Building the Release process in 3 steps

1. High Level

Aligned to your release model, details the major stages of a release: plan, build, accept and deploy and how the lower level activities fit within that: scope, requirements, build & test, acceptance, implementation, early life support and also show checkpoints (scope finalisation, build completion) and show gateways which align to your other processes such as governance, Change Advisory Boards etc). It’s also worth showing which environment various activities take place.

Build a timeline. Start from the ‘go live’ checkpoint at day 0, work backwards (T-) and plot in the major stages for an average release type (you may need one per model) and then plot other activity: environment management (data refreshes, interface switching etc), comms plan and enough lower level activity.

This high level lets you see the whole picture and start identifying areas of contention. If you have release cycles which last for several weeks and which are implemented monthly, you can expect some overlap. Examine these areas of overlap, it’s not uncommon to find the same teams doing different activities at the same time. Does this work for you?

2. Mid level

For each of the stages, briefly sketch out the following:

Trigger, Inputs, Outputs, Stakeholders & resource team owners, activities in a simple list format (which form the basis for your eventual low level processes). For your inputs and outputs, it’s useful to have your product definitions defined (even at draft level) – things such as the composition and format of release notes (at a low level code module level a release note could be a line in a spreadsheet or an entry in your version management tool) and define other products and artefacts key to the process such as a workbook of outstanding change requests (incident/problem fixes) and your business request / change proposal pipeline.

Once you’ve got these outlines, workshop them. Invite the stakeholders per stage. Review the inputs, outputs and activities. For each activity, fill out a RACI (Responsible, Accountable, Consulted, Informed) matrix. It’s also worth deciding at this point what low level processes you need. You may decide that just one processs for that stage is fine, but you may find that so much concurrent activity is going on, or you have activity which crosses stages, that more than one process is required. For example you may have one process each for scope, design, build and test, then another process which covers just the movement of code in and out of your code respository across all of those stages.

Incorporate all this feedback into the mid and high level process diagrams and timelines, and send out for formal review and acceptance among key stakeholders. Once accepted, these should go under change control.

It’s also worth plotting out a process map to help people understand what happens where, and if you find there’s value in having simple process flow diagrams at this stage then knock yourself out.

3. Low level

If you’ve done the mid level process descriptions with enough accuracy, then the low level processes should flow quite logically from the activity lists and the processes you’ve defined. Take into account multiple streams of work, but don’t be afraid to split out processes or subprocesses which might complicate an otherwise clear and easy to understand process, especially if that complex process  is focused on just one small team or activity.

You may need to iterate these a few times. I tend to use the swimlane (cross functional) process flow format in MS Visio but it’s up to you. Number each step, and then write out wordier descriptions in a document alongside the picture. the wordier descriptions can cross reference back to your release policy, or describe exceptions, constraints or other processes to refer to.

And that’s it. This progression has worked numerous times for me. It’s easy to dive straight into doing swimlane diagrams and the detailed descriptions, and also to miss out that intermediate step of defining the inputs and outputs etc. But the mid level is an important step, not just to quickly comply with ITIL requirements for what you need in a process (owner, trigger, inputs, outputs, steps) but to get your organisation up and running quickly with release management with enough detail to get the job done.