There is a conjecture floating around that simplistic and simple are the same thing. That making something simple means making it better. My favorite example is Michael Hatfield (his on our minds these days because of a recent PMI Blog post about the dangers of statistical risk management).

Going back a bit, Michael postulated in another PMI Blog and in front of a gathered audience at EVM World 2009 that the Estimate At Complete formula found on the DAU Gold Card can be algebraically reduced to a simpler form.

Here's the algebra in excel:

Now of course the algebra is correct. You can reduce the EAC formula from the one on the Gold Card to the simplistic version on the right of the picture above. That one (as Micheal points out) says

EAC = ACWP / % Complete

Which in English says the Estimate at Complete (EAC) is Cumulative (time phased to date) Actuals (actual cost) to date (ACWP_{cum}) divided by the percent complete. Yep both the calculations match.

The Gold Card version says

EAC = ACWP

_{cum}+ [(BAC - BCWP_{cum}) / CPI_{cum}] = BAC / CPI_{cum}

where

CPI = BCWP / ACWP (Cost Performance Index)

So the numbers match. You get the same EAC with both the Gold Card and the simplistic version.

**But What's Missing?**

Well nothing if you use EV to report a number to someone at the end of each month. Pick the simplistic one and get back to work.

But if you use EV to "manage" your program, provide actionable insight to the behavior of the work effort, or anything along those lines, you've masked critically important details in the simplistic approach"

Simplistic ≠ Simple

What's missing is

- Visibility into how BCWP was derived.

The one and only true definition of BCWP is BCWP=BCWS x Physical Percent Complete

Without this , the EAC formula has hidden the measure of the very processes used to compute BCWP.

"What does done look like, in units of measure meaningful to the stakeholders."

- Percent Complete is not the same as Physical Percent Complete. This is a core reason why MSFT Project cannot do EV out of the box. Percent complete is "time" percent complete. 50% of the time has passed, so we must be 50% done with the project. This approach is simplistic and a show stopper to any credible assessment of project performance using EV

- The planned physical percent complete at a planned point in time must be defined before the work starts.
- The tangible evidence of Physical Percent Complete is then used at the planned point in time to confirm the actual progress to plan.

- The EAC calculation used in the simplistic formula does not contain "Earned Value," just actual cost. The cost to date. No mention of the "value" produced to date. Just the money spent needed to arrive at this percent complete in time.

- This says - "well I spent 50% of the money, so I must be 50% done at this time."

As Dr. Phil would say *hows that work'in for ya? *Probably not that good from my experience.

Paul Solomon has kept us informed on Congresses efforts to include measure of quality in the Earned Value Management processes. The briefings being prepared for EVM World 2010 by our firm and our partner firms, including Paul, all speak to the inclusion of Technical Performance Measures as the basis of credible management using EV. One of our speaking partners "invented" TPM while serving as a PEO for NAVAIR.

**So Here's the Point**

If you don't know how you arrived at percent complete, how you arrived at BCWP (the value earned on the planned day), and how these variables are related, then you've got a simplistic formula for Estimate At Complete alright. Nice and simple, er simplistic.

But you've got no real information about how your program is performing at the physical progress level, other than you're spending money and time is passing. This may be all you need to know. Maybe not.

This information - data really, not information - says that the passage of time and consumption of money is a measure of progress to plan. This is literally true for Level of Effort projects. These are called "train watching" projects. Not all that useful for discrete development projects, where the relationship between time, money, and technical performance is usually complex, non-linear, and many times probabilistic.

Do Not Confuse Simplistic with Useful, it'll bite you every time.