EVM, the SPI, and the ALAP BCWS Baseline
Stephen Devaux
President, Analytic Project Management; Author, Instructor, & Consultant
by
Stephen Devaux
I am currently on vacation. But when I found myself with internet reception this morning, I decided to go into LinkedIn. There I got into a discussion about EVM—or more precisely, the Schedule Performance Index (SPI).
?
I spend two chapters in my book Managing Projects as Investments: Earned Value to Business Value discussing just what earned value is:
?
So here goes:
Imagine you are a PM for a contractor managing a project that is 20% complete. A schedule overrun will be very costly to your client. As a result, the client inserted a clause into the contract that if the SPI is less than .95 for two successive months, the client may terminate the contract, cease paying, and demand return of all funds paid thus far as well as liquidated damages from the contractor to defray the cost of delays.
?
This month, the SPI was .93. You have two alternatives for the coming month:
2. Complete two activities on parallel Path B, all of which total float of zero and have budgets of $150K and $100K.
?
Which path do you concentrate on?
?
And that’s the problem with SPI. It weights the work items based on budgets (which usually have little or no relationship to project duration) while ignoring the critical path which determines the project duration. As a result, SPI can be “gamed” and “artificially” raised by deciding to perform high-budget work (sometimes even out-of-sequence!) that is not on the critical path. This can substantially “goose” the SPI. In other words, it can temporarily make the project seem to be on or even ahead of schedule. But that's only for the short term. In the long term, it is likely to cause delay from which the project might never recover.
?
In the diagram at the top of this article, we see two schedules with earned value information. In the top one, the SPI is only .75. In the bottom one, it’s 1.00. But which is doing better in terms of schedule? Without critical path information, we simply don’t know. But 99% of clients who think they understand EVM will think they know: 1.00 is higher than .75! And if it’s a project with 1,000 or more work packages instead of 21, most will dig no deeper and will be comfortable that the second project is doing pretty well.
In Figure 2, we’ve included the critical paths: the red arrows right down the middle! And now we see that, while the work packages on the critical path in the first project are on schedule, the critical path on the second project has slipped two months! Now which project is doing better?
?
Of course, we still don’t know for sure. The second project is certainly delayed, and may now include some work that has negative float. But we can’t be sure about the first one. Is there?negative float now on the activities that were originally off the critical path? In other words, has the critical path changed? We don’t know for sure—and nor do the vast majority of clients who, if told that the SPI is 1.00 or higher, will explore no further.
?
But I hope anyone reading this can see that critical path data, including float totals, is essential when looking at EVM schedule reports assembled in the traditional way (i.e., based on an earned value baseline that was weighted on the EARLY dates of the CPM schedule and that allows taking of credit for work done ahead of schedule, even out-of-sequence).
领英推荐
?
Let’s take this example one step further: the way that EVM is currently done not only distorts—it encourages project managers to “game” the SPI when they’re getting beaten up for it being too low!
In Figure 3, the SPI at the end of June is .83—and the project manager is bruised and battered for having such a low number—again, despite the fact that the critical path is on schedule and we don’t know whether or not the two earned value packages that have slipped are still comfortably within their total float margins!
But what is such a project manager likely to do? After all, the client wants that SPI above 1.00!
The item on the critical path due in July is worth substantially less than those on other paths, So the project manager pursues those others—and the July SPI rises to .89, as shown in Figure 4. But what's happening to the work on the critical path? It's falling further and further behind schedule!
This shows how an SPI that is distorted by float because it doesn’t reflect critical path data (which is THE most important scheduling information!) can actually make things even worse than they’d otherwise be!
?
How can this be “fixed”?
?
Simple enough:
?
?
2. Don’t give credit for work completed before the period it’s due in—unless it’s on the current critical path! Because we do want the work on the critical path to be accelerated if possible—but never done out of sequence unless the change is first approved and incorporated into the schedule.
?
3. Finally, an effective way of recovering a slipped schedule is to take resources/budget away from items with sufficient float and to re-target them to the critical path. But the way the current ASAP SPI works, that damages the SPI even if it’s accelerating project completion!? Doesn’t it seem like that's a bad way for a schedule metric to work? ??
Steve the Bajan
Helping organisations make critical decisions, and achieve significant and lasting improvements in project delivery performance.
9 个月Good article Stephen. I agree that SPI is usually a poor measure of schedule performance Partly that's because of the problem you describe, of ignoring the difference @
Executive Partner at PMO Projects Group
10 个月SPI is a metric. Its meaning is pretty clear: the ratio of the work done vs work planned. It's the overall rate at which work is progressing against the expected in the PMB. Whether an analyst can make good use of it, depends on the quality of the analysts and of their capacity to interpret the metric and understand the implications of its value. Just like with Critical Path and floats. Looking only at the critical path is obsolete as often major threats to the schedule are found in activities that are not on the critical path. Metrics when well defined become tools that capable analysts may make good use of. Claiming a big novelty by saying that a projet SPI is above 1 but that the project schedule may be in trouble, just shows lack of knowledge. Obviously it can happen and that is not a problem of SPI but of the capacity to read it and use it. Just like all activities in the Critical Path being on schedule, and the project schedule may also be in trouble. Learn to be a wise analyst, and stop blaming the metrics.
Building Excellence in Organizational Project Management
10 个月The topic of the value of SV reminds me of my days as a navigator. When the pilots would ask me for a position update, I'd answer that there is good news and bad news. The bad news is we are lost. The good news is we are making great time! Although much of the discussions around EVMS tend to take the view of management looking at the entire project or program progress, I find it most useful at the lower levels of the project and at the early stages. After all, SV is always 1 at the end of the project no matter how late it is. The key is to act early to fix things. Steve, you reminded me once that the one thing we know for certain about every project plan at the early stages is that it is wrong. The challenge is to learn how far off it is and why. Then adjust to reality as soon as possible. Whether you are acquiring a project and measuring CV and SV by cost, or, performing a project and measuring CV and SV by resource effectiveness (e.g., staff-days of planned labor against actual and earned progress against the plan), tracking EVMS data at the work package level and making adjustments, the overall project metrics take care of themselves. The risk of plan uncertainty is managed by EVMS.
Senior Project Manager | Operations Manager | Author - I work with organizations & teams to better align their values, mission, & vision to deliver the best quality products.
10 个月Another insightful article. As I often do, I enjoy extrapolating your ideas to at least a program level of thinking. Doing so for this I wondered: 1. When an enabler project is complete, presumably, it can start delivering the value for which it was meant (e.g. a bridge built for access to allow construction on a resort island or Quick Reaction Force (QRF) actions for a natural disaster before sustained support arrives). With this being the case, is it possible to capture the immense value added already vs. looking at all the work to be done...even if the overall program is technically behind schedule? I'm assuming this is just another version of the ALAP EV model with weighted importance? 2. The main reason to undertake a project is to get a higher ROI than the total cost to complete it (a.k.a 'value'), should we consider/is it possible to calculate something like a Value Performance Index that let's us see the value-to-cost ratio of work completed vs. work to come? When I see the word 'value', it's usually indicating the cost it took to complete the task, work package, project, etc. and truly what the product or service is meant to deliver. I know it's semantics and terminology, but it can be an irritant. Ha!
MEP Projects planner at Laing O'Rourke
10 个月This discrepancy can be covered by reporting both performance percent complete and total float value.