Branimir Valentic 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.
Organization’s “secret weapon”
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).
Early Life Support (ELS) is your chance to use the knowledge and experience gained in Service Transition once the service becomes live (i.e., enters the Service Operation stage). It is an overlapping phase between the Service Transition and Service Operation phases of the service lifecycle. ELS means that you will keep people from Service Transition (e.g., those involved in testing activities) and let them stay with the service when the service enters the live environment and users start using it.
Activities
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:
- Operational support and knowledge transfer – people from Service Transition (i.e., employees involved in Release and Deployment Management process activities) are working together with Service Operation (i.e., people involved in Incident Management process activities and Service Desk employees) on resolving incidents and any other issue related to the service. In parallel, knowledge transfer takes place.
- Measuring and improving – the service is measured and compared to requirements. There is still a possibility to make corrections (in functionality or performance) or initiate improvements.
- Users – the service is introduced to users, first impressions are picked up, and users are trained on how to use the service. During ELS user documentation can be created or users’ trainings are held.
- Service Level Agreement (SLA) – during the ELS phase, the SLA is finalized. It would be perfect if there is a possibility for an SLA pilot. This will enable you to make final agreement on all details important for a clear and unambiguous SLA – this article contains more details about SLA: SLAs, OLAs and UCs in ITIL and ISO 20000.
The end
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:
- Timely based, e.g., 2 months after the service enters the live environment
- Service owner confirms that the service can be operated according to the SLA with full confidence of their own personnel capabilities
- Based on live environment experience as well as on results of measurement and monitoring activities (e.g., incident resolution time), transition and operation management mutually agree to end ELS activities
The benefit
ELS produces benefits for all interested parties:
- Performance –monitoring and measurement done during ELS enables you to check the quality of the service (i.e., does the result fulfill requirements), as well as gain feedback on the performance of the processes in previous service lifecycle stages (e.g., Service Asset and Configuration Management, Release and Deployment Management process… etc.)
- Service Operation – processes and functions in Service Operation (e.g., Service Desk, Incident / Problem / Request Fulfillment process) gain know-how needed to operate the service (i.e., keep the status-quo of the agreed performance, i.e., service level)
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.
