Estimate to Complete versus Estimate at Completion
A recent discovery was to realize that many project managers – some of which work for me – confuse the importance of an “estimate to complete” (ETC) with an “estimate at completion.” (EAC) This is not to say they are confused about the term, its definition or any of the semantics associated with these two metrics. The confusion comes from not including all the sunk costs in the assessment of the project at the point in time of the analysis.
When asked in a project review meeting “what’s this project going to cost in the end,” the natural response is to tell us the ETC. I say this is natural because they seem to be looking forward to how much work is left on the project. This is a “natural” view since all the work in the past is just that – in the past. Why would we be interested in data that has passed under the bridge? We can’t bring that sunk cost back; we can’t recover from the mistakes of the past. Or can we? If we use EAC, then the sunk costs of the past become useful as a predictor of the to-be-sunk costs of the future.
By including the past sunk costs – with the appropriate assessment – an improved vision of the future can be produced. What was the economic efficiency of each dollar invested in the past? Did it produce a dollar of value for the project? This is the way to look at earned value – for every dollar I invest (ACWP) in this project how much value (BCWP) is returned. If it is not 1 for 1 or greater, then working harder (spending more money) will not improve the schedule. Only by working more efficiently – improving BCWP for every ACWP investment – can I ever make up schedule. Without this knowledge the ETC is a “fantasy” number. It tells you almost nothing with confidence about the future performance of the project.
Our new understanding means that project assessment must include all the past efficiencies in terms of money (ACWP) and resource productivity if I’m ever to get a straight answer to the question – “how much will this project cost in the end?” “The past is a predictor of the future,” should be tattooed on each project manager – OK washable tattoos.
The third discovery is a change in terminology for our project management methods. In our little IT shop we've used Extreme Programming for some projects. Others are pure waterfall. While still others are “herding cats” inspired. The term XP-inspired has entered our vocabulary. When we attend the local XP Group’s meetings and listen to others describe their XP processes, we wince at our feeble contributions to the discipline. We changed the words now and use XP-inspired to describe our processes. Some pair programming; lots of Unit Tests; some story cards, but also formal documents; lots of code standards, configuration management; and some attempts at code sharing. In the end we’ve made a reasonable attempt to do XP in the spirit of XP.