The acronyms SaaS, PaaS, IaaS and the all-encompassing XaaS are all well understood and in common use in the modern IT world. How about adding another? Transition as a Service (TaaS).
If we put to one side the increasing penchant for organisations to encompass DevOps, and concentrate on the much-favoured model of a delivery function passing a solution to a run team, then we have all experienced a good and bad Transition process.
The main issue is that it can be just that, an inconsistent experience, dependent on the quality of the individual delivery teams and the process they are mandated to follow.
Many organisations have recognised this and have created a central Transition Management function to bring some regularity to the quality of delivery into the run organisation. The main function of Transition Management should be all about risk mitigation. i.e. reducing the risk of disruption to the organisation from implementing change, and by definition, saving expenditure. However, added benefits of Service Transition, starts at the very beginning, with clear and relevant Non-Functional Requirements defined. This is often a glaring omission from the business requirements gathering, but is essential to design a fit-for-purpose Service Architecture.
In many organisations, major investment has been placed into defining a repeatable process, specific to their organisation, that creates set artefacts and transfers knowledge for the solution to be supported successfully.
iCore have been involved in many developments of a Transition Management process, and although every organisation has its own uniqueness, the majority of deliverables are remarkably similar.
Some key points to remember in a Transition Process are:
- It covers the whole project lifecycle, not just the handover when going live
- Assess any potential impact on service asap
- Design flexibility into the process
- Not all projects are the same
- Different risk profiles require more, or less, governance
- Change Management process can cater for low impact projects
- Create reusable Service artefacts
The key to any Transition Management process is to have a defined Target Operating Model (TOM), to deliver into, so it becomes a run and repeat exercise to consistently deliver a quality product. As each project will have a different impact on the TOM, different Service Assurance criteria may be required. A well-defined impact assessment review can tailor requirements, still within the overall process, to identify relevant deliverables. The Transition Management function can then use its gained experience to guide each project manager through the whole process.
Transition can be managed as an externally provided service (hence the TaaS title), with any management overhead the concern of the service provider. A well-defined Terms of Reference (ToR) is essential to give clarity on roles and responsibilities within, and without, the Transition Management team.
By setting up the concept of ‘Transition Factories’ to turn the handle on producing, and gaining approval for, artefacts (Support Models, Transition risks, Service Rehearsal plans, etc.) these can all be delivered to a consistent time and standard.
No specific expertise, or knowledge, of any organisation is necessarily required, so Transition Management can be delivered by a third party and be subject to the usual delivery guarantees of time and quality, while reducing costs.
When selecting a third party to manage Transition, careful consideration needs to take place on where it sits in the organisation. Some have Transition reporting into the deliver space, and some have it in the run space. These often result in an us and them scenario, that hinders progress. Our recommendation is it should sit in neither, and should be seen as an independent trusted advisor to both functions. In a SIaM model, this could sit with the Service Integrator, or be a completely independent partner, it depends on each Operating Model.