This chapter is from the book
This chapter is from the book
This chapter is from the book
Activity-Based Measures of Progress
We can measure progress as a percentage of project activities that have been completed. We begin with an example of an easy-to-implement progress measure—one requiring only planned start and end dates for each major activity, along with periodic estimates of the percent of each activity complete.
Table 14-1 shows a monthly progress report for one software project. The project has defined a set of activities and assigned start and end dates. Each month, a percent complete estimate is provided, based on the project manager's assessment of how much was actually accomplished up to that point. This report is used to convey progress and current status to several levels of management, up to the corporate CIO. One problem with the report illustrated in Table 14-1 is that the CIO receives this report from more than a hundred individual projects every month. Not only are these reports not really helping the individual projects, but the CIO complains about not having time to read all of them and understand the status of each project.
Looking at Table 14-1, which is a report for one project on April 30, 2001, can we say that the project is ahead of or behind schedule? We might say it is behind because the Develop Design activity should be completed by now, but the project manager is estimating that it is only two-thirds done. On the other hand, the project seems to be ahead on the Code and Unit Test and System Test activities. We could improve the information value of this report, while using the same information, by turning it into a graphical representation comparing planned versus actual percent complete. The CIO (or anyone else) could then tell at a glance how well the project is progressing. In addition, we would like to see the trend over time, not just for a single month.
Table 14-1: Percent Complete Report for the End of April
|
Phase |
Start Date |
Planned End Date |
Percent Complete |
|
Document Business Requirements |
1/15/2001 |
3/15/2001 |
100 |
|
Document Technical Requirements |
1/15/2001 |
3/15/2001 |
100 |
|
Develop Design |
3/1/2001 |
4/30/2001 |
66 |
|
Code and Unit Test |
4/15/2001 |
6/30/2001 |
25 |
|
System Test |
6/15/2001 |
8/15/2001 |
5 |
|
Training |
8/01/2001 |
10/31/2001 |
0 |
|
Data Conversion |
7/01/2001 |
9/30/2001 |
0 |
|
Installation |
9/1/2001 |
11/30/2001 |
0 |
Table 14-2: Weights for Each Activity Derived from Scheduled Duration
|
Activity |
Weight |
|
Document Business Requirements |
10% |
|
Document Technical Requirements |
10% |
|
Develop Design |
10% |
|
Code and Unit Test |
13% |
|
System Test |
10% |
|
Training |
15% |
|
Data Conversion |
15% |
|
Installation |
15% |
Our first step is to represent the plan graphically. We did this by making a straightforward assumption that each activity contributes a percentage weighting to the total according to the length of time planned for that activity. For example, eight weeks have been planned for Document Business Requirements. If we add up the total number of weeks summed across all activities, we get 78, and 8 of 78 gives us 10 percent. Thus this activity counts as 10 percent of the total project. The weights for each activity are shown in Table 14-2.
To create the plan line, we can take a regular interval—in this case, monthly—and multiply the percent of each activity that should be completed at the end of each month. Thus, the Document Business Requirements activity should be 25 percent complete at the end of January (2 weeks divided by 8 weeks). It should be 75 percent complete at the end of February (6 weeks divided by 8 weeks), and so on. Based on the dates shown in Table 14-1, we can fill in Table 14-3.
The final step in creating the plan line is to multiply corresponding entries from Tables 14-2 and 14-3. For example, we derive the data point for Document Business Requirements for January by multiplying 10% by 25% to give us 2.5%. The completed weights are shown in Table 14-4.
Table 14-3: Planned Percent Complete for Each Activity by Month
|
|
Jan 31 |
Feb |
Mar |
Apr |
May |
Jun |
Jul |
Aug |
Sep |
Oct |
Nov |
|
Bus. Rqts. |
25% |
75% |
100% |
100% |
100% |
100% |
100% |
100% |
100% |
100% |
100% |
|
Tech. Rqts. |
25% |
75% |
100% |
100% |
100% |
100% |
100% |
100% |
100% |
100% |
100% |
|
Des. |
0% |
0% |
50% |
100% |
100% |
100% |
100% |
100% |
100% |
100% |
100% |
|
Code |
0% |
0% |
0% |
20% |
60% |
100% |
100% |
100% |
100% |
100% |
100% |
|
Sys. Test |
0% |
0% |
0% |
0% |
0% |
25% |
75% |
100% |
100% |
100% |
100% |
|
Train. |
0% |
0% |
0% |
0% |
0% |
0% |
0% |
33% |
66% |
100% |
100% |
|
Conv. |
0% |
0% |
0% |
0% |
0% |
0% |
33% |
67% |
100% |
100% |
100% |
|
Inst. |
0% |
0% |
0% |
0% |
0% |
0% |
0% |
0% |
33% |
67% |
100% |
Table 14-4: Weights for Each Activity Used in Creating a Plan Line
|
|
Jan |
Feb |
Mar |
Apr |
May |
Jun |
Jul |
Aug |
Sep |
Oct |
Nov |
|
Bus. Rqts. |
2.5% |
7.5% |
10% |
10% |
10% |
10% |
10% |
10% |
10% |
10% |
10% |
|
Tech. Rqts. |
2.5% |
7.5% |
10% |
10% |
10% |
10% |
10% |
10% |
10% |
10% |
10% |
|
Des. |
0% |
0% |
5% |
10% |
10% |
10% |
10% |
10% |
10% |
10% |
10% |
|
Code |
0% |
0% |
0% |
3% |
8% |
13% |
13% |
13% |
13% |
13% |
13% |
|
Sys. Test |
0% |
0% |
0% |
0% |
0% |
2.5% |
7.5% |
10% |
10% |
10% |
10% |
|
Train. |
0% |
0% |
0% |
0% |
0% |
0% |
0% |
5% |
10% |
15% |
15% |
|
Conv. |
0% |
0% |
0% |
0% |
0% |
0% |
5% |
10% |
15% |
15% |
15% |
|
Inst. |
0% |
0% |
0% |
0% |
0% |
0% |
0% |
0% |
5% |
10% |
15% |
Our next step is to gather up actuals from the past four months, not just the most recent month. We have gone back to the reports from each month to create the entries shown in Table 14-5.
By multiplying the activity weights from Table 14-2 by the actual percentage complete from Table 14-5, we can graphically present actual progress as shown in Figure 14-3.
)
Figure 14-3: Graphical representation of planned activities complete
Remember that the original complaint about this report came from the CIO: the textual report (Table 14-1) for each project was too confusing, and more than a hundred of these were produced for the entire IT organization.
One benefit of the graphical report shown in Figure 14-3 is that it shows planned and actual, so that in an instant, anyone can tell whether a project is ahead or behind. Because these values are expressed in percentages for each project, they can be rolled up for a division or for the entire IT organization. The CIO can then selectively drill down to the level of individual projects.
As an indicator of project status, this simple percent complete measure has several strengths, especially as compared to the original text report from Table 14-1. For example, the data provides visibility into project progress, and the project did not require a mature process to generate the plan or actual lines. Also, Figure 14-3 lets us make predictions about the future by extrapolating from the actual line.
Table 14-5: Percent Completed Reported by Month
|
Phase |
Planned Start Date |
Planned End Date |
Percent Complete |
|||
|
Jan |
Feb |
Mar |
Apr |
|||
|
Document Business Requirements |
1/15/2001 |
3/15/2001 |
10 |
25 |
50 |
100 |
|
Document Technical Requirements |
1/15/2001 |
3/15/2001 |
15 |
33 |
75 |
100 |
|
Develop Design |
3/1/2001 |
4/30/2001 |
5 |
10 |
20 |
66 |
|
Code and Unit Test |
4/15/2001 |
6/30/2001 |
0 |
0 |
0 |
25 |
|
System Test |
6/15/2001 |
8/15/2001 |
0 |
0 |
0 |
5 |
|
Training |
8/01/2001 |
10/31/2001 |
0 |
0 |
0 |
0 |
|
Data Conversion |
7/01/2001 |
9/30/2001 |
0 |
0 |
0 |
0 |
|
Installation |
9/1/2001 |
11/30/2001 |
0 |
0 |
0 |
0 |
This percent complete measure has weaknesses in several areas:
The measure is based on subjective judgment. Judgments tend to be overly optimistic, with the result that major schedule slips may not be apparent until late in the project.
Reporting progress by major activity is too high a level for identifying problem areas. The next example shows a level of detail that supports an effective drill-down capability within a single project.
Monthly reporting is too infrequent. Effective progress reporting occurs weekly.
One note of caution regarding progress measures based on subjective judgment: Be sure you do not punish someone for providing honest data. People should be in trouble only if they are not reporting things accurately. Conversely, there should be no shame from being behind, reporting honestly, and indicating what is needed to correct the problem. This requires a drastic change in culture for many organizations. Getting the numbers is not the hard part of progress measurement. Using the numbers effectively and constructively requires strong leadership.