History: Managing development

Source of version: 12 (current)

!Managing development
!!Reporting

Reporting is useful for both of the writer and the reader. It force the writer to check the project status and so be constantly aware of time & cost and anticipate problems.

!!!Reporting from developer
On a internal team configuration mode, one 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_documentation#Reporting|developer reporting].

!!!Reporting to client
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 [using_redmine|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 {FILE(fileId=21)}live project report template{FILE} 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
Developer should be able to contact project manager as much as they need, they're the last link in the chain! You never want them to be stop too long with a question. 
Use the live chat for non critical information and an email when you need to confirm something important as email leave tracks. 
See [developer_documentation|QA process].
Ensure reporting from each developer.

{FANCYTABLE(head=> __Actions__)}
Report & communicate with client
Report to internal team with {FILE(fileId=21)}live project report template{FILE}
Check the project progress
Check developer reporting
{FANCYTABLE}

SourceHistory

- A simple and Open process for web team management - Find Register Log in Username: Password: I forgot my password Register
	Sidebar Menu Home Search Categories Wiki Wiki Home Last Changes List Pages Orphan Pages Sandbox Multiple Print Structures Articles Articles Home List Articles Forums List Forums File Galleries List Galleries	History: Managing development View page Source of version: 12 (current) !Managing development !!Reporting Reporting is useful for both of the writer and the reader. It force the writer to check the project status and so be constantly aware of time & cost and anticipate problems. !!!Reporting from developer On a internal team configuration mode, one 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_documentation#Reporting\|developer reporting]. !!!Reporting to client 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 [using_redmine\|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 {FILE(fileId=21)}live project report template{FILE} 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 Developer should be able to contact project manager as much as they need, they're the last link in the chain! You never want them to be stop too long with a question. Use the live chat for non critical information and an email when you need to confirm something important as email leave tracks. See [developer_documentation\|QA process]. Ensure reporting from each developer. {FANCYTABLE(head=> __Actions__)} Report & communicate with client Report to internal team with {FILE(fileId=21)}live project report template{FILE} Check the project progress Check developer reporting {FANCYTABLE} SourceHistory
RSS: Wiki Articles File Galleries Forums This content is licensed under a Creative Commons Attribution 3.0 Unported License offered by Pierre Doleans and sponsored by Collabforge - Website powered by Tiki Wiki

Sidebar

Menu

History: Managing development

Source of version: 12 (current)