Some years ago, a long-term client asked us to bid on a production software project for which we’d developed a proof-of-concept. Our team estimated this new project by establishing technology and design assumptions, decomposing the work into tasks, then estimating those tasks using individual judgement. We then reconciled disagreements between the varied estimates by splitting the differences, and summed the results to create a final, total estimate.
The client liked our bid, so we planned everything and got to work.
Within the first month, however, there were issues. The first tasks took much longer than anticipated, and we’d already discovered a lot of unanticipated work. It was obvious we had big problems, and it was soon clear we had to provide a new estimate if we wanted to keep the project on track, as well as maintain the project and client relationship.
So we estimated again. This time, team members each estimated the previously-identified tasks in isolation, then summed their estimates to create individual, total estimates. All of these new estimates were much higher than the first, however, with significant variation across the team.
Without more to go on, we went with the sum of the highest estimates for each task, leading to a new total estimate more than 3x larger than the original. We then compared the first and second estimates with the actual effort applied to the proof-of-concept system. As it turned out, the proof-of-concept system had cost more to develop than the first estimate and less than the second.
Unsure of what all of this meant, we went with the second (highest) estimate because we considered that to be the most responsible choice. Responsible or not, the project was put on indefinite hold and we lost our client’s trust.
Experiences like this taught us how important estimation is to our work and relationships. What we learned from these experiences and how we’ve improved since (and how we know we’ve improved) is the subject of this series.
In subsequent posts we’ll walk through how we could have done a better job on this project, how we’ve changed our estimating process, how we integrate estimation with our other functions, and what we’re planning for the future.
But first, we’ll begin with what went wrong—and why—in the next post of this series.
(Please see the second post in this series here.)