Service Transition has been a recognised phrase since it was coined by ITIL v3 way back in 2007 (and then further tweaked in 2011). Steve Ingall is iCore’s Head of Business Services and he recalls being involved in the review of the Service Transition publications where new concepts and terminologies were being introduced, some of which are still not clear today. We asked Steve, what did he think had happened in the Service Transition space since then and how it needs to further evolve to continue to add business value in the ever challenging IT landscape we face today and into the future.
Q1) Thinking back to 2007 what was the main change that Service Transition introduced?
A. Well apart from the authors perhaps trying too hard to show how authoritative they were and introducing some terms that just confused and didnt really add anything. I think the Service Transition publication and its position in the service lifecycle was the right thing to do. It did provide a better holistic view to the whole change and release processes and introduced the concept of Transition Planning for the first time where instead of the old Software Control and Distribution we were starting to look at all assets within the service, e.g. people, software, hardware, knowledge, locations, processes, documentation, suppliers. It formalised what many transition managers had been trying to do for years.
Q2) How have you seen Service Transition mature over the recent years?
A. I think the whole area of Service Transition has had to grow up fast (I’m not sure it is mature yet). As we burst into the so called Digital Services era and had to grapple with the emerging Agile and Lean methods then never has the old ITIL adage of adopt and adapt been put to the test. Suddenly we were being asked to accelerate the delivery of solutions and to provide high availability, on-line services that were reliable, secure and enhanced the customer experience. The weekly CAB just didnt really hack it any more as digital services demanded changes and fixes to be delivered daily or even hourly. I think the good thing is that in several organisations Service Transition has been growing up at the same time as businesses and IT departments have also had to grow up so that they could adopt Agile methods. This is not true however, for organisations that have only ever existed as digital services where Service Transition has just evolved into a broker role embedded within the Squads and Tribes.
Q3) What do you continue to see as the Service Transition challenges that IT departments face?
A. So far I’ve only really talked about Service Transition in the context of a system development project, and I think most organisations have embraced the need for someone to chaperone the Project Manager to be successful in getting all things done in order to pass through the traditional Go / No Go decision point. The Service Transition discipline is much more than just system development as it can be used to look at transitioning any of the assets I mentioned earlier. For example I have used transition approaches to tackle changes in suppliers (wholesale and through rationalisation); modifying tired sourcing deals; moving 1400 people from one financial institution to a new one, bringing processes back in-house; and even the take-over of a bank by another bank. Each had its own challenges due to the nature of the transition but the approach was always similar. This is where I think organisations need to get to in their own thinking, perhaps even thinking of Transition as a Service?
Q4) How do you see Service Transition evolving going forward?
A. I believe that Service Transition will become a discipline in just the same way that Project Management is today, and I would argue with those organisations that say that Service Transition should just be another aspect of the Project Managers role by advocating that the Transition Manager is there to be independent and objective, ensuring corners are not cut, that risks are correctly assessed and managed, and that the handover from Project to BAU is facilitated such that the BAU Support Organisation is able to fully operate independently of the project as soon as possible. There is another area that I see Service Transition evolving and that is to become part of a wider Lifecycle Assurance process. By this I mean that we need to ensure that the systems that get delivered continue to meet the needs of the business throughout their lifecycle, something akin to a cars MOT which is done at regular intervals to ensure the car is road-worthy. We need to ensure that the systems are still fit for purpose and they have adapted to changes in demand and usage. I can see this being introduced very quickly as Digital Services become more and more mission critical and Agile really kicks in to the application development world.
Q5) What would you say to someone starting out in their first Service Transition role today?
A. Learn from the experience of others and look to see if there is a tried and tested framework in your organisation that you can use. Understanding that Service Transition is about building relationships and facilitating the successful delivery of whatever the change is will be good first step. One thing I would add as a caution is that as a Transition Manager do not get sucked in to doing lots of pseudo project manager activities. I have seen many unsuccessful transitions where the Transition Manager has become embroiled in commercial discussions, or in producing documentation, or undertaking testing, to the detriment of that independent and objective enabling role. And have fun! In summary: Service Transition is becoming an increasingly important discipline in its own right and I believe there is a simple framework that can be adopted that can easily be adapted to work in Waterfall or Agile projects, and on changes that are not system development in nature. Its about building relationships and getting a mutual trust that assures value, quality of delivery and a successful outcome for everyone.