True or false? It becomes increasingly important to track progress as the deadline nears to see how close the project will be to finishing on time and on budget.
False! This is a pretty easy question to answer if you've read the previous chapters. By the end of the project it doesn't matter how close you are because you have almost no ability to change your cost and schedule performance. The key to finishing on time and on budget is to start out that way and stay on track throughout the project.
When projects start with challenging schedules, if they fall behind, even by a little, they spend the rest of the project trying to catch up. Other projects, however, seem to have a self‐correcting process built into them; if they fall behind a little, the problem is quickly identified and dealt with immediately. The best project managers find problems early and solve them without overtime. They make the project look easy.
Progress measurements are the tools we use to identify problems when they are small—when there is still time to catch up. Since cost and schedule progress comprise two‐thirds of the cost‐schedule‐scope equilibrium, they are the primary focus of progress measurement.
Each work package in the plan is a measurable unit of progress. Each has start and finish dates. The smaller the work packages, the more progress points you can refer to, and therefore the more accurate your schedule progress will be. (Work package size guidelines are covered in Chapter 9.) The following story highlights the importance of breaking down a project into small, measurable units.
A software project manager responsible for a major release of a flagship product was trying to ascertain the schedule status. Several of the development managers had broken their work down into only a few tasks that were six months long. All were reporting that they were “on schedule” four and a half months into their work. The project manager's gut feeling was that the developers really had no idea where they were. She also felt that they were not likely to recognize a schedule problem for at least three more weeks—and that they wouldn't admit to it even at that point. To find the truth, she sat down with each development manager and said, “We've got six weeks until your deadline. Can you give me a week‐by‐week description of the work you have left to do?” During these meetings, three of the four managers had to admit they were dangerously behind schedule. Although they were 75 percent through the project schedule, the managers were able to finish their portion on time by turning all their developers onto this project.
This near‐disaster illustrates the importance of questioning schedule status when the work is not broken down into small, detailed tasks. The primary tool for illustrating a schedule is also good for displaying schedule status. Figure 19.1 is a Gantt chart showing schedule progress.
Notice that the focus here is on displaying schedule status. You will use project status meetings, as described in Chapter 16, for capturing actual task completion status. The real truth about schedule status is often elusive because it is hard to pin down what proportion of a project is really complete. The following tips are commonsense ways to get the most accurate picture possible of a project's progress.
A project manager should always be suspicious of work package status that is reported in detailed increments, such as 12 percent, 35 percent, or 87 percent, unless there is empirical basis for this amount of detail. When possible, use the 0‐50‐100 rule for recording schedule completion of tasks that span no more than two reporting periods.
Using this method, as long as the work packages are small, no task will have 50 percent completion for two status meetings in a row (because the maximum time to complete each task is no more than two reporting periods).
Every work package is supposed to have completion criteria (see Chapter 9) and should not be considered 100 percent complete until it meets these criteria. You need to be rigid about this—if tasks are consistently allowed to register as complete before all the final details are taken care of, the project might fall far behind, even though the official status reports it as being on schedule.
Schedule completion measures accomplishment, not effort expended. Just because you've used up 50 percent of your labor budget doesn't mean you've accomplished 50 percent of the project. Schedule status is a measure of whether you've accomplished as much to date as you had planned to.
Management by exception is a seductive method for keeping the project on schedule that, in many cases, can actually increase schedule problems. Management by exception focuses on keeping critical path tasks on schedule while ignoring noncritical tasks that fall behind their scheduled start or end dates. Although it may be true that tasks that have float can continue to be delayed until they run out of float and become critical, these delays can lead to a resource crisis at the end of the project—which is the worst time to try to accomplish extra work. The people poured onto the project at the end will have had little or no experience with the project. In addition, you will have increased your schedule risk, because a late completion of any one of the critical tasks can delay the project finish.
There is a way to measure schedule progress if your project contains many similar tasks. To begin, consider what these three projects have in common:
In each case, the portion of the total number of piles, engineering drawings, or computer programs completed can produce a useful schedule status. Figure 19.2 shows an example of a simple graph that displays this type of status. This graph can be generated by simple spreadsheet programs or project management software. These graphs can be extremely useful, but they can be misleading because they don't differentiate between easy and difficult tasks. For example, if all the easy piles were driven first, or if all the easy drawings were created first, the projects might initially show progress ahead of schedule, only to fall behind later when the time comes to handle the difficult piles and drawings.
Measuring costs accurately is critical as a project progresses because cost measures productivity. Every work package has cost estimates for labor, equipment, and materials. As each one is executed, be sure to capture the actual costs; comparing planned and actual costs will tell you whether the project is progressing as planned (see Table 19.1).
If project management is new to your firm, you may encounter plenty of resistance to tracking actual labor hours on tasks. Engineers, programmers, scientists, and other knowledge workers often complain bitterly about the lost productive hours they must spend each week just writing down their labor for specific tasks (even though experience has shown that this rarely takes more than five minutes a day). Here are two approaches for overcoming their resistance. These methods concentrate on winning their cooperation rather than forcing their compliance:
TABLE 19.1 Track Actual Costs for Each Work Package
Planned | Actual | |||||
---|---|---|---|---|---|---|
Task Name | Labor | Equipment | Materials | Labor | Equipment | Materials |
Task n | 40 hrs. | $1,000 | $1,500 | 50 hrs. | $1,200 | $1,500 |
Task p | 30 hrs. | $200 | $100 | 25 hrs. | $200 | $150 |
Task r | 60 hrs. | $0 | $0 | 55 hrs. | $0 | $0 |
Graphing cost performance usually compares the projected expense over time to actual expenses (see Figure 19.3). That's useful information, but this kind of graph has some potential drawbacks:
Comparing planned cash flow with actual cash flow has its uses, but it doesn't tell you whether the project will be over or under budget. To find the true picture of cost performance, the planned and actual costs for all completed tasks need to be compared. This is accomplished with a technique called earned value reporting. Earned value reporting uses cost data to give more accurate cost and schedule reports. It does this by combining cost and schedule status to provide a complete picture of the project. For example, projects can be ahead of schedule (good), but over budget (bad). Or they can be ahead of schedule (good), and under budget (good). Altogether, there are five possible combinations when you include “on schedule and on budget” (see Figure 19.4). As this diagram shows, project managers who track only cost or only schedule are getting only half the picture and won't really know if their project is in trouble.
Tracking cost with earned value introduces some new terms:
Figure 19.5 shows an example of using earned value both to measure cost performance to date and to recalculate the budget.
Not long ago, only the U.S. Department of Defense (DoD) used earned value to manage projects. Now the practice has spread to large and small commercial firms as well as the civilian agencies of the federal government. Through increased use, the terminology is beginning to change. Although international standards organizations still promote use of the preceding terms, the Project Management Institute (PMI), based in the United States, recommends substituting the following terms:
Firms that want to be aligned with PMI terminology and individuals studying for one of PMI's certification exams should take special note of these terms.
Recalculating the estimated cost at completion using earned value implies the current trends will continue. But be careful not to assume that just because you are over budget now that you will be granted more budget. Instead, the cost variance should be used as a warning flag to help you identify problems early, when there is still time to get back on track.
Is the project on schedule? This is a question that all the stakeholders want answered. But it can be difficult to measure the degree to which a project is ahead or behind schedule. What if the majority of tasks are on schedule, but a few are ahead of schedule and others are behind? What is an accurate description of this project's schedule status? In this kind of situation, earned value calculations can help measure schedule variance just as they help in measuring cost variance. Calculating schedule variance uses some of the same concepts as the cost variance calculation. (Substitute PMI terminology here as well.) These are:
Using the cost figures as the basis for schedule measurement is useful because it takes into account the number and size of tasks that are behind schedule. That means if 10 concurrent tasks, each worth $10,000, are all one week behind schedule, the schedule variance will be larger than if only one of those tasks is one week behind schedule.
There is no more accurate presentation of a project's cost and schedule performance than earned value charts. Not only do they show the cost and schedule status at any given date, but they also indicate performance trends. Figure 19.6 shows an earned value chart.
An executive with 10, or even 100, projects under his or her control can use the kind of graph shown in Figure 19.4 to pinpoint the cost and schedule performance of each one. This will help to determine which project demands the most attention.
Agile methods strive for simplicity and clear communication. The burndown chart in Figure 11.2 uses two axes, scope and time. The scope is measured in points, which also equate to effort. Therefore, the Plan line represents the value of the work that will be accomplished over the sprint. That is the same as Budgeted Cost of Work Scheduled or Planned Value. The Actual line on a burndown chart represents scope accomplished, which is the same as Budgeted Cost of Work Performed, or Earned Value.
The example in Figure 19.5 shows how simple it can be to use earned value metrics to report progress. Unfortunately, many firms trying to apply earned value practices find it much more confusing. If you've read the previous chapters in this book and are practicing the discipline as it is described here, earned value metrics are practically free. In other words, if you have a detailed plan and capture actual performance data, the earned value calculations become easy. What follows here are some hard‐won insights on applying the earned value reporting methods on projects.
The secret to making earned value work is in the work breakdown structure (WBS). Each task on the WBS must be a discrete task that meets these criteria:
If you've applied the guidelines in Chapter 9, your WBS will probably enable easy earned value reporting. The problem occurs when the WBS contains one of these mistakes:
What does a CPI of 0.95 really mean? If my SPI is 1.1, what should I do? Although we've defined the basic terms of earned value analysis, we still need to make sense of the numbers in the context of our project.
The projects that benefit most from earned value will have the greatest challenges implementing it. The larger the project, the more difficult it is to understand all the parts and to stay on top of cost and schedule variance. That's why these practices were invented—to manage huge defense programs. Putting the infrastructure in place to generate honest data on a routine basis is a formidable task on a major project or program—but the alternative is even worse.
Interpreting Earned Value metrics and making the calculations are certain to appear on the PMP Exam. These are covered in the PMP® Exam Prep bonus video Earned Value, which is found at www.VersatileCompany.com/FastForwardPM.
While the project team has the authority to solve certain problems, others need to be escalated to higher management or may even demand the direct attention of senior management. The determining factors for who handles a problem or approves a solution are its cost and schedule impacts. Escalation thresholds represent preset variances that signal the severity of a problem; these thresholds are set during the planning process. The communication plan developed early in the project and described in Chapter 16 contains a description of the cost and schedule escalation thresholds (see Figure 19.7).
Thresholds accomplish several important functions:
A baseline is a comparison point. Cost and schedule baselines represent the original project plan as approved by the stakeholders. Ideally, a project should never vary from its original plan, so a comparison between actual performance and the baseline would show no variance. But in reality, this zero variance never happens. Even though everything may not happen according to the plan, however, many projects do meet original cost and schedule goals. Keeping the baseline cost and schedule goals visible is one way of holding the focus on the original goals, even when changes start to happen. Earned value reporting, as shown in Figure 19.6, is one way of keeping this vital information visible, because it emphasizes variance from the baseline. A Gantt chart may be used to focus on schedule variance alone (see Figure 19.8).
The baseline is more than just a starting point; it also represents the accepted cost‐schedule‐scope equilibrium on the project. The project team is committed to meeting the baseline and should assume it will continue to be held to the baseline, unless otherwise directed by the project manager. Consider the following example.
The BoxBetter project had been stuck about two weeks behind schedule for a month. The project manager had tried several ways to catch up, but none of them were working. At this point, Terry and Madison, who spent about a quarter of their time on the project, gave up on bringing the schedule up to date and decided to turn their attention to other projects. Although the schedule for BoxBetter called for them to complete a task prior to the next status meeting, neither of them worked on the task. At the meeting, Terry and Madison were chagrined to learn that the other project team members had done extra duty to bring the project back on schedule. Their task was now the only one that was late—and others were waiting for them to complete it. In this case, Terry and Madison had mistakenly assumed that the baseline for the project had changed.
Changing the baseline, however, is a big deal because it represents a new cost‐schedule‐scope equilibrium. This new equilibrium requires approval from all the stakeholders. If the justification for the change is good enough, meeting the new baseline might even be considered a success. Other times, however, it simply represents accepting a new reality. If all the evidence suggests that the project will miss the original cost and schedule goals, then it probably makes sense to change them. Maintaining unrealistic goals is rarely motivating. At the same time, however, the baseline must be changed cautiously and honestly, because it affects motivation if the baseline is changed over and over again. The new baseline should be as realistic as possible, reflecting the level of performance that led to the baseline change.
It's surprising how many projects never really know their status until they get close to the deadline, when they have no hope of finishing on time or on budget. There's no mystery to measuring progress accurately; all you need is a detailed project plan with cost and schedule estimates for each work package. But it does require disciplined, systematic attention to the details. It is this attention to the details that enables the project manager and team to spot the problems early, when they are still small and there are still good options for solving them.
The financial analysts on Wall Street wouldn't stand for companies releasing quarterly or annual results based on gut feelings; they demand hard data to show quantifiable results. It's time every project was held to the same standard.
Answers to these questions can be found at www.VersatileCompany.com/FastForwardPM.
3.133.157.142