Managing development

Reporting

Reporting from developer

On a internal team configuration mode, 1 meeting every morning of 10-15mn should be organized to ensure team coordination, review the effort of the day before, talk about eventual problems, assign the tasks and fix the daily objectives.

With a distant team, writing reports is essential as the communication is not such efficient as the internal mode.
Developer needs to daily report their work on assigned cases by a comment, even if the case is not finish. They should explain where are they and talk about eventual problems.
See: developer reporting.

Reporting to client (& account manager)

Organize weekly meeting to reassure the client.
Get client feedback on design before integration.
Check your planning to see if you're still in time and notify account manager when at steps completion.

Reporting to CFO

If contractors are involved, they should track their time against their tasks and so with the Redmine example you can have a precise picture of the cost day by day.
CFO probably wants to know if costs and deadline are in tracks.
Use the live project report template file to report on your project. It might be a good idea if this document is shared with like Google Docs.

Project turbulence

For every problem, you need to communicate a lot. Never assume that everyone understands. It's usually a good practice to be transparent with all the stakeholder and say the truth even in case of mistake, it happen every single day to every human being.
Each time a problem appears, take some time to analyze it, why it's happening and which things need to be changed to prevent it.

Deal with specifications changes

You should try to keep client in the scope but it's quite usual that client change his mind and request modifications.
Firstly, you may want to be sure that's it's a out of scope request.
If yes, you will need to gather the specification on this new change and quote the task again.
Check if this new modification will affect the deadline.

Deal with over time

Usually happen as result of a lack of specifications.
When project starting to go over time and client really need the product at the due date it's probably a good idea to try to re-prioritize the work. And see if some feature can be integrated after due date.

Deal with over budget

Like over time it's most of the time a result of a lack of specification. Or because of a problem appearing, like a difficult bug, and not enough spare time has been scheduled to fix it.
In this case, you would want to warn the CFO, estimate the over budget and probably try to find a code solution by modifying the scope and get the client to agree on this.

Developer communication

Case process

Code review