Project management's not-so-odd couple

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.

About the Author

John Zyskowski is a senior editor of Federal Computer Week. Follow him on Twitter: @ZyskowskiWriter.

Reader comments

Fri, Feb 4, 2011
chris
Wash D.C.

Good info and perspective. Certainly EVM is adaptable to agile. EVM measure budget and schedule achievement but does not truly measure scope realized and its business value. How often have we heard the refrain when meeting with users at the end of the development cycle .... "I know that is what I told you I wanted but that is not what I really want." We can only guess how much scope is achieved and how well that satifies the value proposition. Schedule and budget are proxy values that do not measure those attributes. A value proposition of agile that is often overlooked is the realized scope has a much higher probability of increasing the business value of the scope implemented.

Wed, Jan 26, 2011
Linda M Cook

One of the other factors to consider when comparing EVM to AgileEVM is that agile practices support completing the most valuable features/functionality as prioritized by the business leaders. Properly executed, a project using agile methods should deliver more value earlier than a similar project using traditional waterfall methods.

Fri, Jan 14, 2011
Glen B Alleman
Denver, Colorado

Good article. A bit of care is needed though. Requirements do emerge but the end-to-end baseline budget needs to be maintained in some way.
Rolling waves provide for emerging requirements. The measures of physical percent are a nice match with "working software" or working anything for that matter.
The "trick" is to align the work packages and control accounts inside the rolling waved with the iterations of the development process. St that point there is no difference between agile and EVM based development - "in principle."
Finally the "water fall" process is no longer allowed in DoD I 5000.02, IMP/IMS is an iterative and incremental approach that should be applied in the software world as well. It defines Events, Accomplishments, and Criteria that have nearly identical outcomes to Scrum's processes.
Glen B. Alleman
VP, Program Controls
Aerospace and Defense

Fri, Jan 14, 2011
Tamara Sulaiman Runyon
Boulder, CO

I agree 100% with your Scrum team not using the % complete technique! When we use AgileEVM, we are measuring at the release plan level. We found that measuring at the sprint level did not provide valuable data. Our PV for the is based on dividing the number of sprints completed in the release plan by the total number of sprints planned for the release, multiplied by the Budget at Complete (planned $). We did not "lock" the story point value of each story for a number of reasons. Hopefully this comment is helpful. Feel free to contact me directly if you'd like to talk about how we've implemented AgileEVM. Also, there is a tool and website available on AgileEVM.com (note: I have no financial interest in these) that you might find useful. -- Tamara

Thu, Jan 13, 2011
Bob
Wash, DC

Good article. My Q is using 0/100 for each Story in our 2 week sprint. We get some wild fluctuations of SPI & CPI and end up preparing time consuming Variance reports. The Scrum Team will not consider using the % complete EVM technique. Also for the 2 wk sprint we are locking the PV value of each story unless there are instances where MR (Scope & Budget) are needed (per ANSI req) to finish the story. In those instances I allow the PV value to be adjusted by the MR amount. COMMENTS?

Please post your comments here. Comments are moderated, so they may not appear immediately
after submitting. We will not post comments that we consider abusive or off-topic.