Can we integrate Earned Value Management with Software?
Yes We Can.
It's always been possible. It's been done. It's being done. Better yet, we can integrate Earned Value Management with Agile Software Development, like Scrum.
Earned Value + Agile = Success is a recent briefing at the National Defense Industry Association Information Systems Summit. This briefing speaks to the issues of DoD acquisition on the application of Agile Software Development methods through the National Defense Authorization Act, Section 804.
Prior to this briefing, the NDIA Program Management Steering Committee meeting in Fort Worth discussed how to successfully integrate Earned Value with Agile Software Development.
There are strong voices asserting this can't be done, this shouldn't be done, it adds no value, haven't seen it done, is a questionable practice. All those approaches seem to be based on "I haven't seen it work, so it can't work."
This is a throw back the the early days of eXtreme Program, where some voices - and I was one of them - claimed "I can't see how this can work in my domain, so it can't work in my domain."
Here's a recent briefing moving the discussion forward.
This briefing doesn't tell us how to do it. That's domain specific. But it speaks to what to do and guidance on what steps are needed for success. These are straight forward:
- Define what done looks like in terms of capabilities for the software. This is the vision and mission statements from the sponsors and funders of the project. We want to process transactions at $0.07 per transaction rather than the $0.11 per transactions we are doing today.
- Define a release cycles. This is a Rolling Wave and the Planning Packages for the software solution. Define the sequence of working software needed to deliver the capabilities. Each cycle provides working capabilities, just like in agile. Formal process like DoD 5000.02 have this on the SDD (Milestone C) phase. Other development processes do as well as large construction or deconstruction (D&D is one area we work).
- Define the tangible outcomes for each iteration. This is a natural approach for all successful projects. Measure these outcomes in physical evidence of compliance with Key Performance Parameters, Measures of Performance, and Technical Performance Measures.
- Define tangible evidence of physical progress to plan on fine grained boundaries. Answer the question "how long am I willing to wait before I find out I'm late?" Measure physical percent complete at some finer grained boundary to allow enough time to take correction action to actually avoid being late.
- Measure the performance of development in tangible units meaningful to decision makers. The best measure of money. "Story points" might be OK for developers, but "story points" don't show up on the balance sheet, and aren't in the Control Account Plan (CAP), and EV is not measured in Story Points. The core reason is Story Points are a relative estimate of effort, and not a quantified measure of something tangible, like money or time. Do something about this for agile projects to be considered part of the business.
- Identify impediments to progress and have a mitigation plan. Risk is how adults manage projects. Don't use the unit less blather that "agile reduces risk." Measure the risk reduction in cost, schedule, and technical performance improvements.
There is a lot more here of course, but don't believe Earned Value and software development can't be integrated, even agile software development. The excuses used by those saying it can't are just that excuses.
- Managers using EV to appear to make progress? I'm calling BS on this. EV measures tangible evidence of progress. Not measuring tangible evidence of progress to plan (agreed deliverables at the end of the iteration), then you're not doing EV. You're lying to others and your self. That's EV that's bad management.
- Not reporting actual deliverables? That's actually a violation of the Federal Acquisition Regulation in our domain. You're a felon. You're also a bad project manager.
- Listening to horror stories of how it can't work? Stop listening, go find stories of how it does work. Any fool (a lazy one at that) can find examples of stuff that doesn't work. Go look for how others made it work and learn from them. Stop listening to people who have never made it work, tell you it can't work.
- Can't tell the difference between ANSI-748B Earned Value and Business Value? Get a grip, read the guidance, do you're home work, grow up and be a real business and project manager.
There are many voices around this topic, but please focus on "solutions" not whining "I can't make this work."
