Release policy
The first chapter of this topic introduced the basic concept of releases and how ITIL defines 3 different approaches. So what we now have is the method, but to make Release Management a useable process we need something that binds it all together.
Now I run the risk of switching some readers off, as I am going to talk about something called a “Release Policy” and anything with the word policy in it can cause a feeling of “loosing control” or “limiting our flexibility”. This can be especially so around SME’s who need to be able to react to market forces and direct competition.
So what is a Release Policy? Well the best way to think of it is as a document that outlines your roadmap to ongoing upgrades and allows you to manage the future of your IT services by having a point of reference of your ideal approach. Now it can be viewed two ways; firstly as a binding agreement that dictates your upgrade path and allows you to consider the wider picture such as budget and hardware requirements in plenty of time. Alternatively it can be viewed as a strategy document that is reviewed on a regular basis and is used as a “hand on the tiller” but not always implemented exactly as the timelines dictate. Only you, based upon your company culture can deceide which one is most appropriate.
So what could be in a Release Policy for a SME ? Headings could include:
• The name of the system / application
• How your are going to refer to it (eg internal naming convention or vendors given name)
• A statement that define when the release will be implemented (eg first quarter of year, 6 months after vendor public release etc)
• Times to avoid (may be different for each application)
• Approach towards testing and backout
• Number of back releases that will be held and for how long
A short example for your main desktop operating system could be as follows:
Release Policy: John Peters Trailers
Application: Desktop estate operating System (Windows)
Release Name: Vendors designation including Service Pack notation
Release Window: Release will be a minimum of 9 months after general release and only after the first service pack has been released
Release Exemptions: Peak trading period (April – July) to be avoided
Testing statement: Hardware to be refreshed in line with operating system upgrade. All other applications to be loaded at current software level and tested for compatibility
Release Approach: Machines to be upgrade spread over 2 weeks
Backout statement: Following successful compatibility testing, all issues to be resolved without backout. This may result in secondary applications being upgraded. If the problem can not be resolved within 2 working weeks, then regression to the previous desktop machines will be allowed
If you would like to see a full example of a release plan, please contact us Quoting “Release Plan example” in the subject heading
2nd Feb 2009
Click here for details of our FREE business healthcheck and join the rest of the companies using IT Service Management.
Providing Affordable IT Management to SME's