Last updated on
Plutora Blog - Release Management

Your Software Release Schedule is an Important Part of the Release Process

Reading time 4 minutes

In most enterprises, the concept of having a reliable release schedule which represents what is going on in the development arm of your IT shop is quite foreign. The currency of the release schedule can’t be relied on or, in some cases, doesn’t even exist.

A classic case of bad practice is receiving weekly email updates or SharePoint alerts iterating that the release schedule is updated, something along the lines of “attached is Version 12”. Let’s face it — we all hate receiving updated documents, and release schedules are no exception.

What is a Release Schedule?

A release schedule is important and required for landscapes where you have multiple teams working on multiple systems delivering Projects or BAU changes. What this important artifact provides is an evident approach that planning for the delivery of releases and changes has occurred (to what extent comes down to the product or release manager and their experience). It graphically shows you immediately the contentions and dependencies around releases and gives you the mechanism to make decisions around release dates and test environment allocations.

I wanted to mention a few points around some of the key issues that owners of release schedules need to improve on:

The Stakeholders

software release schedule

Your release schedule should be shared with the following people:

  • CIO/CTOs (they’ll use it as a release roadmap)
  • All IT resources involved in IT Dev and IT Ops.
  • Business stakeholders will require it as well to gain insights into what changes are occurring to their systems.
  • Vendors, yes vendors. The amount of times we have seen vendors overlooked from accessing the release schedule is absurd. Your vendors need to know your release dates and major milestones. They need it for their planning to ensure they can deliver the items they are on the hook for.


There is no use having a release schedule if no one knows about it or can’t access it. Having lots of different schedule versions in a file share or SharePoint somewhere is no good either. You need to ensure that stakeholders know where it is and can easily access it, whether your release schedule is in Plutora or in some other location.

Using Plutora has many benefits. One advantage is that the release schedule is always the latest and greatest version of the real world. How, you ask? Because managers of Plutora are coordinating all their activities from Plutora in real time.

A viewer of a release schedule always needs to know what they are viewing is latest and greatest version. For some stakeholders, they might use it as a roadmap or IT pipeline reference point while others might use it for day to day delivery such as Product and Test managers.


Ok, so you have a great looking release schedule but how achievable is the delivery of each line item? Have you ensured that the dependencies and any potential risky release date are addressed? Do you have all the activities and milestones identified? Ensuring you have as much detail as possible in your release schedule is extremely important.

Plutora Release Management

Plutora’s Release Management tool was originally conceived due to the frustration experienced around visibility into the release pipeline. Regardless if you’re an enterprise release management team following the waterfall methodology or a single software line running a Scrum or Agile dev process, the need to see the release pipeline is the same. Basically, you need to know what is happening and when to make decisions about various factors. A solid, repeatable release plan reduces rework, lowers risk, and eliminates the need to piece together the definition of a release from myriad spreadsheets and documents. Establish a predictable delivery pipeline with Plutora.