Want to make an IT service change? Here’s how to do it
7 Aug 2019 12:14 PM
Blog posted by: David Billouz – consultant and trainer, Ociris Global, 07 August 2019.
Change, release and deployment in ITIL® help to ensure that what a requester – such as a service owner – wants can be delivered from a technical and feasibility perspective.
I’ve seen this work effectively in the French national railway company, SNCF; but before we get to that, there is a useful mnemonic to help organizations understand the change lifecycle: “I Always Ask Someone Better Than I When Making A Change”, which means –
- Identify the request for change
- Assess the request (risk assessment, roll-back plan, etc)
- Ask someone to approve the change (change manager, CIO, etc)
- Schedule the change
- Test – deploy in a testing environment and create the first full release available for other tests in a pre-production environment, for example
- “I when” = “it works”, both in technical terms and acceptance criteria.
- Accept the change
- Close the request
And what happens if you don’t follow this?
For example, if a project manager requests a change by “date XX”, you might approve the change based on what you know. However, after testing, you might be forced to change the realistic delivery date!
Understanding change, release and deployment
For ITIL practitioners, understanding the separation between change, release and deployment changes slightly with the move to ITIL 4 and is based on the environment: deployment management ends with the live environment while release management allows users to use the release.
In development, and particularly in the case of digital transformation, the Scrum method has a release plan which is like a “train” you can’t afford to “miss”! For developers, release is the time when you have a complete piece of work ready and the approaches outlined in ITIL 4 complement this.
Substituting a new tool for old at SNCF
How did the ITIL principles already outlined apply in the example of SNCF?
It began with an existing service management tool customized for change control, but which didn’t facilitate the link between change control and release management.
This presented a problem for SNCF’s larger sub-contractors that were accustomed to using both release and deployment management processes.
The challenge, therefore, was to implement a new tool, create the link between processes and ensure that services were up-to-date and meeting business expectations.
This programme involved workshops with SNCF, including Lean techniques to understand existing processes and the application of ITIL best practices. Ultimately, 550 IT service owners and change stakeholders went through relevant training; for example, this included service owners for an IT application that manages train timetables.
The tool roll-out started in one department within SNCF and was then rolled out more widely in the organization, with a structured ITSM approach based on ITIL.
Consequently, the result of the programme was both completing the deployment of the new ITSM tool and ensuring service owners were happy with the new tool and the associated processes.
Also, the programme managed to de-commission the former tool – usually an activity only for brave organizations!
Going through this type of change with the support of ITIL best practices did provide a great “moment of truth” which only happens when people actually use the new tool and don’t try to revert to the previous tool – now that’s you call success!