Applying Graphical Reporting Tools
,As mentioned earlier in the chapter, senior managers may have only a few minutes of uninterrupted time to digest your report. Respect that time. They won't be able to fully read and understand your report if they have to read 15 pages before they get any useful information. Having to read several pages only to find out that the project is on schedule is frustrating and a waste of valuable time.
Gantt Charts
A Gantt chart is one of the most convenient, most frequently used, and easiest-to-grasp depictions of project activities that I have encountered. The chart is formatted as a two-dimensional representation of the project schedule, with activities shown in the rows and time shown across the horizontal axis. It can be used during planning, for resource scheduling, and for status reporting. The only downside to using Gantt charts is that they do not contain dependency relationships. Some project management software tools provide an option to display these dependencies, but the result is a graphical report that is so cluttered with lines representing the dependencies that the report is next to useless. In some cases, dependencies can be guessed at from the Gantt chart, but in most cases, they are lost.
Figure 7-1 shows a representation of the Cost Containment Project as a Gantt chart, using the format that I prefer. The format shown is from Microsoft Project, but it is typical of the format used in most project management software packages.
Figure 7-1: Gantt chart project status report
Stoplight Reports
As mentioned earlier in the chapter, stoplight reports are a very effective way to communicate status intuitively without burdening senior managers with the need to read anything. The explanation will, of course, be in the attached report if the managers are interested in reading the details.
Burn Charts
Burn charts are another intuitive tool that displays the cumulative consumption of any resource over time, expressed either as a percentage of the resource allocated to the project or the quantity of the resource. If you are displaying the quantity, there should be a horizontal line showing the maximum quantity of the resource available. Burn charts are very simple, but they're limited in their value. For a more sophisticated display of resource use against the plan, the earned value analysis would be used.
Milestone Trend Charts
Milestones are significant events that you want to track in the life of the project. These significant events are zero-duration activities and merely indicate that a certain condition exists in the project. For example, a milestone event might be the approval of several different component designs. This event consumes no time in the project schedule. It simply reflects the fact that those approvals have all been granted. The completion of this milestone event may be the predecessor of several build-type activities in the project plan. Milestone events are planned into the project in the same way that activities are planned into the project. They typically have finish-to-start (FS) relationships with the activities that are their predecessors and their successors.
Figure 7-2 shows a milestone trend chart for a hypothetical project. The trend chart plots the difference between the planned and estimated date of a project milestone at each project report period. In the original project plan, the milestone is planned to occur in the ninth month of the project. That is the last project month on this milestone chart. The horizontal lines represent one, two, and three standard deviations above or below the forecasted milestone date. All activities in the project have an expected completion date that is approximately normally distributed. The mean and variance of an activity's completion date are a function of the longest path to that activity from the report date. In this example, the units of measure are one month. For this project, the first project report (at month 1) shows that the new forecasted milestone date will be one week later than planned. At the second project report date (month 2 of the project), the milestone date is forecasted on target. The next three project reports indicate a slippage to two weeks late, then three weeks late, then four weeks late, and finally six weeks late (at month 6 of the project). In other words, the milestone is forecasted to occur six weeks late, and only three more project months remain in which to recover the slippage. Obviously, the project is in trouble. It appears to be drifting out of control, and in fact it is. Some remedial action is required of the project manager.
Figure 7-2: A run up or down of four or more successive data points
STANDARD DEVIATION
The variance and standard deviation of a set of data points measure the spread of the data points around the average value of the data points. The formula for calculating standard deviation of a set of n data points x1, x2, … xn is as follows:
Variance = Σ((xi − xm) / xm)2
Standard Deviation = Square root of the variance, where xm is the average of the n data points.
If you want to learn more about these two metrics, refer to any elementary materials on statistics.
Certain patterns signal an out-of-control situation. These patterns are shown in Figures 7-2 through 7-5 and are described here:
Successive slippages — Figure 7-2 (shown previously) depicts a project that is drifting out of control. Each report period shows additional slippage since the last report period. Four such successive occurrences, however minor they may seem, require special corrective action on the part of the project manager.
Radical change — Figure 7-3 shows the milestone to be ahead of schedule, but it also reports a radical change between report periods. Activity duration may have been grossly overestimated. There may be a data error. In any case, the situation requires further investigation.
Figure 7-3: A change of more than three standard deviations
Successive runs — Figure 7-4 signals a project that may have encountered a permanent schedule shift. In the example, the milestone date seems to be varying around one month ahead of schedule. Barring any radical shifts and the availability of resources over the next two months, the milestone will probably be reached one month early. Remember that you have negotiated for a resource schedule in these two months, and now you will be trying to renegotiate an accelerated schedule.
Figure 7-4: Seven or more successive data points above or below the planned milestone date
Schedule shift — Figure 7-5 depicts a major shift in the milestone schedule. The cause must be isolated and the appropriate corrective measures taken. One possibility is the discovery that a downstream activity will not be required. Perhaps the project manager can buy a deliverable, rather than build it, and remove the associated build activities from the project plan.
Figure 7-5: Two successive data points outside three standard deviations from the planned milestone date
Earned Value Analysis
Earned value analysis (EVA) is used to measure project performance and, by tradition, uses the dollar value of work as the metric. As an alternative, resource person hours/day can be used in cases where the project manager does not directly manage the project budget. Actual work performed is compared against planned and budgeted work expressed in these equivalents. These metrics are used to determine schedule and cost variances for both the current period and the cumulative to-date period. Cost and resource person hours/day are not good, objective indicators with which to measure performance or progress. Unfortunately, there is no other good objective indicator. Given this, you are left with dollars or person hours/day, which you are at least familiar working with in other contexts. Either one by itself does not tell the whole story. You need to relate them to each other.
One drawback that these metrics have is that they report history. Although they can be used to make extrapolated predictions for the future, they primarily provide a measure of the general health of the project, which the project manager can correct as needed to restore the project to good health.
Figure 7-6 shows an S curve, which represents the baseline progress curve for the original project plan. It can be used as a reference point. That is, you can compare your actual progress to date against the curve and determine how well the project is doing. Again, progress can be expressed as either dollars or person hours/day.
By adding the actual progress curve to the baseline curve, you can see the current status versus the planned status. Figure 7-7 shows the actual progress curve below the planned curve. If this represented dollars, you might be tempted to assume the project is running under budget. Is that really true?
Figure 7-6: The standard S curve
Figure 7-7: Baseline versus actual cost curve illustrating cost variance
Projects rarely run significantly under budget. A more common reason for the actual curve to be below the baseline is that activities that should have been done have not been, and thus the dollars or person hours/day that were planned to be expended are unused. The possible schedule variance is highlighted in Figure 7-8.
Figure 7-8: Baseline versus actual cost illustrating schedule variance
To determine actual progress schedule variance, you need some additional information. EVA comprises three basic measurements: budgeted cost of work scheduled, budgeted cost of work performed, and actual cost of work performed. These measurements result in two variance values: schedule variance and cost variance. Figure 7-9 is a graphical representation of the three measurements.
Figure 7-9: Cost and performance indicators
The figure shows a single activity that has a five-day duration and a budget of $500. The budget is prorated over the five days at an average daily value of $100. The left panel of Figure 7-9 shows an initial (baseline) schedule with the activity starting on the first day of the week (Monday) and finishing at the end of the week (Friday). The budgeted $500 value of the work is planned to be accomplished within that week. This is the planned value (PV). The center panel shows the actual work that was done. Note that the schedule slipped and work did not begin until the third day of the week. Using an average daily budget of $100, you see that you were able to complete only $300 of the scheduled work. This is the earned value (EV). The rightmost panel shows the actual schedule, as in the center panel, but now you see the actual dollars that were spent to accomplish the three days' work. This $400 is the actual cost (AC).
The PV, EV, and AC are used to compute and track two variances. The first is schedule variance (SV). SV is the difference between the EV and the PV, which is −$200 (EV – PV) for this example. That is, the SV is the schedule difference between what was done and what was planned to be done, expressed in dollar or person hours/day equivalents. The second is cost variance (CV). CV is the difference between the EV and the AC, which is $100 in this example. That is, (AC – EV) the cost of the work completed, was overspent by $100.
EVA TERMINOLOGY
For those who are familiar with the older cost/schedule control terminology, I have used the new terminology as defined in the Project Management Body of Knowledge (PMBOK) 2000 and as used in PMBOK 2003. The old terminology corresponds to the new terminology as follows:
- ACWP is the actual cost (AC).
- BCWP is the earned value (EV).
- BCWS is the planned value (PV).
Management might react positively to the information previously shown in Figure 7-7, but they might also be misled by such data. The full story is told by comparing both budget variance and schedule variance as shown in Figure 7-10.
To correctly interpret the data shown previously in Figure 7-8, you need to add the EV data shown in Figure 7-9 to produce Figure 7-10. Comparing the EV curve with the PV curve, you see that you have underspent because all of the work that was scheduled has not been completed. Comparing the EV curve to the AC curve also indicates that you overspent for the work that was done. Clearly, management would have been misled by Figure 7-7 had they ignored the data in Figure 7-9. Either one by itself may be telling a half-truth.
In addition to measuring and reporting history, EVA can be used to predict the future of a project. Take a look at Figure 7-11. By cutting the PV curve at the report date height from the horizontal axis, which has been achieved by the EV, and then pasting this curve onto the end of the EV curve, you can extrapolate the completion of the project. Note that this is based on using the original estimates for the remaining work to be completed. If you continue at the same rate you have been progressing thus far, you will finish beyond the planned completion date. Doing the same thing for the AC shows that you will finish over budget. This is the simplest method of attempting to “estimate to completion,” but it clearly illustrates that a significant change needs to occur in the way this project is running.
Figure 7-11: PV, EV, and AC curves
The three basic indicators yield an additional level of analysis for you. Schedule performance index (SPI) and cost performance index (CPI) are further refinements computed as follows:
SPI = EV / PV
CPI = EV / AC
Schedule Performance Index — The SPI is a measure of how close the project is to performing work as it was actually scheduled. If you are ahead of schedule, EV will be greater than PV, and therefore the SPI will be greater than 1. Obviously, this is desirable. Conversely, an SPI below 1 indicates that the amount of work performed was less than the work scheduled — not a good thing.
Cost Performance Index — The CPI is a measure of how close the project is to spending on the work performed to what was planned to have been spent. If you are spending less on the work performed than was budgeted, the CPI will be greater than 1. If not, and you are spending more than was budgeted for the work performed, then the CPI will be less than 1.
Some managers prefer this type of analysis because it is intuitive and quite simple to equate each index to a baseline of 1. Any value less than 1 is undesirable; any value over 1 is good. These indices are displayed graphically as trends compared against the baseline value of 1.
Integrating Milestone Trend Charts and Earned Value Analysis
Both milestone trend charts and earned value can easily be accommodated within the project life cycle. All of these metrics can be used to track practice-level improvements resulting from a process improvement program. After all, they are where the rubber meets the road.
This section is adapted from an earlier book of mine, Effective Software Project Management (Wiley, 2006).
Integrating Earned Value
At each report date, tasks that are open for work or were scheduled to be open for work can be in one of the following three situations:
- They are complete and hence have accrued 100 percent value.
- They are still open for work and hence have accrued a percentage of value equal to the proportion of subtasks completed.
- They are still open for work, and no subtasks are completed; hence, they have accrued 0 percent value.
Add all of the accrued values since the last report date to the cumulative project total. Display that data on the baseline S curve.
Integrating Milestone Trend Data
At each report date, the task managers of tasks that are open for work or were scheduled to be open for work should update the project file. The update information will indicate the following:
- The task is reported as complete as of a certain date.
- A certain percentage of the task work is complete (same as the earned value report mentioned previously) and an updated estimate to completion is given.
- No progress is reported.
If project management software is used, the software produces an updated project file with new forecasted dates for the milestones you are tracking. The presentation of the SPI and CPI data over time can be represented using the same format that was used to report milestone trend data. Three examples follow.
Figure 7-12 depicts a common situation. Here the project has gotten behind schedule (denoted by the “S” in the figure) but is under budget (denoted by the “C” in the figure). That is probably due to the fact that work that was scheduled has not been done and hence the labor costs associated with those tasks have not been incurred.
Figure 7-12: A project that is under budget and behind schedule
On rare occasions, you might experience the situation shown in Figure 7-13. The project is ahead of schedule and under budget. Less costly ways were found to complete the work, and the work was completed in less time than was planned. If this should ever happen to you, relish the moment. Take whatever kudos your client or management cares to heap on you. You deserve their accolades. They don't happen often.
Figure 7-13: A project that is under budget and ahead of schedule
Figure 7-14 is the worst of the worst. Nothing more needs to be said.
Figure 7-14: A project that is over budget and behind schedule
The same approach can be used to track a project portfolio over time, as shown in Figure 7-15.
The graph shows the SPI values of the individual projects that comprise the portfolio. This is also a useful graphic for summarizing the practice changes from your process improvement program. If a clear trend is visible at the portfolio level, it is indicative of a successful transition from process to practice.
Figure 7-15: Adapting the life cycle for a project portfolio schedule
