EVMS for dummies.

Many writers stress the importance of Earned Value (EV) to program managers to help them know where they stand. This article will provide a high-level look at Earned Value, since many books and articles get into the minutiae. Like so many of my articles for Defense AT & L, this is intended simply to give you a taste and whet your appetite. Then you can look into the details if you are interested. (I certainly don't think my readers are dummies, by the way, in spite of the title!)

[ILLUSTRATION OMITTED]

Earned Value can be a powerful tool and can be a great help to the PM. So what is Earned Value? It is an objective measurement of how much work has been accomplished on a project. It compares the value of the work done with what was budgeted to do that work and what was actually spent to do it. It shows you where you're going rather than where you've been. Course corrections are easier to make when you have time to make small adjustments. It's too late to turn the ship when you're close to the iceberg--and it's the same with projects.

[FIGURE 1 OMITTED]

To measure progress on a project, there must be a standard against which to compare the forward movement. The Earned Value Management System (EVMS) establishes that baseline to measure progress. It lets you know where the project is in regard to cost, schedule, and work accomplished--knowledge that is critical to the PM and to the success of the project. Companies doing business with the government should note that the government is requiring it more and more often. And even when it is not required, EV is worthwhile.

One way to look at the process is depicted in Figure 1.

Every project should have a performance measurement baseline that looks at the budget spread over time to accomplish the scope of work, against which progress can be measured. EV is a key concept here. How much progress did the project make against the original plan? The result can be expressed in dollars or time. Figure 2 gives a sample representation of a project using EV. It's a project that has a problem somewhere.

Here's a simple way to determine where your project is using EV, and it works for cost, schedule, and even technical progress. Subtract the planned from the actual to get the variance. A positive result means that the project is ahead of schedule or under budget (depending on which is being measured at the time). A negative result means that the project is behind schedule or over budget. You can do it the opposite way (subtract actual from planned), but that, of course, reverses the meaning--negative is good. An example follows to clear up any confusion.

The Wrong Side of the Tracks

Here is a sample problem that highlights what has been said. The project is to lay four miles of railroad track. The schedule says it will be done in four months and the cost will be $4 million. If, after two months, only $2 million has been spent, how is the project doing? There is no way to tell. You need one more piece of data--how much work is complete. We'll say that one mile of track is complete. Here's how you calculate.

* With the givens of the project (4 miles, 4 months and $4 million), the EV is 1 mile of track = $1 million.

* Planned work remaining: $3 million (3 miles of track)

* Schedule variance: $1 million (1 mile of track complete) minus $3 million (work remaining) = $2 million (variance)

* The project is 66% behind schedule.

* Cost of the work remaining = $2 million

* Cost variance: $1 million (work completed) minus $2 million (money spent so far) = $1 million (variance)

* 100% overrun 

* Your estimate at completion: $8 million and 4 months late.

In other words, this project is in deep trouble. Like too many projects, it is over budget and behind schedule.

Think Small: Work Packages

For EV, you need to break the project down into smaller work packages. If you try to measure the whole project at once, it can be very hard to calculate, or the results can be misleading. By using small work packages, it is much easier to calculate, and you can catch problems earlier, giving you more time to react.

[FIGURE 2 OMITTED]

A work package is a small, well-defined, and measurable task. In this case, the smaller the work package, the better (within the limits of common sense, of course). A good guide is to use a single work breakdown structure element. The task must be clearly defined and of short duration. And finally, it must have a defined output that is measurable in some way.

There are four ways to measure progress on work packages. Three are commonly used and one is used only rarely. The three common measures are percentage, milestones, and level of effort. The fourth is apportioned effort, but since it is so rarely used, I will not discuss it here.

The percentage method can employ either a fixed percentage or variable percentage (which is not as complicated as it sounds). If it is fixed, there's a given percentage used when a task is started; certain fixed percentages when minor points or milestones are reached; and 100 percent when the task is complete. Some projects do not include the minor milestones, and then it is X percent when the task is started (and that can be zero) and 100 percent when completed. This simplifies calculations but may not necessarily give a true picture. For the variable percentages method, various percentages are assigned for each minor milestone or deliverable. For example, if the work package is the purchase and installation of a piece of equipment, it might be 20 percent when the newly purchased equipment is delivered onsite; 80 percent when installed; and 100 percent when testing is complete and the equipment is operational.

The milestone method is similar to the fixed percentage method. It is used with larger tasks or work packages. A fixed percentage is assigned to each major milestone. When that milestone is achieved, the task is considered that percentage complete.

The level-of-effort method is generally used for service-type tasks. In this methodology, the percentages are spread uniformly across the time required for the task. On a one-year contract, after one quarter, it would be 25 percent complete, two quarters, 50 percent complete, and so on. As you can see, EV is extremely simple and so not necessarily useful for service-type tasks. It doesn't tell you anything except how much of the contract time has passed--and you already know that from the calendar.

How EVMS Goes Wrong

Like any tool, EV is not perfect--but it is one of the best around. The problems come when people or projects make one or more of the following mistakes:

* Tasks are made too large.

* Tasks are ill-defined.

* There is too much level of effort rather than defined products.

* There are too many changes.

* EVMS is made too complicated.

* Managers either don't believe or ignore the results.

Look Forward Rather Than Backwards

"The really nice thing about not planning is that failure comes as a complete surprise and is not preceded by long periods of worry and depression!" according to that well-known subject matter expert, Anonymous.

EV shows where the project really is at any given point and whether the PM can be relatively assured that the project is (or isn't) on track. It is a good way to measure performance on a project and is a tool that should be used. The alternative is simply to estimate how much has been done, and that is not very accurate. The really good thing about EV is that it is forward-looking rather than backwards-looking, and it focuses management attention at an early stage when something is going wrong. What is great is that it looks at and compares everything (work completed, money spent, and time elapsed) to the pre-established baseline. So you really do have good data on where the project is.

For further and more detailed information on EVMS in DoD, see the Defense Acquisition Guidebook and the EVM Implementation Guide, which, with other EVMS-related documents, are available at <www.acq.osd.mil/pm/>.

The author welcomes comments and questions and can be contacted at [e-mail] or [e-mail].

Turk, an independent consultant with Suss Consulting, is a retired Air Force lieutenant colonel and defense contractor. He has supported information technology projects, policy development, and strategic planning projects for DoD, other federal agencies, and nonprofit organizations.