That led me to poke around Google Reader for Earned Value blogs in case I had missed someone. I came to John Rusk's paper on EV and Agile. The link to Mike Griffth's nice blog with a post on Earned Value.
And then I came to the phrase...
Despite its usefulness, the confusing terms and heavy use of maths puts off a large percentage of the population.
Let's see if I understand this. "Heavy use of maths." Algebra with two (2) independent variables (BCWS - Budgeted Cost of Work Scheduled and ACWP) - Actual Cost of Work Performed) and one dependent variable - BCWP (Budget Cost for Work Performed) is considered heavy by a large percentage of the population. By large I naively assumed > 50%.
Yikes, this EVM stuff is complicated! Really? Is this really true? Were > 50% of the people working in project management or software development asleep in grade school arithmetic?
And then I encountered...
Debates digress beyond numerical accuracy - More challenging still is when several people do understand EVM and start debating which versions of the formulae to use and everyone starts obsessing on the math instead of the project. “Should we use EAC = BAC/CPI, or EAC = AC + ETC, or EAC = AC + [(BAC-EV)/CPI ?” Geez people, the developers probably pulled half of these estimates out of the air and we are applying advanced math to them?
That would be a NO. There are three (4) and sometimes four (4) formulas for ETC (Estimate To Complete) and EAC (Estimate At Completion). Which one to use? Use them all. One is optimistic, one is pessimistic, the others are in between.
I'd suggest looking through Dr. David Christensen's bibliography at the EAC and ETC topics to see how this is handled.
If you hold a PMP you need to know this. If you are employed in the program controls world or are a CAM (Control Account Manager), you better know these or start looking for work else where. Same for project's subject to SOX.
And if you're a credible Project Manager and you let your staff "pull estimates out of the air," you need to look for a new job. To invert the quote - Geez, can people be that stupid to proceed in the presence of bad estimates - no wonder IT projects fail.
But more importantly, if you work on a project where you are spending other people's money, you must be able to answer the following questions to be considered credible:
- What is this project going to cost when we're done - within some error margin?
- When are you planing to be done with this projects - within some error margin?
- How much progress toward DONE have you made so far - in tangible units of measure?
- How much more work is there to go toward DONE - in tangible units of measure?
The answers to these questions establishes the credibility of the project management team - no matter if they are formal DoD Program Managers or a Scrum Master with her team.
Using Earned Value with Scrum
Scrum and Earned Value are bedfellows, with some simple assumptions. First they both answer the questions above. But there are some assumptions that must be made for Scrum to answer correctly:
- Is a Total Allocated Budget (TAB) established somewhere, by someone? What is the "Not To Exceed" (NTE) budget for this project? Some has to know this.
- The total set of deliverables for the project also needs to be known. If not, the project is considered Level of Effort (LOE). On LOE projects, the passage of time and consumption of resources (money) is the measure of progress. This is sometimes called "Train Watching" after the German Railroad system of having crossing be "watched" by a person in a shack, to lower and raise the cross barrier.
With these answers in hand, Scrum can partition the work across the planned iterations and define the planned deliverables for each iteration. This is successful when the project is close ended, just like the definition of the project says it is when you read PMBOK®
Some now we've "connected the dots," back to Mike's post.
What’s the value in tracking progress against a flawed plan? - EVM compares actual project performance to planned performance at a point in time. So, if our initial plan is wrong we could be effectively trying to do the equivalent of tracking our progress on a road trip from Calgary to Salt Lake City on a map of France! The quality of the baseline plan is a critical success factor of EVM. In agile projects we acknowledge initial plans will likely need changing and so the basis for effective EVM is quickly eroded with evolving plans.
I have a suggestion , get a credible plan. Use Scrum's planning process for this. The olde saw, works here...
Doctor, doctor it hurts when I do this (raising his arm). Then don't do that.
Come on folks. We had a predilection for poster (banners) campaigns at a large DOE program I worked a few years ago. One poster read...
Don't do stupid things on purpose
If you don't have a credible plan to get to DONE, a credible "not to exceed" budget, some credible set of processes that will be used to get to DONE? You're doing stupid things on purpose. Stop
Finally
Where’s the Quality? - We could be on time and on budget, but building a horrible product that the business does not like or is low in quality. We should be aware that cost and schedule are not the whole picture. EVM and agile alternatives are just a part of the picture.
Mike has hit on an important topic. The connection between Cost, Schedule, and Technical Performance Measures (TPM). Here's a training briefing from the College of Performance Management, on this critical topic.
View more presentations from Glen Alleman.
Finally a Cruel Irony
I find it ironic and amusing that “Earned Value” is a traditional project management term and agile projects often track progress in nebulous “Points”. This is backwards. Agile projects deliberately relate things back to real business value, and yet many traditional project track progress against tasks that add little or no business value and call the process “Earned Value”.
This another of those uninformed blanket statements. The "value" in Earned Value is not the same as the "Value" in business Value. Several VERY highly regarded agilest have made this same flawed assumption.
The Value in Earned Value is the consumption of the budgeted cost for the item being produced. The Budgeted Cost for Work Scheduled (BCWS) is the planned cost for that item. The Budgeted Cost for Work Performed (BCWP) is the measure of the consumption of this budget as a function of time.
We budgeted $100 for the item. The items is "worth" $100 when we are 100% done.
We planned to spend $100. We completed on-time and on-budget and consumed our $100. We're golden.
What's the business value of the $100 item we just completed on-time and on-budget?
This is not the role of Earned Value. This is the role of the business plan, it's ROI calculations and its connection with the business strategy.
OK, The Final Final
Creating a detailed requirements document that formalizes an incomplete, premature view of requirements that should change as details emerge and business continues to evolve is not earning much value at all. Yet prioritizing features by business value and tracking progress against the business oriented features is an excellent example of real “Earned Value”.
This is COMPLETELY dependent on the domain and context. If we're building a flying machine like this real one we work. Then having on incomplete, premature view of the requirements is called PDR (Preliminary Design Review). The program can't wait for the complete design. It needs some Rough Order of Magnitude (ROM) of the design. See Page 36 of the presentation above.
It seems there are assumptions being made about how EV and Agile are connected, possibly in the absence of knowing how EV actually works in practice.
