Let’s take a look at the Forecasting phase of the Product Release life-cycle. This phase is not usually mentioned in ITIL processes as a separate process or phases for release management, and it’s a significant difference between Product Release Management (PRC) and IT Release Management. In PRC, we own and develop the product itself, so Release Management dictates the Go-Live date or launch date of new releases of the product. In contrast, IT releases often manage deployments of 3rd party IT applications or customizations to them.
A good Product Release Calendar can be one of the most useful tools for customers and the business itself that is published by Product Release Management. It is a high level schedule of upcoming releases for a particular product your business is developing, usually a few quarters or even years in the future. Customers can leverage it for their own IT planning around your product.
We can see the difficulty we will have in forecasting releases in the diagram below. The fog of war, as I like to call it, are all the unknowns we face with the product that makes it difficult to plot out a solid product release schedule – from market forces to customer requirements to technical team capacities. As important as it is, this is why the product release calendar can also be one of the most difficult artifacts to get right.
There are some steps we can take to building out a release calendar as part of the Forecasting process. Remember, that with all the unknowns the Product Release Management is trying to bring structure to the process.
The Release Calendar usually indicates at least the Go-Live or Launch dates of the next release. If it’s possible, the release phases may also be shown with some sort of durations. For customers and external stakeholders, it’s usually a good idea to only publish go-live dates that you are fairly confident in hitting, otherwise your calendar may face a credibility issue.
Consider the following factors when building a Product Release Calendar:
- Development and Build capacity
This will dictate how fast Releases can be developed. Work with the Development teams to understand how much capacity they have, and ensure this is taken into account when giving releases enough time to be built.
- Testing team Capacity
Another element that dictact release throughput. Consider how much capacity is available for each testing type such as functional, integration, User Acceptance and Business Acceptance testing. This will of course depend on your firm’s testing processes.
- Technical dependencies
Understanding the changes being implemented in a release, and their technical dependencies to other system components will enable you to decide how best to bundle common components together for more efficient development and testing. It also allows you to schedule deployments and testing within the same environment. Two independent changes, might be able to be tested in different releases executing in parallel, while two related changes may need to included in the same release.
- Testing Environment capacity
Most companies can handle more than one release being tested at the same time, or at least overlapping. Having an understanding of the testing and staging environment usage will enable the scheduling of testing through the environments.
- Deployment and operational capacities
Consider constraints on deploying into production.
- Market Demand and other external forces
Depending on your organization, the Product Management or marketing teams, or the Product owner in an Agile environment, should be able to give you direction on what the market is looking for and when. Consider this when deciding upon go-live and launch target dates.
- Customer Requests
Customers will have requests and requirements for when they expect a release. These requests should be vetted by a proper prioritization process – whether by product management or another function, otherwise there may be competing interests from multiple clients.
- Internal vs External Release Calendar
Consider publishing an external and an internal Product Release Calendar. Internal teams will want to know the durations of the release phases and any milestones they need to meet. Dates that need not be shared externally. For example, if a release is scheduled to go live in winter, a project manager will need to know what dates they need to meet to include their project changes in that release.
Customers do not need to know all those details, and so a more simplistic calendar can be published to external stakeholders.
Progressive elaboration is the name of the game in this phase. At first, with so many unknowns, the Release Calendar will not be as accurate, but as time moves forward you should be able to firm up milestones and dates and ensure your forecast is up to date.