Project management's not-so-odd couple
- By John Zyskowski
- Jan 12, 2011
It took a few years and regular prodding by the Office of Management and Budget, but earned value management has finally become a standard tool that agencies use to track the performance of their technology development projects.
EVM has helped straighten out more than a few faltering projects before they could really go bad, but that hasn’t been enough to give government a perfect track record on delivering new systems on time and on budget.
Now OMB and a number of other agencies have a new idea for stacking the odds of project success in their favor: agile development, which brings a more modular, flexible approach to projects.
At face value, EVM and agile development seem contradictory, but they can not only coexist but also actually make each other better.
It’s not hard to see why there might be some confusion. EVM — and the so-called waterfall style of system development that it’s often paired with, especially in government projects — embraces the maxim “plan what you do, and do what you plan.”
With EVM, managers are supposed to define a project’s scope in great detail at the outset and develop a schedule and budget to make it happen. Once the project starts, EVM uses that baseline plan to compare the value of work completed against expected progress and actual costs on an ongoing basis, usually quarterly. That helps managers catch cost or schedule deviations early and presumably fix them before they get out of hand.
Agile development rejects the idea that one can determine upfront every feature a new system should have — especially if a project might take years to complete because user requirements and priorities will likely change in that time. Instead, project managers using agile development start with only a high-level definition of the project’s requirements — and, of course, a schedule and budget. They refine the requirements as developers build chunks of functionality in a modular process, based on regular testing and feedback from those who will use the system when it’s done.
Studies show that agile development is faster and can deliver an end product that’s more useful than the waterfall approach can. But does it pull the rug out from under EVM as a project management tool?
Tamara Sulaiman, an agile development coach and trainer, explored that question in a paper she published in 2006 with Brent Barton and Thomas Blackburn. They proposed and tested a method called AgileEVM, a simplified set of earned value calculations adapted from traditional EVM using scrum metrics. Scrum is a popular form of agile development.
They found that they could follow EVM techniques using metrics already generated during the scrum process, so it didn’t add any new tracking work. Moreover, they showed that EVM not only applies to agile processes but also introduces a useful cost-efficiency analysis that agile practitioners typically don’t generate.
“We discovered as we started using this that we can run what-if scenarios based on using the AgileEVM calculations,” Sulaiman said. “If I have trade-offs about what changes to make to our backlog of features still to be developed, I can see what the impact will be to the project as a whole if I make certain changes.”
But what about agile development’s fundamental principle of regularly recasting system requirements based on user feedback? Isn’t that rebaselining a project, and doesn’t constantly shifting that finish line make EVM’s progress reports less reliable?
Reprioritizing which features to work on á la agile is not the same as rebaselining from an EVM perspective, said Larry Albert, president of the health care division at Agilex Technologies, which specializes in agile development.
“In the agile world, I’m still locking down my schedule date, my delivery date and my budget,” Albert said. “My requirements, also known as my priorities, are what ebb and flow as I go down that path marching against that budget and schedule.”
EVM becomes even more powerful in the agile context because project status updates come every few weeks, which is the duration of agile iterations, or sprints, as opposed to the typically quarterly EVM updates with traditional waterfall development projects.
Although hard-core agilists used to scoff at the old-world roots of EVM, Sulaiman said that attitude is changing fast as evidence of EVM’s applicability and value to agile processes grows.