William Goelkel, PMP, responded with:
"EVM can lead us to make bad decisions, or forecasts, when the standard against which we measure everything is the plan we baselined at the point in the project's life cycle when we were most ignorant of its requirements."
"I'm not convinced a calculated EAC [estimate at completion] as you described is always useful."
I'd like to further my arguments to the contrary while responding to Mr. Goelkel's thoughtful comment.
Mr. Goelkel's main example concerns software projects, where "goals change and our understanding of the users' needs evolves." Either this understanding evolution is captured formally and introduced into the baseline, or it is not. If it is, then there's no problem. If it is not, then we have scope creep, the most pernicious attribute of managing projects.
Even so, EVMS have a remarkable ability to predict the future, even when the baseline has been turned to rubber.
Say you had a US$100,000 project, but "evolving" customer expectations will end up costing the contractor double that, or US$200,000. At the point that the project should be half-done (cumulative budget = US$50,000, and actual costs are at the same level) the task leader assesses that she is only 25 percent done. The calculated EAC will instantly indicate the real EAC of US$200,000, allowing for either elimination of the scope creep or a request for more money.
For a more real-world example, try to find a project that (impishly) has a "Project Managers' EAC" column right next to the calculated EAC in their cost performance reports.
Ninety-nine times out of 100, the project manager's version is lower than the calculated one and less accurate. It's like clockwork.
In my next post, I'd like to tackle how project management trends in the software world--like scrum or Agile--are actually attempts to accommodate the rampant scope creep that so often afflicts those projects.
For now, I'd like to hear what other EV practitioners have to say. I'd also like to thank William Goelkel for this discussion.