There are many reasons why releases fail. Maybe your test pack wasn’t scoped properly or that harmless application patch from the vendor removed a key piece of functionality. All of these pale in terms of avoidability and regularity in comparison to the following conversation:
Requestor: “I want this change to go into the release.”
Release Manager: “Sorry, the scope has closed, we’re scoping the next one though.”
Requestor: “But that’s too long to wait, it has to go in NOW.”
Sound familiar?
Something I’ve run up against several times at several different organisations is making sure that the release process, policy and schedule is fit for purpose not only in terms of being compliant with best practice (such as ITIL) and controls (such as COBIT) and any other requirements within the business, but also to ensure that your change and release structure can cope with the volume of change.
Let’s assume your organisation has two broad categories of changes which are bundled into releases – new business functionality in the form of BCRs (Business Change Requests) and problem fixes.
We’ll also assume that you have a monthly release model which includes:
1. Scope and Design finalisation (1 week)
2. Build & Test finalisation (2 weeks)
3. Running an automated regression pack (1 week plus 2 days for final fixes to go as deltas on top of the main release)
4. Cutover and implementation activity (3 days)
5. Early Life Support (2 weeks) (ELS is an ITIL term which used to be called release warranty – in essence, a period of enhanced support following a release or where incidents/problems follow an accelerated support model compared with normal Business As Usual support).
I’m currently doing some work planning releases for the next 30 months or so based on some standardised models etc (more on this in another post).
I’m scheduling 2 main types of release: functional releases in the main business systems (running SAP as it happens) and maintenance / patching windows.
The organisation has a real appetite for business functional change, and is less keen on regular maintenance. However we have to comply with corporate global policy on WINTEL and linux patching as well as app patching so we have some political support for this vital work.
Building this into the schedule therefore leads to a curious question – when we plan releases far into the future, do we do it to constrain their activity and impact on other releases, or entitle them to have that reserved slot…or both? What do you think – for your varying release streams, do you schedule activity more to constrain or to entitle?
