Have you ever been on the receiving end when a new application or service has just been ‘thrown over the wall’ by a project without so much as a manual, and you are left to manage and support a product that you have no clue about whilst the project team sails off into the sunset?
Service Transition can prevent this.
In ITIL-speak: Service Transition ensures that a new, modified or retired service enters (or leaves) the live operational world as smoothly as possible. This process sits between ‘Design’ and ‘Operations’, ensuring that policies, processes and procedures are in place to protect and support the live service.
In a nutshell, the Service Transition process ensures that the operational and service teams have the correct knowledge, skills and expertise to continue Business as Usual (BAU) support after the project has closed.
Among the project deliverables you should expect to see a Service Transition workstream which is owned and delivered by the Service Transition Manager. This means the Service Transition process must be integrated with existing Project Management process, allowing Transition activities and progress to be represented at every stage gate.
If this is done effectively, projects are more likely to land successfully, on time and within the agreed budget, without unexpected cost to the operational teams or worse, the customer.
It is imperative that the Service Transition process is represented and activities considered right at the beginning of the project life cycle, working in tandem with Service Design. Needless to say, this means early engagement is critical.
The Service Transition Manager role acts as the eyes, ears and voice of the operational organisation, and the gatekeeper for BAU support.
The remit of Service Transition within the delivery of a project includes:
The gathering and understanding of the support requirements
Translation of the support requirements into support material – this may include knowledge articles such as Service Support Documents, process flows and runbooks, or activities such as training or shadowing
Capturing the exact nature of the project’s deliverables - what will be the impact, changes and improvements?
Planning and coordination of Knowledge Transfer (KT) sessions with the appropriate teams
Planning and management of Early Life Support (ELS) – are we looking at 30, 60, 90 days? Perhaps a ramp-up, ramp-down approach?
Agreement and publication of both Acceptance and Exit criteria – not all projects realise these are two different things! Acceptance criteria must be met for the product to be progressed into a live environment; Exit criteria comprise the ‘final test’ for the product to leave ELS and move into BAU support
Planning and support of any Dress Rehearsals to test the support material and identify gaps, as well as determine whether more KT sessions are needed!
Leading plans and procedures for decommissioning of replaced or obsolete items – not just products or services, but support artefacts too. Have you got an ELS ticket queue? After the project is in BAU, the queue needs to be closed and outstanding Known Error records handed over to the BAU teams – with their agreement, of course!
Establishing what Resourcing/Staffing need to be in place throughout the project life cycle and going into BAU – will the new service mean an increase in ticket volume, or additional Event Management traffic? What about impacts to downstream systems?
Collaborating with Organisational Change teams to ensure proper and relevant communication of the changes, both within IT and to the customer
Reporting any risks to service in the appropriate place
And lastly, providing regular updates to the relevant operational service folks on the status of the project – they need and want to know, especially if they are taking it on!
Like any process, Service Transition generates key artefacts:
Service Support Documentation
Early Life Support plans
Service readiness checklist
Acceptance Criteria
Exit Criteria
The scale of Service Transition can be as great or small as your organisation’s size and maturity level warrants. The above may seem too much, or even too little: it really is down to you to know what your best practice can look like.
It’s worth noting that successful Service Transition does not happen until an organisation realises the need for it and the benefits it will bring. A robust Transition process is necessary because business operations and processes are in a constant state of change and flux, with technology growth, expansion and creative initiative to support that change a key feature of any successful IT organisation.
With the proper process in place, you should no longer be catching something chucked unceremoniously over the wall. In fact the Service Transition process is the newly built gate between the two worlds. The Service Transition manager holding the key deciding whether the requirements have been fulfilled, the service can be supported and there no outstanding issues. Once all agreed, the project can hand over, shaking hands and sailing off…
Comments