1. A sound architectural design where services are neatly conceived for managing values and entities.
2. Collection requirements including boundary values (see Boundary values ). Thereby, the tests will be focused on the “critical” scenarios.
3. Developers able to work in a TDD (Test Driven Development).
4. Scripts (e.g. Based on Ant/Crusader) to send the data results to a repository. This information (developer, task and result) is linked to the WBS/PBS (detailed at work-package level).
5. SQL based procedures for storing the results (see previous point) into a DB, which will be pooled for updating the performances (see post) based on the following values (as described in the following paper[1]):

• Time (Plan)
• Quality of production (As stated in the Acceptance Criteria)[2]
• Cost and reserves
• EVM
• Risks (e.g. listed both for proximity and impact)
• Issues (pending)

Pros and cons

In the following table are listed gains and costs:

Conclusion

The choice of avoiding the automation can be solved with the manual input of “personalized” data. This does not change the necessity of collecting and analyzing data both for evaluating the producers’ performances (Burn down charts) and the team output.

To use technology as ancillary requires that masters would be able to take their own responsibilities (i.e. accepting the existing reality).

[2] The quality of the processes will be monitored through the “Learned Lessons” applied to the Governance.

[3] http://www.stsc.hill.af.mil/consulting/sw_estimation/EstimatingHandbook.html

The projects are set up for delivering a product. Therefore, all the efforts are sustained for obtaining that specific result. The PM(O) must be able to supply, to the Snr Management, the information needed for evaluating whether the project is still feasible (i.e. within the scope, the delivery date, budget and quality) or not.

From this viewpoint, all other information (upcoming results, risks and issues) can be better understood in order to take action whenever it would be required.

Offering an integrated view

Glen, your comment is correctly focused on the “Physical Percent Complete”. This is the core of the message. Thereof, the effort spent is justified (hopefully) by the presence of the result; obviously, they must respond to the “done” criteria (see post ).

Goals that are measured will be achieved[1]. EVM is a good way for showing both the actual result and the trend. There is an interesting paper[2] about it.

It begins with a good description of EVM and then indicates the reasons for its failures. However, most of these problems are just ignored risks. Others, like the evaluation of the LOE, the correct structure of the Critical Path, the quality (plausibility) of the estimations cannot be ignored. Nevertheless, the presence of a working system for collecting automatically (wherever possible) data will increase the possibility of improving the Risk Management (see post about the history and the related comment).

The list of the risk and issues related to the present stage (this can be easily obtained querying the Risk and Issue registers) makes easy to increase the meaningful of the information.

What is worth to present

Until now, the best solution (on trial with positive results) is offered by Dr. C. Ebert in the first cited document.

Briefly it consists in four diagrams (diagrams and underlying formulas on Excel are coming):

1. Milestones
2. Quality
3. Cost
4. Earned Value

It depends upon the project/program complexity the strategy of aggregating those data in order to show the whole picture or singling out specific projects/work-packages.

For the whole “Concept” and the beginning of the “Definition” phases (see yesterday post), due to the early stage of the agreements (i.e. lack of established measurements) efforts can be counted on LoE basis (progress is equal to the actual costs divided for the available budget for the stage).

These metrics are the essential ones. It will depend upon the project/program needs for delving into more details. This would introduce the issue of profiling the reports that will be proposed tomorrow.

Conclusion

Reports are the PM(O) products. Fundamental decisions depend upon the quality of the information provided. Supplying the successful reports is a complex project that begins with the negotiations of what shall be shown, then it is essential to grant the lode of data and check their reliability for producing meaningful information.

[2] www.icoste.org/LukasPaper.pdf