Forecasting: Building An Accurate Product Release Calendar

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.

release_phases

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.

Forecasting and the Fog of War

Forecasting and the Fog of War

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.

Advertisements

3 Easy Ways to Improve Your Product Release Management

Product Release Management is the function responsible for the end to end management of designing, developing, testing and delivering new software, or updates to an existing software, which is considered part of a business’s core services or products.

Since we are talking about a business’s core offering being the software here, it’s vitally important the release process is efficient and effective as it has a direct impact on the bottom line.

Here are 3 ways to make sure your Product Release Management function is well positioned for success:

1. Maintain a Product Release Calendar

calendarA Product Release Calendar is the schedule of potential releases for your produ
ct in the upcoming time period. This is essential to help not only your
own firm plan out the future of product, but also for your customers to plan their own IT changes to implement the new release into their current operations.

Product Release Calendars are most useful when they can indicate release dates at least
a few quarters, sometimes years, down the road.  Usually a target Go-Live or Launch date is indicated in the calendar, with potential milestones for each release.  We will discuss how to forecast and build out a Product Release Calendar in another post.

The PRC should never be built in isolation – it impacts many stakeholders who have to create, test and maintain the product, and so feedback needs to be collected on a regular basis. Depending on the structure of the company, some of the stakeholders that PRM should collaborate with for input and buy–in might be:

working– Product Management or Marketing teams – to understand when the market or customers are looking to see certain big-ticket features for the product,

  • – Project Management – to understand when projects are coming down the pipeline, and their target implementation dates,

– Development, Testing, Environment and Operations teams – to understand their capacities, schedules, usage and other constraints.

Once a usable Product Release Calendar is ready, publish it and maintain it on a regular basis. Make sure to note that it can change so that expectations are set with your stakeholders. Whether it’s sent out via email to stakeholders or placed on the company intranet site somewhere, this will help make it official and help stakeholders understand what’s in the pipeline.

2. Leverage Project Management methodologies to run the Release

A Product Release is very similar to a Project and thus leveraging project management methodologies will help bring structure and consistency to the release end to end processes.

Implementing Project Management processes will go a long way in providing a solid Task-Boardframework to work under for a release. A simple initiative that can be implemented might be to hold a regular release meeting, say once a week, for your stakeholders to come together and discuss their risks, issues and updates during the execution phases. Regular communication is essential for the success of a Product release due to the sheer number of people usually involved.

Scope and Schedule management – base-lining the features and defects being fixed, and the target go-live of the release at the very beginning will greatly improve planning and delivery.  Scope and schedule may change, but its more manageable with a strong Change Management process in place for the release.

Risks and issues can also be tracked and plans put in place to mitigate the situation. As with any best practice, you should customize it to your firm’s maturity and culture. Some mature companies use a software tool to track risks, when smaller firms might just log it in a local spreadsheet. Whatever the method, being able to track all your risks will help greatly when planning and mitigating any potential issues.

The PMP certification is one of the industry leading project management certifications and is an item I highly recommend to any Product Release Manager to read up on if they are looking to improve their releases.

3. Communicate, Communicate, Communicate

announceIf you’re responsible for Product Release Management, then the product you work on is revenue generating or at least an important and strategic business product for the company. This means everyone from the most junior developers to the most senior executives will care about the release. They may be aligning their work activities around a release – for example, a salesperson may be selling the latest features of the upcoming release to a customer, or a developer might be trying to prioritize her tasks around their work for the release. As techies, we might often forget this, but communication around a product release is essential and of great value to its stakeholders.

Leverage technology to publish regular updates on the release so that stakeholders know what is in scope, the schedule, upcoming milestones, and anything else that may be relevant to them. Some ideas to improve communication might be to email out a Release Scorecard each week to the department, maintain a Release dashboard webpage or publish a webpage on the intranet for all employees to access Release information.

Whichever path you choose, communicating to your stakeholders about the Product Release will drive alignment with the release goals across teams.


These 3 steps will help you in implementing an effective and strong Product Release Management function.

Depending on the organizational culture and process maturity, each of the steps can be executed a little bit differently in each company. So always look to customize these steps to what works best in your own organization.

Together though, these 3 approaches can be a powerful driver to more efficient and higher quality Product Releases that all stakeholders support.

The 6 Product Release Phases

As mentioned before, Product Release Management is closely aligned with Project Management. Thus it should come as no surprise that we align the Product Release phases with the standard Project phases – initiation, planning, execution and closing. A Product Release is in many ways a project, and each release can be managed as one.

We will go into the details of how each of the phases can be carried out in future posts, but for now we will summarize the key points of each phase one by one. The 6 phases of Product Releases are:

  1. Forecasting
  2. Planning and Scoping
  3. Build
  4. Testing and Validation
  5. Preparation and Deployment
  6. Close

