This chapter is from the book
This chapter is from the book
This chapter is from the book
Detailed Activity-Based Measure
Percent-complete measures can be based on a much lower level of granularity. Table 14-5 shows an example based on a very detailed breakdown of activities and rolled up to the project level. (Figure 14-4 is a simplification from an actual project but the general idea has been captured.) For each of the units to be designed, an estimated number of design hours were generated (based on a combination of parametric cost-modeling and engineering judgment). For Subsystem 1, Unit A will require an estimated 120 hours, while Unit B will require an estimated 88 hours. Each unit is assigned a weighting based on these estimates. For example, the 120 hours estimated for Unit A represents 120/1071 hours or 11.20 percent of the estimated design effort.
)
Figure 14-4: Graphical representation of percent complete based on data in Table 14-5
Each design activity (for example, requirements trace or use cases) is assigned a weight based on a combination of historical data and engineering judgment. Thus, tracing the requirements counts for 15 percent, documenting use cases counts for 25 percent, and so on. We can multiply the two sets of weights to derive detailed weights for each unit by activity combination. For example, for the activity of requirements trace, we multiply 11.20 percent times 15 percent to arrive at a weighting of 1.68 percent for Unit A. This means that a credit of 1.68 can be claimed only after the requirement trace for Unit A from Subsystem 1 is completed, documented, and signed off (by SQA or whatever exit criteria are in place for calling a design activity complete). Each of the other design activities—use cases, object model, and peer review—is associated with planned and actual completion dates and weightings. For the sake of saving space, these dates and weightings are not filled in.
You can use this same method to track code progress or integration and test progress. The percentages can be summed on a weekly basis to show overall progress. By looking at the detailed data in the spreadsheets, it is possible to see the progress of individual tasks for individual units.
This is the approach underlying the concept of Earned Value, a topic that is beyond the scope of this chapter. An excellent reference is Earned Value Project Management by Quentin W. Fleming and Joel M. Hoppelman.
The strengths of this detailed level of tracking progress include the following:
It is more objective than the less detailed example above because concrete exit criteria were associated with each of the design activities.
Weekly reporting made this much closer to real time than the monthly reporting of the first example.
The detailed reporting provided a clear drill-down capability for the project manager, who could look at progress from the perspective of the entire project or for individual subsystems and units.
The weakness in this example was the need for a detailed level of planning (certainly not a weakness in itself, but an immature process will not support this level of planning and tracking).
Product-Based Measures of Progress
The second type of measure—work unit progress—looks at progress from the perspective of the work product rather than the intermediate activities. Instead of counting activities completed, we count units of product that pass objective completion criteria. The key word here is "objective." Work unit progress can be measured at any phase in the development (units designed, units coded, units completing unit test, units integrated, tests successfully executed, problem reports closed). Units can refer to any work entity that is meaningful, including design components, function points, lines of code, screens, reports, and so on.
The basic concept is to start with an estimate of the total number of units, a planned start and end date, and a plan line that represents the number of units completed at various points. The completion of work units often follows an S-shaped curve similar to that shown in Figure 14-5. Progress appears slow at first, but the rate increases and then tapers off as the final and most difficult units are completed.
)
Figure 14-5: Typical S-shaped curve
Figure 14-6 shows a measure of planned versus actual progress based on this type of measure. Again this example is from a real project.
)
Figure 14-6: Work unit progress
The work unit progress measure shown in Figure 14-6 has the following strengths:
It is objective to the extent that it is based on concrete exit criteria for counting a unit as coded.
It can support roll-up and drill-down. We can look at coding progress for the entire project, or we can drill down and look at individual subsystems.
The biggest strength: Work unit progress can be very useful, even in the absence of a detailed planning process. It provides visibility into the rate of progress required to meet the planned start and endates for any given activity. In that sense, it can be a useful counterpart to a Gantt chart by allowing us to answer the question "How many units do we need to have completed at any given time?"