The basic principle of Earned Value starts with the establishment of a Performance Measurement Baseline (PMB) and the measurement of progress against it. The Budget At Completion is the total target for the budgeted cost for the project when it completes.
Everywhere we turn we hear about projects that are over budget, behind schedule, and are failing to deliver the promises made when the project started. This is the mantra of most IT projects. Business requirements change. Technology requirements change. Everything changes.
But for the owners of the funding source, change is not something they like to hear about when it comes to budget increases and schedule delays. The agilest will tell us as well, that the system be produced must be ready to be put into production - or at least be complete at some level of maturity - at all times. This way the customer - the one with the check book - can get something for their money at all times.
And here's the rub with most IT projects. Most projects in general. The customer has a budget. The customer has specific needs that must be there to fulfill the business case. Those needs need to appear on or before a specific time to start earned their keep for the business.
Being told the requirements will emerge along with the code that we're developing is of course little comfort to the holder of the check book, when what was planned to be delivered turns out to be less than what was delivered - even if the budget and schedule numbers are met. Most business people I've met kinda want to know when it will be done, will I be within my budget, and can I get what I need - at a minimum - to fulfill the promises I made to the board of directors.
We showed up on time and on budget, but the features you wanted - or even the features you needed for the business to work - aren't there.
So Let's Look at Some Environmental Impacts That Drive Scope Changes
- The original baseline plan left some things out.
This is a common occurrence. Happens all the time, even in very formal programs. This should actually be expected and therefore a process is needed for handling it when it does.
The first step is to establish a time when "new" items can be added. This can be an open widow, on the rolling wave boundaries, through a formal process of change management. Something that is predictable.
These changes need to be connected to the CURRENT scope of the project. They need to have a reason. The best approach is to connect the change to the business case, the Concept of Operations, or the Mission Statement. But if they expand the scope of the project, there must be another process. Otherwise the scope grows with bound and the value of EV becomes worthless.
- We've got a new way of doing the work
This is similar to the item above. No change in scope has occurred but we've discovered a better way of doing things. This of course will impact the BCWS and how we measure physical percent complete. Like the additions to the existing scope - usually more details and slight changes in the external behavior of a feature.
- The original estimates for budget and duration turn out to need "fixing"
We always learn as the project progresses from left to right. We must use this knowledge to improve the schedule baseline. This is a motivation for rolling waves. The Planning Packages in the future rolling waves have less fidelity at the task or work package level, than the current rolling wave. This is why they are called Planning Packages.
- There is real scope changes to the project from the customer
Additional scope - not just improvements in the current scope - must go through a formal change management process. This process is not, nor should ever be, an impediment to improving the project. It is a red herring from agilest to suggest that change control is heavy weight. But if we're changing the scope of the project without understanding the impact of those changes, the business value of those changes, the risk impacts of these changes, then we're no longer managing the project. We're just spending the customers money.
- The work we planned is taking longer than we planned and it is costing more than we planned
These activities can not be accommodated in Earned Value. If we're late, we're late. If we're over budget, we're over budget. The Performance Measurement Baseline must show that. Rebaselining or "rubber banding" the baseline is the beginning of the end for using Earned Value effectively.
For Earned Value to produce value for the project, baseline integrity is a must.The only reason to deploy EV is to identify variances in cost and schedule from the baseline. Fiddling with the baseline negates all the beneficial outcomes of EV.
So there is a simple and hard rule, "no messing with the baseline in the absence of formal change control." No changes to the baseline can be made to fix poor performance - period.
So Now What's the Real Problem?
- Maintaining the Performance Measurement Baseline in the presence of pressures for scope changes
- A change control system that is not burdensome, but at the same time maintains the integrity of the PMB
And in the end...
- How to actually use Earned Value in the presence of changing scope.