As we walk-through the release phases we will also indicate how each step align with the typical Project phases (Initiation, Planning, Executing and Closing) to help clarify how it fits in with Project methodologies. We can leverage Project methodologies to help manage the scope, schedule and risks of the Release just like any other project would.

prm_projects

Initiating

1. Release Forecasting

Forecasting is an ongoing release process that is used to build out the high-level schedules of future releases. We have included it here as it is an important phase that sets the release targets for the upcoming periods. It is also one of the most difficult processes to do well due to the number of unknowns in predicting the future and the number of stakeholders involved.

calendarDuring this phase, Release Management works closely with Product Management to determine a future
schedule of releases (aka the Product Release Calendar) that will meet the Product roadmap needs, while also taking into account the resourcing and environment capacities of the development, technical and operations teams.

This can be a complex undertaking, especially in bigger organizations, that requires collaboration with all the different stakeholder groups involved in the release life-cycle.  Each stakeholder has different needs and constraints that the Release Manager needs to be aware and mitigate when developing the calendar. For example, a product manager or project manager might be able to tell Release when they want a feature to go to market, but the Release Manager will have the holistic picture that takes into account other releases, resources and environment usage to determine whether it’s feasible.

The main output from the Forecasting phase is a Product Release Calendar (or updates to the existing Product Release Calendar) which documents the high-level schedule of future potential releases of the product. Even at a quarterly level, a Product Release Calendar will give customers an idea of when to expect updates to the software. For enterprise customers, this enables them to plan and budget for any changes they need to handle in their IT environments.

Planning

2. Release Planning and Scoping

planningWhile the forecasting phase is a continuous one that occurs through all the other phases, the Planning and Scoping phase is in many ways the first step in building out a particular Product Release. In this phase, we determine the scope of the release, put together a detailed schedule and approach to delivering the release, assemble an Integrated Release Team and finally produce the release plan. As mentioned before, this is very similar to the Planning phase of a project as described in the PMBOK.

Note, the scope of the release is simply put, the software features and defect/problem fixes that will be delivered by the release.

This phase can vary in duration, depending on how mature the Product Management function is and how the business operates.  A strong product management function will be able to more readily define what product features are required, while a weaker one may mean that there needs to be some prioritization of features to define the scope. If the firm is using an Agile methodology, this phase may be much shorter as well if the sprints and backlogs are run efficiently. Different organizations have different approaches to defining scope of release, for now we will accept that the scope of the next release can be determined and baselined.

A release plan should be defined at this point which describes at least two items of importance:

  1. Scope: namely the software changes on the release, and the
  2. Schedule or milestones the release will be meeting.

Other items the plan can describe include the release version, key stakeholders, promotion path through the testing and staging environments, and success criteria that need to be met at different milestones. The plan may be simple at first, but can be progressively elaborated as the release progresses. The release plan is important in helping to align the Integrated Release Team to what the release will be delivering and the schedule it is targeting.

Once the plan is defined, Change Management will need to be respected to ensure any changes to the plan are approved and agreed upon. We will describe Change Management in more detail in a future post.

Executing

workingIn this phase of the release, we kick off the regular release meetings with an Integrated Release Team (to
be discussed in a later post) to manage and monitor the following significant areas:

  • Risks
  • Schedule
  • Change Management
  • Code promotion
  • Other release activities

The Release phases within the Project Execution phase are Build, Testing and Preparation and Deployment.

3. Release Build

The first step of the Execution phase is the Build which involves a number of technical activities. This is where the code or scope of the release is developed and built and any preparation activities are conducted in anticipation of testing. In the Agile world, the code and testing may often be done together in this phase and with the next phase (Testing and Validation), while in the Waterfall world, testing is done separately.

Keep in mind, the actual coding and development is usually done by a different team from the Product Release team. As such, Release’s main concern in this phase is to track the development milestones and ensure progress is on time – usually collaborating with the Development Manager or Lead. Any issues or risks need to be mitigated or the schedule updated to reflect any changes. Release should also be coordinating preparation activities for the next phase such as the development of test plans, scripts, environment readiness and so forth.

4. Release Testing and Validation

This is a key phase of any product release as it is here that the code is put through its trial by fire and quality is measured. In Agile environments, this phase may blend into the Release Build phase, but for clarity we separate it out here.

The testing phase may involve running functional, system, integration tests as well as User Acceptance and Business Acceptance testing.  The sequence and types of testing depends on the organizational processes and requirements. It is imperative that Product Release Management tracks testing and ensures that the entry and exit criteria are met, and any exceptions are clearly understood and managed.

5. Release Preparation and Deployment

The preparation and deployment phase of the release is the last step before a product, or product update, is launched into the market or deployed into a production environment.  At this step, the stakeholders come together and agree or disagree that the release has met its requirements and objectives.  Usually a readiness checklist of some sort can be used to track that the various requirements have been met – we will go into some types of checklists that can be used in a later post. The Readiness Checklist will cover everything from scope confirmation to testing exit criteria to marketing communications to release notes. This feeds into a final Go/No-Go checkpoint or potentially a (Change Assessment Board) CAB approval that determines whether the release can be launched or deployed.

