Creating an Agile Estimate for an Earned Value Management PMB

Question

Earned Value Management is predicated on the creation of a Performance Management Baseline (PMB). The PMB can be thought of as a super estimate that defines what work is planned to be done by what date and at what cost. Many companies spend a tremendous amount of time creating these super estimates since contracts are written against them, customer expectations are set against them and a project can be judged to be a success or failure benchmarked against the PMB. (And in a world of constrained budgets, underperforming against the PMB can mean death for a project.)

There are many Agile criticisms of creating this level of estimating. For example, I was listening to an old interview with Mike Cohn on the Controlling Chaos podcast about Agile Estimating. Towards the beginning of the interview he talks about the fear developer’s have of giving estimates. He said an estimate is pretty much used to beat a developer over the head with (as an attempt at “management.”) He also brought up the point that people spend too much time estimating assuming that an estimate is a firm a commitment -which it unfortunately does often get turned into.

Given that EVM is a requirement for many organizations, how can a contract be written or stakeholder expectations and stakeholder sponsorship be developed in such a way that accounts for the inherent uncertainty in the estimating process? How can PMB’s be made more realistic, while still giving stakeholders the governance they require?

Answer 1

The first thing to address is the notion that estimates are used to "beat" the developers. This is simply bad management. Mike and others use this red herring many times as an excuse for not doing estimates.

Estimating software development is an art, but also a straight forward process done all the time in complex embedded systems. Learning to produce credible estimates for development systems is independent of agile or the procurement processes.

That said the PMB usually has rolling waves, multiple CLINS, and other un-definitized work, much like agile projects. What is not usually in question is the final operational capabilities of the system under development.

The application of EVM (Earned Value Management, EV is the numbers), to software development projects is not only possible it is being done. But the effort doesn't start with agile, it starts with a credible "plan" for the production of the needed capabilities, and the definition of the level of maturity of those capabilities. This is the Integrated Master Plan / Integrated Master Schedule process.

With the IMP/IMS in place, "packages of work," - Work Packages, are defined with measurable outcomes - Measures of Performance and Measures of Effectiveness. These can be turned into to iterations and releases and agile applied.

What is the difficulty for many in agile is the notion that the end "capability" emerges over time. This is actually the case in many DoD programs as well as NASA. The System Design and Development Milestone (SDD MS C) is the style of development where "emergence" is common.

Familarity with DoD procurement is the starting point for deploying agile.