In software development the purpose of estimates is to reach an agreement with the involved parties. Estimates are tools of communication. They are warrants for the expected budget, duration or scope of a given project or product. The project’s business case will be evaluated on the basis of these warrants.
But be careful. Estimates are not hard facts, they are but guesses. And how dare we professionals to base huge budgets and business critical products on warrants that are guesses knowing that they by nature are uncertain?
Making the uncertain as certain as possible
“Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable”
Guessing on any future event holds no guarantees. One could even go so far as to say “do we really know anything for certain?” I won’t dive into that question!
But what we can do is to make those guesses as likely as possible. Our guesses should be so good that an agreement can be made based upon them meeting the expectations of the parties involved. However, what is a good guess that will be a solid warrant? It’s not the cheapest or most expensive guess or even the average. In fact it’s not even about numbers.
The best estimate you can make is, given a set of conditions is the most probable one, with risks explicitly stated.
Dealing with the risks
If you want, you can even make contingency plans for the risks, and estimate those as well. But remember, even then, it’s still a guess and you should make sure that everyone knows what the estimation process is focusing on: increasing probability. Then, you have used the estimate as a tool to shed as much light as possible on the issue for all parties to see and reach a consensus that is agreeable to reason.
And by the way, talking about risks and the natural fact that humans make mistakes, early on in a project, is critical. Once the task or project is underway, mistakes will be made and you should learn from them.[http://pentia360.dk/project-planning/] Or opportunities will arise, that you should seize. If the initial business case includes these eventualities, no one has to spend their time arguing about why the estimates are not being precisely met
There are many named methods you can use, to find the numbers – But I won’t cover them here. Instead, I’ll describe what factors we can try to control, to increase the probability of our guesses.
If we want to make highly probable guesses that agrees to reason, we need to be aware of, and maximize these factors to the best of our ability. We need to understand the business case and the conditions surrounding the project, when doing the estimates.
How much time is available to do the estimates, before the opportunity is missed?
How easy is it to draw on past experience? How do you put the team of estimation together?
What do we know about the task?
The optimal conditions are: Having personal experience with the task, all information available, and all the time in the world. However, that is rarely the case. So start by assessing how many of these three factors are available, and improve them as much as possible.
Not unlike the project management triangle, these factors can be used for identifying what we should focus on. We should build a foundation for estimation:
- If you can’t get time – get information and experience
- if you can’t get information – get experience and time
- if you can’t get experience – get time and information
I’m fairly sure that, whatever estimation method you use, your estimates will be highly probable by using this foundation up front.
My colleague Thomas Eldblom wrote a great blogpost about the developer view on the estimation process . http://pentialized.dk/2013/10/16/estimation-redefine-or-new-term/
When your best guesses are wrong
Nobody likes being wrong. But at least you (and hopefully the project organization) are proven right in the fact that “estimates are not facts”. People can hold very different definitions of the term “estimate”, and therefore expect something very different from the project result, -process, -communication and -priorities. Either you have planned with contingency based on risks, or if not: You need to start scoping out.
Scoping out is a way of hitting the estimates more accurately based on information you have gained during the project and the current use of resources. In that case, the current remaining time/budget becomes a constraint, a timebox, in which the team must complete the work.That means, you prioritize the remaining tasks and whatever tasks do not fit into the timebox are scoped out of the project.
This method of scoping out can be a very counter-intuitive surprise for a project owner, and in worst case have negative contractual implications. Or, it can be a previously agreed upon action that follows naturally, and the project finishes – fulfilling the business case. It all depends on how the estimates are defined and used to align the project to reason.
Follow us for similar blogposts:
Share the blogpost with your network: