Why is Estimating Hard?
Estimating is difficult because predicting the future is inherently uncertain. Here are some strategies I’ve encountered or tried:
- Add 30% for Project Management:
I don’t understand this approach at all. Firstly, there’s no way I do that much project management, and secondly, it doesn’t address the root causes of inaccurate estimates. - Double or Triple Your Estimate:
This is one of my own strategies. Based on a few projects I’ve quoted, it seems to yield a more accurate estimate, but it still lacks insight into why the original estimate was inadequate. - Double It, Then Double It Again (4x it):
This might sound outrageous at first, but I’ve come to understand it. The initial estimate covers the work, the first doubling accounts for details and changes, and the second doubling addresses potential problems and bugs. This makes sense to me, assuming everything indeed takes twice as long. If not, do we then triple it, making it 9x? (Thanks to @panphora for this idea.)
It’s important to note that in the points above, I deliberately avoided using the term “overrun.” An overrun suggests that the estimate was accurate, and it was the execution that failed. However, we know this is often not the case. Work isn’t undertaken just to finish with more than anticipated. The real issue lies in our inability to predict what will be needed and how long it will take to accomplish.
Building it back up
It was clear that this “happy path” thinking was not only costly in financial terms, but probably explained the various issues I’ve had with over-running or over-working over the years – at either mine or sometimes my client’s expense.
And though the observations themselves felt extremely valuable, they needed fleshing out and pulling together.
Moving forward, I would like to:
- start thinking about some kind of “framework” to fit them in or around
- use them as building blocks to break down any future work, maybe even adding timings
- shine a light on the overall structure and nature of projects, and their estimation
I believe the distinction between the work done “before,” “during,” and “after” a project could serve as the foundation for this framework. Ultimately, I have settled on:timately, I have settled on:
Visualisation
During this investigation, I started to consider whether I could represent the findings visually. The graphic below is not an accurate depiction of the work, nor is it to scale in relation to the overall scope of the project lifecycle. However, it serves as an initial attempt to illustrate “the work” in comparison to the entire project scope.
The following graphic is not an accurate representation of the work, or to scale regarding the work there was to do, but is an initial attempt to view “the work” compared to the overall scope of an entire project lifecycle:
Analysis
Breaking this (again, inaccurate) diagram down by area (again, units do not represent effort 1:1) provides a little numerical perspective:
