The Purpose of Planning
Before talking about the Cone of Uncertainty and estimation lets clarify some things about planning. I constantly tell my friends and co-workers that ideas are not the same as planning. Remember the last time you started something that, for several reasons, you never ended, or that time you said my “plans” are …, but in reality, you never took real actions to execute those “plans” or you just keep putting them off. The main difference between ideas and plans is basically that ideas are vague, aspirational, and desirable; while true planning takes ideas further and establishes goals along with preconceived steps to take that eventually help to estimate, make decisions, and even refine or change the plan.
In the same way that it happens in life, in the software and IT industry in general, estimations and planning are of the utmost importance for the success of any project. The plans are a guide that tells us where to invest our time, money, and effort. If we estimate that project will take us a month to complete and in return, it will generate a million dollars, then we may decide to carry out that project. However, if the same project generates that million dollars in 15 years, then perhaps it is better to reject it. Plans help us to think ahead and know if we are progressing as expected among other things. Without plans, we are exposed to any number of problems.
In my experience as a developer, scrum master, project manager, etc., teams tend to two extremes: They don’t make any plans at all or they try so hard on a plan that they convince themselves that the plan is actually correct. Those who do not plan simply cannot answer the most basic questions, like, when do they finish? or, will it be ready before the end of the year? Those who plan too much, invest so much time in their plan that they fall into assumptions that they cannot confirm, their insecurity grows more and they begin to believe that even by planning more they will achieve more accurate estimations although this does not actually happen. If you feel identified with any of the previous scenarios, in your favor I can say that planning is not easy.
But that plans fail and planning is complicated is not news. At the beginning of a project, many things can be unknown, such as the specific details of the requirements, the nature of the technology, details of the solution, the project plan itself, team members, business context among many other things. But then, how do we deal with these riddles? How do we deal with uncertainty?
The Cone
These questions represent a problem that is already quite old. In 1981, Barry Boehm drew what Steve McConnell later called the Cone of Uncertainty in 1998. The cone shows that in a sequential or “cascade” project that is in the feasibility stage, we will normally give an estimate that is far from reality, in a range of between 25% and 400%. This is for example, that a 40-week project will take between 10 and 160 weeks. By the time we finish obtaining requirements, our estimate will still be between 33% and 50% out of date. At this point, our 40-week project will take between 27 and 60 weeks. Imagine what happens with those projects that are never clear about their requirements.
How to deal with the Cone of Uncertainty?
Buffering (margin of error)
This is to use a percentage of time and/or resources to cushion the effect of materializing risks. You have to be careful, a common reaction is to put double or triple the time to estimate a project, this is NOT buffering, this is “padding” which IS NOT a good practice. Giving a too large number will cause sponsors or clients to resist and not approve your project. Give them a too low number and you will take the risk of running out of time and money. This becomes doubly risky when you are using fixed contracts for your proposal, where there is even more pressure to keep costs down.
It is important that you make use of historical data to compare your current project with other completed projects and obtain reasonable and justifiable numbers in order to get a margin of error or buffering. Include postmortem processes or lessons learned at the end of each project to support your buffering figures in the future.
Estimate in ranges
Something I like about agile approaches for project management is being honest from the beginning and never use closed figures, but be transparent and always use ranges, especially in projects that seek to innovate and try new things where there is a lot of uncertainty. This is for example:
Look. We don’t know how long this is going to take, however, the following is our best bet based on the information we have so far. But if we can do a couple of iterations, we can develop something, evaluate how long it takes, and then have a much better idea of how big this is.
Also, present the best estimate at the moment as a range. This can help project sponsors to decide how much risk they are willing to accept.
Relative estimation
There have been various investigations on how to make estimates of effort and it has been discovered that people are good at estimating the size of something comparing it with a reference (Software Development_Effort Estimation). For example, someone cannot tell you how high the building you live in is, but they can tell you that it is approximately twice the height of the other. You can apply this principle to projects too.
Note. Agile approaches use interesting concepts like Story Points and Ideal Days to make relative estimates.
This is not a foolproof measure, you can still misjudge. But it is certainly good to get initial funding that allows the team to build something and see how long it takes to complete this progress, while simultaneously they learn more about what needs to be achieved, in such a way that this experience is used to reduce the variance of that estimated starting number.
Why is all this happening?
There is no doubt that there is always pressure from the financial sector of organizations to make estimates for an entire project or for a whole year, although these practices ultimately backfire 😀
The best thing to do is to permeate this knowledge in your organization, and constantly remind and communicate that the goal of estimating is not to guess the future, but to determine whether the project goals are realistic or even possible.
Some interesting links:
Part of the list of topics for this post and the idea of the graphic with the little sun 🙂 were partially based on articles from agilenutshell.com
These are some recommended books to know more:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
