Predicting the Future
My earlier post, Our Biggest Unused Weapon, posited that the ability of even a basic earned value management system (EVMS) to predict when a project will be complete and how much it will cost at completion is unparalleled in the management information system world. But I also argued it was being under-used by most practitioners.
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.
|Glen B. Alleman|
|Dr. Azhar M. Khan|
|Ray W. Stratton, PMP, EVP|
|Mark Lester Dy|
|N. Gopi Krishna|
You need to know the amount of time passing to ascertain a value at a point in time (absorption rate versus units). That being said, could anyone tell me the relationship between the end-product of the EVM process and a pro forma, as produced in real-estate and construction?
Historically, I have seen pro formas used for assessing the feasibility of projects with input of all the known -- at a conceptual phase -- financial factors playing out over the time of the project. It is a technique used to build a business case.
EVM seems to be the same thing, only during the actual implementation stages, with generally known processes and units. Anyone care to comment? What are the likenesses, what are the differences? Thanks.
Editorsâ€™ note: on June 8, a few commentersâ€™ names were lost due to human error. We deeply apologize.
Please Login/Register to leave a comment.