Earned Value Management (EVM) is a management methodology for monitoring and controlling schedule, cost, and scope. It allows management to measure and track project execution and progress. In 1997 the U.S. Office of Management and Budget (OMB) released the Capital Programming Guide, which since then requires the use of EVM for all contractor performance-based management systems. This guide is an appendix to the OMB’s Circular A-11, which provides guidance on preparing Fiscal Year (FY) budgets and contains instructions on budget execution. This means that all budget approvals depend on performance as measured by EVM, behoving government contractors such as Raytheon, Boeing, Lockheed Martin, General Dynamics, Northrop Grumman, and others to adopt EVM as part of their standard management practices. EVM evolved from the DoD Cost/Schedule Control Systems Criteria (C/SCSC) which was an early attempt in 1967 to standardize contractor requirements for reporting cost and schedule.
The problem with comparing actual expenditures to baseline plan, which is what other project management techniques do, is that it ignores the amount of work “actually completed.” EVM addresses this by distinguishing between cost variances resulting from progress deviations due to either over or under-spending. The approach compares the planned amount of work with what has actually been completed, at any point in the project. This is used to determine if cost, schedule, and work accomplished (percent of scope completed), are progressing as planned.
The implications of this, in the software development domain, is that software project management boils down to the monitoring and control of what the three sides of are essentially the “Iron Triangle” – key project performance data points are collected to answer a basic set of questions related to the current state of the project, as listed in Table 1.
After this data is collected it is then used to derive some key project performance indicators, some of which are listed in Table 2 below.
These indicator metrics are inspected at regular intervals to spot trends, take corrective actions, and ensure that a project is on track. Figure 4 below illustrates the tracking of EVM metrics over time.
Organizations that have traditionally practiced this EVM style of project management have paired it with a “Waterfall” approach to engineering and CMM-inspired processes. While EVM might at first seem complicated or hard to grasp, it is essentially a formal technique for understanding:
· Is work being accomplished as planned?
· Is it costing as planned?
· What is the remaining work likely to cost?
· When will the project be finished?
When management periodically takes time to focus on these questions and takes corrective actions to steer the project back on course when there is a deviation from the plan, EVM is reported to provide a powerful mechanism for large-scale project control. However, in the software engineering realm there are two big problems with EVM:
1) Controlling a project to-plan requires a full up-front plan. This means that the scope of the project must be fully understood, specified and planned up front. Any later changes in direction are regarded as scope changes and must go through a formal contractual change process. The plan cannot evolve and change as new information or insight is gained. Re-planning (“reprogramming” in project management speak) is a difficult affair in EVM. In other words, a rigid plan is not an Agile plan and thus takes away from the project’s potential for “nimbleness”.
2) EVM milestones are arguably arbitrary. For example, EVM claims a significant portion of “earned value” on a development project after the requirements and the design phases are completed. A project can thus claim to be at 50% completion even though no code has yet been produced. On the other hand, as we will discuss in later chapters, Agile projects track progress by feature: project percent-complete is more accurately tracked based on number of features completed. This is also a more valuable customer proposition, as 50% complete means that they can potentially receive a software delivery with 50% of the functionality already in it.
Agile project management techniques are by comparison light-weight, but focus on some of the same project performance questions (is the work progressing as planned? Is it costing as planned?) using mechanisms such as ‘sprint burn down charts’ (monitors how much work is remaining in one sprint) and ‘team velocity’ (how much effort a team can handle in one sprint).
We feel that EVM and Agile project management are not at odds and in fact can be mostly complementary. What would be needed, for Agile and EVM to coexist is Agility on the management side. Management must be able to practice what is known as “rolling wave planning” on a near-continuous basis. For example: plan only a month or so ahead of time, thus allowing for a greater degree of flexibility in the project plan (or more specifically, the Performance Management Baseline – PMB) against which performance is measured.
