After project work is under way, you want to make sure that it proceeds according to plan. To do this, you need to establish a reporting system that keeps you informed of the many variables that describe how the project is proceeding as compared to the plan.
A reporting system has the following characteristics:
To establish this reporting system, you can choose from among the hundreds of reports that are standard fare in project management software packages. Once you decide what you want to track, these software tools offer several suggestions and standard reports to meet your needs. Most project management software tools enable you to customize their standard reports to meet even the most specific needs.
There are five types of project status reports: current period, cumulative, exception, stoplight, and variance. Each of these report types is described here.
These reports cover only the most recently completed period. They report progress on activities that were open or scheduled for work during the period. Reports might highlight activities completed, as well as the variance between scheduled and actual completion dates. If any activities did not progress according to plan, the report should include the reasons for the variance and the appropriate corrective measures that will be implemented to fix the schedule slippage.
These reports contain the history of the project from the beginning to the end of the current report period. They are more informative than the current period reports because they show trends in project progress. For example, a schedule variance might be tracked over several successive periods to show improvement. Reports can be at the activity or project level.
Exception reports indicate variances from the plan. These reports are typically designed for senior management to read and interpret quickly. Reports that are produced for senior management merit special consideration. Senior managers do not have a lot of time to read reports that tell them everything is on schedule and there are no problems serious enough to warrant their attention. In such cases, a one-page, high-level summary report that says everything is okay is usually sufficient. It might also be appropriate to include a more detailed report as an attachment for those who might want more information. The same might be true of exception reports. That is, the one-page exception report tells senior managers about variances from the plan that will be of interest to them, and an attachment provides more details for the interested reader.
Stoplight reports are a variation that can be used on any of the previous report types. I believe in parsimony in all reporting. Here is a technique you might want to try: When the project is on schedule and everything seems to be proceeding as planned, put a green sticker on the top-right corner of the first page of the project status report. This sticker will signal to senior managers that everything is progressing according to plan, and they need not even read the attached report.
When the project has encountered a problem — schedule slippage, for example — you might put a yellow sticker on the top-right corner of the first page of the project status report. That is a signal to upper management that the project is not moving along as scheduled but that you have a get-well plan in place. A summary of the problem and the get-well plan may appear on the first page, but they can also refer to the details in the attached report. Those details describe the problem, the corrective steps that have been put in place, and some estimate of when the situation will be rectified.
Red stickers placed on the top-right corner of the first page signal that a project is out of control. Red reports should be avoided at all costs because they indicate that the project has encountered a problem for which you don't have a get-well plan or even a recommendation for upper management. Senior managers will obviously read these reports because they signal a major problem with the project. On a more positive note, the red condition may be beyond your control. Here's an example of when a red condition would be warranted: there is a major power grid failure on the East Coast and a number of companies have lost their computing systems. Your hot site is overburdened with companies looking for computing power. Your company is one of them, and the loss of computing power has put your project seriously behind in final system testing. There is little you can do to avoid such acts of nature.
Variance reports do exactly what their name suggests — they report differences between what was planned and what actually happened. The report has the following three columns:
A variance report can be in one of the following two formats:
Typical variance reports are snapshots in time (the current period) of the status of an entity being tracked. Most variance reports do not include data points that report how the project reached that status. Project variance reports can be used to report project as well as activity variances. For the sake of the managers who will have to read these reports, I recommend that one report format be used regardless of the variable being tracked. Your upper management will quickly become comfortable with a reporting format that is consistent across all projects or activities within a project. It will make life a bit easier for you, as the project manager, too.
Here are five reasons why you should measure duration and cost variances:
Early detection of out-of-control situations is important. The longer you wait to discover a problem, the longer it will take for your solution to bring the project back to a stable condition.
As input to each of these report types, activity managers and the project manager must report the progress made on all activities that were open for work (in other words, those that were to have work completed on them during the report period) during the period of time covered by the status report. Recall that your planning estimates of activity duration and cost were based on little or no information. Now that you have completed some work on the activity, you should be able to provide a better estimate of duration and cost. This is reflected in a re-estimate of the work remaining to complete the activity. That update information should also be provided.
The following list describes what should actually be reported:
Determine a set period of time and day of week — The project team will have agreed on the day of the week and time of day by which all updated information is to be submitted. A project administrator or another team member is responsible for ensuring that all update information is on file by the report deadline.
Report actual work accomplished during this period — What was planned to be accomplished and what was actually accomplished are often two different things. Rather than disappoint the project manager, activity managers are likely to report that the planned work was actually accomplished. Their hope is to catch up by the next report period. Project managers need to verify the accuracy of the reported data, rather than simply accept it as accurate. Spot-checking on a random basis should be sufficient.
Record historical data and re-estimate remaining work (in-progress work only) — The following two kinds of information are reported:
Report start and finish dates — These are the actual start and end dates of activities started or completed during the report period.
Record days of duration accomplished and remaining — First reported is how many days have been spent so far working on this activity. The second number is based on the re-estimated duration as reflected in the time-to-completion number.
Report resource effort (hours/day) spent and remaining (in-progress work only) — Whereas the preceding numbers report calendar time, these two numbers report labor time over the duration of the activity. One reports labor completed over the duration already accomplished. The other reports labor to be spent over the remaining duration.
Report percent complete — Percent complete is the most common method used to record progress because it is the way people tend to think about what has been done in reference to the total job to be completed. Percent complete isn't the best method to report progress, however, because it is a subjective evaluation. What goes through a person's mind when you ask him or her, “What percent complete are you on this activity?” The first thing is most likely “What percent should I be?” This is followed closely by “What's a number that we can all be happy with?” To calculate the percent complete for an activity, you need something quantifiable. Different approaches have been used to calculate percent complete, including the following:
A logical frequency for reporting project progress is once a week, usually on Friday afternoon. For some projects, such as refurbishing a large jet airliner, progress is recorded after each shift, three times a day. I've seen others that were of such a low priority or long duration that they were updated once a month. For most projects, start gathering the information around noon on Friday. Let people extrapolate to the end of the workday.
Variances are deviations from plan. Think of a variance as the difference between what was planned and what actually occurred. There are two types of variances: positive variances and negative variances.
Positive variances are deviations from the plan indicating that an ahead-of-schedule situation has occurred or that an actual cost was less than a planned cost. This type of variance is good news to the project manager, who would rather hear that the project is ahead of schedule or under budget.
Positive variances bring their own set of problems, however, which can be as serious as negative variances. Positive variances can result in rescheduling to bring the project to completion early, under budget, or both. Resources can be reallocated from ahead-of-schedule projects to behind-schedule projects. Positive variances also can result from schedule slippage! Consider budget. Being under budget means that not all dollars were expended, which may be the direct result of not having completed work that was scheduled for completion during the report period.
This situation is revisited in the “Earned Value Analysis” section later in this chapter.
Conversely, if the ahead-of-schedule situation is the result of the project team finding a better way or a shortcut to complete the work, the project manager will be pleased. This situation may result in a short-lived benefit, however. Getting ahead of schedule is great, but staying ahead of schedule presents another kind of problem. To stay ahead of schedule, the project manager must negotiate changes to the resource schedule. Given the aggressive project portfolios in place in most companies, it is unlikely that resource schedule changes can be made. In the final analysis, being ahead of schedule may be a myth.
Negative variances are deviations from the plan indicating that a behind-schedule situation has occurred or that an actual cost was greater than a planned cost. Being behind schedule or over budget is not what the project manager or reporting manager wants to hear. Negative variances are not necessarily bad news, however. For example, you might have overspent because you accomplished more work during the report period than was planned. In overspending during this period, you could have accomplished the work at less cost than was originally planned. You can't tell by looking at the variance report. You will need the details available in the EVA reports
More details are forthcoming on this topic in the “Earned Value Analysis” section later in this chapter.
In most cases, negative time variances affect project completion only when they are associated with critical-path activities or when the schedule slippage on non–critical-path activities exceeds the activity's slack. Slack is defined in Chapter 5. Minor variances use up the slack time for that activity; more serious ones will cause a change in the critical path.
Negative cost variances can result from uncontrollable factors such as cost increases from suppliers or unexpected equipment malfunctions. Some negative variances can result from inefficiencies or error. I discuss a problem escalation strategy to resolve such situations later in this chapter.
REPORTING AND DISPARATE PROJECT MANAGEMENT APPROACHES
Not every project will use the same project management approach. That may create reporting problems when project status reports are sent up the food chain to senior managers. You could just let the chips fall where they may and force senior managers to aggregate the data to fit their own needs. I don't see many senior managers agreeing to place that burden on their office staff. Instead a standard reporting format must be established and each project manager must be responsible for reporting status accordingly.
18.118.198.127