The project manager prepares a status report every period (biweekly or semi-monthly is the preferred frequency), based on the aggregation of the individual status reports provided by the package managers. The status report should contain the following elements: Accomplishments This Period. Summarizes the packages (or, deliverables, in a non-software project) completed and any issues that have been resolved this period. Planned Accomplishments for Next Period. Identifies those packages and issues that are planned to be completed during the next reporting period. Issues. All open issues should be numbered so they can be tracked and measured. The project manager should attempt to quantify each issue with an assessment of the potential impact (effort, cost, and time) so that they can be prioritized. As issues get closed they drop off the list. Progress against Plan. A simple table (Figure 1) provides a complete quantitative picture of the project’s progress against the current estimates and targets. There is typically a need for separate tables showing effort (person hours, person days), target dates, and costs. Original Estimate is the effort agreed to in the original plan, budget, contract, etc., and serves as the base against which variances are reported. As changes are approved, this estimate can be updated accordingly, or a separate column can be added to track approved changes. This Period is the effort incurred during the current reporting period. To Date is the total effort actually incurred so far. A value of zero indicates that work has not commenced. Rem To Do is the amount that the individual doing the work estimates is required to complete the assignment. This must be re-estimated every period. It is not simply an automatic subtraction of the To Date value from the Original Estimate. In other words, Rem To Do should always represent what the worker currently thinks is the effort required to complete that assignment based on the experience so far. A value of zero indicates that work is completed. Var This Period is simply the difference between the Var Total computed this period and the Var Total computed for last period. This value represents the variance actually incurred this reporting period and is a simple mechanism to track and manage slippages and over-runs before they become unmanageable. The volatility of this number is an excellent indicator of project risk. Also, the trend of this value over time is a window into whether the project is improving or worsening. Var Total is the total variance and is the difference between the Original Estimate (plus any approved changes) and the sum of the To Date and Rem To Do values. Finally, it is useful to have a place where the relevant managers can include any written explanations for any current period variances. This tends to simplify status reporting and ensures that any material changes in progress are documented for learning and root cause analysis.

Original Estimate This Period To Date Rem To Do Var This Period Var Total Module 8 125 25 100 25 Module 9 85 20 30 60 -5 -5 Build D 210 45 130 85 -5 -5 Total Project 5200 350 800 4000 200 400

Figure 1. Example progress against plan (Effort Table).

The progress reporting structure should map directly to the WBS so that the relevant aggregations and summaries can be produced by package. This also provides the ability to drill down to finer details to better understand trends and risks. For example, we see in Figure 1 that Build D is projecting an over-run of five hours for the implementation of Module 9. Figure 2 provides more detail on this status by revealing the WBS for this module. This shows that during the planning activities (Plan) the developer was able to complete that work ahead of estimate by five person-hours. However, the construction task (Construct), which is still in progress, is now projecting an over-run of ten person-hours. The sum results in the total five-hour projected over-run for the module.

Original Estimate This Period To Date Rem To Do Var This Period Var Total Plan 10 0 5 0 5 5 Construct 35 20 25 20 -10 -10 Cover 10 0 0 10 Validate 30 0 0 30 Module 9 85 20 30 60 -5 -5

Figure 2. Example drill-down for progress of Module 9.

And, further, since neither the unit test planning (Cover task), nor the unit testing itself (Validate task) has started for this module, it is important for the project manager to ensure that the developers have reflected their current understanding of the risks and complexity that resulted in increasing the effort for programming is properly reflected in those two tasks. There is typically a great deal of learning that is gained early in the project life cycle that must be reflected in downstream activities, or it will be lost.

Back to top