![Advisera Branimir Valentic](https://advisera.com/wp-content/uploads/blog_authors/branimirvalentic.jpg)
January 21, 2015
I think we would agree that if your organization wants to support a newly developed service, there is a lot of know-how, in respect to that service, needed. The point is, when the service goes into the operational phase (i.e., according to the ITIL – Service Operation phase of the service lifecycle), users start using it. And the usual interaction starts – questions, issues, requests, comments… etc. It’s a live service, after all. There is no extra time to become familiar with the service and build know-how about it. Quite the contrary – the service provider has to stay “one step ahead” of the users, which means that capability has to be built in a short period of time.
Let’s go one step backwards. Change is happening in the Service Transition phase (see this article about Service Transition: Service Transition in ITIL of the service lifecycle – something existed on paper (i.e., the service is documented in the form of a Service Design Package, which is input into Service Transition. This article explains Service Design Package: ITIL Service Design Package – everything under one roof) and at the end of the transition phase it exists as a service. From intangible to tangible – you can use the service, test it, or see the results of it.
Can you imagine the situation: you spent several months building and thoroughly testing a new service (part of Service Transition). The service is deployed and you turn around because – Service Operation takes over. There is no use of gained knowledge and experience if you leave for another assignment. The knowledge and experience you gained in Service Transition can be extremely useful in Service Operation (see this article about Service Operation: Service Operation in ITIL). Otherwise, they have to start from the beginning and try to learn on the live service. That can be dangerous (making unwanted mistakes on the service while it’s in use), expensive, and unprofessional (imagine that you have advanced users who gain know-how faster than the people involved in Service Operation).
Figure 1: ELS – Bridging the operation and transition phases
The nice thing with ELS is that it enables a smooth and controlled handover of the service to Service Operation. It sounds easier than it is. ELS involves many activities; let me mention a few:
It’s nice (from a Service Operation point of view) to have a strong foundation in the form of an experienced deployment team. But, their engagement is time limited. When does it end?
There is no unique answer to that question – it depends on the service itself. What can be done is to define the exit criteria. There are several ways to define exit criteria:
ELS produces benefits for all interested parties:
Users / Customer – right from the beginning, users are instructed on how to properly use the service. They also get the opportunity to compare what they requested with what they got.
Figure 2: Benefits of ELS
On one project, my task was to create a test manual and prepare customer acceptance tests. Deployment started after the customer accepted the service. We also agreed that ELS will last for at least two months, or until all sites are fully functional. During that time, I was 100% involved in all operational issues, as well as customer education. Results confirmed that this was the right approach. As did the customer’s payment.
You can also check out this free Release and Deployment Management (RDM) Process template to get familiar with Early Life Support as part of the RDM process.