The Big Ol' Switcheroo

 

When the US Department of Energy first came into existence, their guidance on performing project management was pretty much the same as the rigorous version used by the Department of Defense. However, it didn't take long for those requirements to get watered down via DOE Order 4700.1 and 4700.5, which implemented a so-called "graded approach." This graded approach spelled out the circumstances under which certain projects could opt out of certain aspects of the project management requirements, based primarily on the complexity and risk profile of the specific project. As soon as the new requirements came out -- wouldn't you just know it? -- a whole bunch of projects that had previously been considered appropriate for complete PM implementation were suddenly asserting that they were, actually, very simple, with low risk profiles! A veritable avalanche of arguments against projects having to comply with the complete set of PM requirements ensued, the vast majority of which were completely bogus. I was even involved with a project where the project manager sought to have his project renamed as a program, since programs, per se, were not required to obey the previous rules, only projects.

Flash forward to the Summer of 2009. Based on the release of my first book Things Your PMO Is Doing Wrong (PMI Publishing, 2008), I had been invited by PMI®’s Information Technology Special Interest Group to do a webinar on the difficulties of performing traditional project management techniques in an IT environment. The webinar, entitled “Stop Those Divorce Proceedings! Performing Earned Value Analysis in an Agile/Scrum Environment” was well-received, but I came across some disquieting factoids while I was doing my research. Of course, the frequency with which software projects come in over-budget and late is such that poor performance against their baselines had already become axiomatic. But, since 1986, when Hirotaka Takeuchi and Ikujiro Nonaka  published the seminal work that would form the basis for Agile/Scrum project management, the efforts to streamline project management to rid it of its more restrictive aspects in order to make it useful in an IT environment has led to a few “graded approach” moments which, in turn, threaten to return software projects to their days of persistent overruns and delays.

Take, for example, the aforementioned use (or lack thereof) of Earned Value Management Systems in IT projects. There is a myth, perpetrated by those who don’t like or understand project management in general and Earned Value in particular, that EV “requires” the existence of highly-accurate time-phased budgets, known in the EV world as “Planned Budget,” or, for us old-timers, the Budgeted Cost of Work Scheduled. Without these well-estimated and time-phased budgets, say the ignorant resistors, all subsequent Earned Value analysis is rendered useless. This lie is tailor-made for those who seek to avoid having to do any PM at all by asserting the Agile/Scrum approach. When, they ask, we are in the middle of a scrum, and the scope baseline has been changed and approved, does anyone have time to perform a bottoms-up estimate of the new scope? Isn’t that why Agile/Scrum was invented in the first place – to avoid software development teams having to stop work to formally reset the baselines in order to comply with some stodgy, old PMBOK Guide®-recommended requirement? Surely it’s best to eschew (actually, these Visigoths would never use a word like “eschew,” but hang with me) all Earned Value Methodologies for this work, and subsequent projects like it!

The truth here is that Earned Value does not need a highly-accurate time-phased budget to return extremely valuable management information. In fact, in those instances where the work has been woefully mis-estimated, Earned Value is the best analysis to uncover the error. Say you had a task that has been estimated to cost $100,000 (USD), but the more appropriate cost estimate would have been twice that. The task gets underway. At the end of the first reporting cycle, your project controls analyst asks your overall percent complete, and you inform her that it’s about 25%. However, your project controls analyst collects your actual costs, and they come in at $50,000. Using the traditional formula for calculating an Estimate at Completion, :

EAC = (BAC / CPI)

where BAC is the budget at completion ($100,000) and CPI is the Cost Performance Index (Earned Value divided by Actual Costs; in this example, 25,000 divided by 50,000, or 0.5), she instantly knows that this task will most likely cost $200,000 – which is what a perfectly prescient estimator would have known beforehand.

Okay, but what does this have to do with Agile/Scrum, and costing the change that was introduced in the middle of the last Scrum? The previously shown formula can be algebraically reduced to:

EAC = ACWPcum / % Complete

where ACWPcum is the cumulative amount spent on the task. In the example, $50,000 divided by 25% also produces the $200,000 amount. Simply ask the Task Manager to estimate his percent complete based on the expanded scope, and divide that figure into the altered task’s cumulative actual costs, and you have the new estimate, ready to plug into the cost baseline.

This is but one example, but there are many others where traditional PM techniques may be compromised safely, and others that cannot. How to differentiate? For that, the insightful reader will want to order my recently-released, must-have book, Game Theory in Management, and I look forward to y’alls’ comments.