BLOG! Goitil.co.uk Providing Affordable IT Management to SME's

Blog Navigation:
Access Management (SO)
Applications Management (SO)
Availability Management (SD)
Capacity Management (SD)
Change Management (ST)
Continual Service Improvement (CSI)
Demand Management (SS)
Evaluation Management (ST)
Event Managment (SO)
Financial Management (SS)
Incident Management (SO)
Information Security Management (SD)
IT Service Continuity Management (SD)
IT Operations Management(SO)
Problem Management (SO)
Release and Deployment Management (ST)
Request Fulfilment (SO)
Risk Management (SS)
Service Asset and Configuration Management (ST)
Service Catalogue Management (SD)
Service Desk (SO)
Service Knowledge Management (ST)
Service Level Management (SD)
Service Portfolio Management (SS)
Service Validation and Testing Management (ST)
Strategy Generation (SS)
Supplier Management (SD)
Technical Management (SO)
Transition Planning and Support (ST)
Return to blog homepage

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.

Co Reg no 5808734 | ©2006 Nuts and May Ltd