Let me paint a picture for you, you’re in a dark room and all you can hear is the simple tick tock of a clock… no it’s not the crocodile from Peter Pan. It’s a bomb, you’ve been trained and you have years of experience defusing bombs, but it’s still nerve racking. I then take my VR headset off and take a breath, that game is a bit intense!!!
But something I’ve noticed through my experience as a PM that as we work through a project, we are following the same set of principles and trying to “defuse” issues before they blow up in our faces. Smarter people than me have managed to turn this into a concept which has been discussed and expanded upon – “The Cone of Uncertainty” which is captured below.
So what does this all actually mean in practice? To cut a long story short, it is the principle that as we move through a project the worse time to make promises, firm decisions and estimates is at the outset. The reason behind this is quite straightforward – at the beginning of the project there are a lot of unknowns, both known unknowns (things we are aware of but can’t decide) and unknown unknowns (things which we don’t even know are going to happen).
The graph above shows this in an easy to understand way: with the passage of time, unknowns are reduced and estimates become more accurate as we gain domain knowledge. However, this leaves an obvious question – how do we influence the cone? This brings me onto something a scrum coach described as “The Bombshell of Uncertainty” (ties in nicely to the title right!!) and the “Trumpet of Uncertainty”.
As you maybe able to guess, this is one that may blow up in your face. As my scrum trainer described it, this is the main issue with any waterfall project which has a great amount of upfront documentation. As much as upfront documentation and decisions may seem to be helpful, as Robert Burns put it in his poem “To A Mouse” (1786):
“The best laid schemes o’ mice an’ men
Gang aft a-gley, [often go awry]
An’ lea’e us nought but grief an’ pain,
For promised joy.”
For all the time and effort put into documentation, life gets in the way which can often invalidate the rest of the documentation, which was based on that decision. Another issue can be that the world changes. Having set documentation and set deliverables does not allow for flexibility, and so any changes to the product must be done after it is finished… by which point it may well be too late.
Often in both of these cases the project is then regarded a failure, as it cannot be achieved and the plan has become invalid in one way or another. This issue leads to one of the key pillars of the Agile Manifesto: “Responding to change over following a plan”.
In terms of looking at this in terms of the graph above, the lines continue horizontally before eventually dropping steeply at the end of the project, forming a shape very similar to a bombshell synonymous with World War 2.
So if the “bombshell” is the Waterfall version we are seeking to avoid, what would an Agile enthusiast say would happen to the cone of uncertainty if a project was to embrace Agile principles? Digging out my Agile hat, and following a textbook definition of Agile, the cone of uncertainty would be pushed further to the left of the graph, forming less of a cone and a shape more akin to the mouth of a trumpet (or any brass instrument really).
The reason behind this is the focus on iterative and incremental improvements to products with frequent demonstrations to clients, to ensure functionality is both correct and still relevant. This ensures that while the world changes around the project, the project can adjust and adapt with it in order to provide the most value at completion.
This focus on tight feedback loops, whether through the scrum or kanban ceremonies, is where offers Agile an advantage over traditional Waterfall methodologies. The honest recognition of knowing that plans will change, and being able to respond effectively to that change and a focus on removing blockers ahead of time, means that Agile offers a increased chance of success – or if a project cannot be achieved, failing fast and saving clients both money and time.
So what at the main lessons to learn from this rambling on unknowns and cones and trumpets?
- The cone of uncertainty is a straightforward way to display the concept of unknowns and estimates, and how these can be reduced and become more accurate over time.
- A Waterfall model drags out this cone due to it’s reliance on up front documentation, and inflexibility should the documentation be based on incorrect assumptions or that the world changes.
- Agile can push the cone to the axis of the graph with it’s focus on flexibility and being able to adjust as the needs of the project change.