Closing

6. Release Close

After the release has been deployed, a review session is recommended to feed into the continuous improvement cycle. It is here that the Release team collect objective feedback, both positive and negative, from the teams involved in the release on potential improvements and lessons learned that can be implemented in future releases.

Release Phases and the SDLC

The 6 release phases also align with the Software Development Lifecycle. Product Release Management is usually engaged in the SDLC at the design phase, helping to coordinate and manage the development, testing and delivery of the product. Depending on the organization, they may be involved earlier or later in the SDLC as well.

prm_sdlc

The Release Forecasting phase is considered a continuous process that engages across multiple SDLC cycles and is not shown in the diagram.

An Introduction to Product Release Management

If you’ve come to this site, then you’re most likely involved in the Software Development Life-Cyle at a software or technology company, and you’re trying to understand what Release Management is and how to do it.  You’ve come to the right place.

Product Release Management

This blog attempts to define Product Release Management (PRM) – a little understood aspect of developing software, but an activity that is increasingly needed in today’s world where software is pervasive in everything we do. As more and more software is developed and released, solid Product Release Management is an absolute necessity to deliver high quality technology in a fast and efficient manner, using methodologies that can scale with the needs of the business.  PRM enables improved development and launch of innovative and original software products while reducing costs to go to market.

What is Product Release Management?

PRM is the function responsible for the end to end management of designing, developing, testing and delivering new software, or updates to an existing software, which is considered part of a business’s core services or products. This means that the business will be building requirements, designing, and delivering their own software products which means there are many unknowns in the process. There is a ‘fog of war’, which we will go through in more detail later, in every step from understanding requirements from customers, designing features,to launching in a competitive marketplace.  A strong Product Release Management function can help mitigate many of these risks in building a delivering high quality software.

Product Release Managers leverage Project Management methodologies and run their releases as mini-projects – managing and coordinating all the intricacies of building software.

prm

Before we dig deeper into Product Release Management, let’s first set some context of how it relates to IT Release Management and Project Management.


 Product Release Management vs IT Release Management

The first step in clarifying Product Release Management, is to separate it from the very different, but still similar in many ways, beast called IT Release Management. IT Release Management often leverages the IT Infrastructure Library (ITIL) best practices and is grouped under the function Change and Release Management.

While PRM is the end to end management of releases for core business and revenue generating products, IT Release Management is focused on applications and software that support the business functions. The PRM is focused on managing releases for a certain product that is usually developed by the business itself, while IT Release Management is often (but not always) focused on third party applications. Some of the main difference between PRM and IT Release Management are identified below:

PRM vs IT RM

PRM vs IT RM

An example of where Product Release Management would be used might be at Microsoft during the development of their latest Windows application. As you can imagine, there are many unknowns and risks that Microsoft faces as it builds out the new Operating System that they hope will meet customer needs and be a success. In contrast, IT Release Management might be utilized in an accounting firm’s IT department when the team manages updates to a third party accounting software used by all their accountants for day to day transactions.  Though there will be risks in implementing and deploying the solution, the software itself has been built by another 3rd party and so the challenges are different. Very different skills and processes are needed by Product Release Management which we will explain in a later blog post..

PRM leverages project management methodologies to coordinate the various functions involved in a release for the product and fits best within the Product Management department of a software company. This is because there are synergies between the Product Management team which is in charge of the vision and direction of the product, the Product Release Management team which is in charge of delivering that vision to the market.

IT Release Management is focused on IT services and products that support a business’s core activities. IT RM is also usually more technical in nature, and the RM function may be involved in managing builds, configuration and deployments.  The scope of the IT RM releases also may cover a range of changes including 3rd party application updates, operating system patches, security improvements, hardware upgrades, Projects and Programs. IT RM fits best in an IT department.

PRM is the end to end management of releases for core business and revenue generating products.

Product Release Management and Software Project Management

Product Release Management is just another sub-activity in the typical software project life-cycle. One release may have multiple projects delivering changes for the product on it, and so the PRM collaborates closely with the Project Management teams to support their work.

PRM_and_PM

While the Project Manager focuses on the end to end project which includes project initiation and other project phases, as well as all the end to end project activities such as doing business analysis, gathering requirements and managing customers, the Product Release Manager is focused only on the product. If it is a brand new product, the PRM will be coordinating the design, development and validation of the software, while for an existing product, the PRM will also be managing the release forecast and schedule for the software.

PRM_projectsAs we will look at later, multiple projects can be grouped or bundled together on one release. This means Product Release Managers may work with multiple project managers to help deliver their product changes.

PRM and SPM can overlap if the business is a software company where the project is delivering changes to core product. In this case, there can be overlap in the two areas, but the PM is still focused only on delivering their project, while PRM is focused on product releases.