This is Part 3 of our Release Planning blog posts series, click here to go to Part 1 and Click here to go to Part 2.
In Part 3 of Release Planning, we will go into the details for:
Coming up with a Plan for an Upcoming Release and more importantly its timing, is very similar to trying to accurately predict the Path of a Hurricane. It’s not easy and you will never be 100% accurate early on. Especially with a large project there are a lot of different variables, which will impact the actual timing of the Release. Some of these you can predict and control, while others are external variables that will affect the path of your Release.
Anyone who has watched the news of an approaching Hurricane has seen this type of diagram from NOAA.
This is known as the Cone of Uncertainty, as we know with 100% accuracy where the Hurricane is at this very moment. However, as we go further out into the future, we become less and less certain as to the exact path that the Hurricane may take. And because of this the “Cone” becomes larger and larger the further out in time we go. You can easily see this in the chart above.
The most important aspect of Predicting the path of a Hurricane is to constantly update this “Cone of Uncertainty” as new facts and information are reported. For an organization like NOAA they might do this every hour, moving their Predictive Model further out, as the Hurricane moves. This way as the Hurricane moves slightly to the right or left of its Predicted Path, they update the Predicted Path and the future “Cone”. This provides everyone with the latest information as to where and when the Hurricane may make landfall.
This same process occurs in Software Development. During the course of the Project we only really know where we are at right now. The rest is a Prediction, and the farther out we are trying to Predict the wider our “Cone of Uncertainty” will be. And likewise, the shorter the Timeframe that we are trying to Predict, the tighter our “Cone of Uncertainty” is.
Just like you break down the Scope of a Project into multiple Modules and Epic Stories, etc. You can break down your timeline into separate Phases or Milestones, each with separate Themes and Timeframes.
Example:
This way you can now start to line up the Timeframe, Resources and Scope for the first 2 Phases. What does each Phase include (Scope)? When does it need to be done? And what Resources are needed?
Given the “Cone of Uncertainty”, if we are trying to determine the exact Date for Phase VIII completion, we will never be accurate. Where possible try to focus your efforts on Predicting one or maybe two Phases in Advance, because those are going to be the most Accurate. Anything beyond that has a high risk of changing.
However, most Business Executives and Organizations will want some idea of when the Project might end. So, in these case do the following:
Using our Previous Example from Part 2 - Scope and Timeframe:
Note: this is an example only of how to do this, but is based on experience or similar projects.
Notice that your Cone of Uncertainty grows over time. So, at the beginning the gap is very small, and as you get to Phase IV - Production SaaS Deployment the Cone is nearly 2 Months Wide. This could even be wider, depending upon the Risk Factors involved with the Project and how many changes / unknowns you are expecting.
In a Traditional (Planned) Project Management Methodology the Project Manager(s) will spend a lot of time creating and updating a very detailed Task level Gantt Chart, which is constantly changing. However, due to the “Cone of Uncertainty” in Developing Software, we must ask the question, “Why are we doing this?” Especially for large projects that are going to take 6+ months or more.
We know that we are going to encounter Changes and Unexpected Impediments throughout the lifecycle of the Project. And if we know we can only Predict out 2 to maybe 3 months with any reasonable Accuracy, then why spend the time and effort on a Detailed Gantt Chart showing say 18 months worth of Tasks?
Every Technology Executive and Professional knows that if you’re trying to Predict that far out, it is going to be wrong. It is creating an illusion that we know when the Project will be completed. And worse we are setting ourselves up for failure. Because if we report to the Executive Management team that based on what we know this Project will be done by X Date Range, then that becomes the Timeframe, regardless of what happens. That is the date they will remember and hold us accountable to.
In 2016, I was the VP of Software Development for a small Software Company, although our actual Development organization actually consisted of two separate teams. Product Management oversaw one of the teams, and I oversaw our core team.
While our Core team was working on other Products, the Product Management team was asked to do a refactor of the User Interface of our main Product to replace Microsoft Silverlight, which was being deprecated. They didn’t like using an Agile framework and so created a very detailed Plan and Gantt Chart showing what they thought was every task that would need to be done. And they Predicted, based on their Plan, that they would be able to have a Production Release in six months.
They were wrong, it actually took closer to 18 months. Unfortunately, the Executive Management Team believed them, because of how detailed their Plan was. They assumed (incorrectly) that because the Plan was so detailed that everything was absolutely included in the Plan, and that we were, “Trying to Boil the Ocean” with our concerns.
And based on this, the Sales Team was given the “Green Light” to start Selling the new version of the Product after the first 3 months had passed. And like every other Software Company who has tried to sell “Futures” or “Vaporware”, it normally doesn’t end well. Because at some point the Client who bought the Vision of the Product, actually wants to use it. And that is when your Professional Services Team comes back and says, “It doesn’t work, we can’t implement this.”
My strong recommendation is if you are actually selling a Software Product, wait until it is in an External BETA Stage and you have at least some initial feedback that Customers actually like it.
Then you can go out and actually Sell the New Product. Otherwise, you will get too far out in front of your Skiis and quite probably crash and burn.
In Part 3 of Release Planning, we have discussed:
In Part 4 of Release Planning, we will go into the details for:
If you haven't, you can check Part 1 here, and part 2 here.
We hope that you have enjoyed this article and found it valuable.
Thank you, David Annis.
