Let’s look at service introduction. Have you ever experienced an IT project landing into production where IT support and business users are surprised (and most likely unhappy)? Did someone forget to tell them about it? The support documents were not in place when you needed them? The service level agreement (SLA) was never agreed? Nobody remembered to create the continuity plan and now the application is down and everything is in chaos? How did this happen when we created such a great system or IT service and have an agreed process for service delivery and service introduction?
Service delivery and service introduction: Where (and Why) Does It Go So Wrong?
The focus driving IT development projects is usually the need to ensure that the solution meets the expectations of the business, in terms of functionality and performance. However, the failure to prepare the organization to exploit, and support teams to deliver it, will adversely impact the outcome of a project, and lead to the perception that the development, while a technical triumph, failed to bring the expected business value at service introduction.
The fundamental issue is that projects and production services, i.e. service delivery, are seen as separate units, even though both should be aimed at achieving exactly the same business outcome. Then the project manager’s responsibility is typically limited to the lifespan of the project and the service manager’s responsibility starts when the new service goes live. With the “handshake” between the project and the service delivery teams often having issues. Does this sound familiar? It should, it’s a common issue and one of the service introduction wrongs being righted by the DevOps movement.
Mending the Project-to-Production Disconnect
For far too long, organizations have been investing time in “reinventing the service management wheel” for each project, when we should instead be working in an agreed, formalized, and structured manner to reduce both the required effort and pain for service introduction.
A pragmatic approach to bridging the gap is to standardize the way in which we create services or, in case of an outsourcing deal, on-board services. In the IT service management (ITSM) world, this process is typically called design coordination, transition planning and support, or service introduction.
In my experience, this service introduction approach can save a lot of headaches for both the project and the IT operations (and service delivery) side of the equation. When people start thinking about the service delivery needs right at the beginning of the lifecycle – before the project has even started! It might sound obvious, but it’s not as common as it should be.
Practical Information on How to Start with Service Introduction
Below I list a few examples of the tasks involved in service delivery and service introduction, mapped to the waterfall project management method for the sake of identifying at which stage they occur. But the same list can equally be used in Agile projects or in outsourcing scenarios.
Initiate:
- Nominate the service owner. You need a person who can make decisions.
- Think about the high-level service level requirements: criticality, availability, and security. You’ll need this information to evaluate whether the service is feasible in the first place, and to estimate how much it will cost to build and run after service introduction.
Plan:
- Nominate the service manager. You need them to be part of the project right from the beginning and to talk with the business about service delivery.
- Agree on the service acceptance criteria and ensure that the required service introduction tasks are also included in project planning.
- Identify the key stakeholders: users, customers, supporting services, dependencies, and all related support functions.
Analyze & Design:
- Conduct business impact analysis (BIA) together with the service owner and service manager. If you fail to understand the business impact of service introduction, how can you create the right service with the right infrastructure, solution, security levels, support model, and enabling services? This will be a basis for your SLA too.
- Design your processes, metrics, and tools. You need to agree who the responsible people are and what the standard changes are for this particular service. Plus, how do you record the SOX control points? How do you configure your ITSM tools in terms of assignment groups etc.? There’s a lot to consider and agree in terms of support.
- Agree what needs to be documented during the service delivery and service introduction project to ensure that everything is ready before go-live? For example, the recurring maintenance tasks – and agree who will create, review, and approve the documents.
Build & Test:
- Agreeing the SLA based on BIA should now be easier. Just make sure it’s also aligned with operational level agreements (OLAs) and underpinning contracts.
- Configure your ITSM tools – assignment groups, access rights, SLAs, etc.
- Create, review, and approve the created documents.
- Plan the continuity arrangements. And make sure that the major incident procedure is clear to all parties. Create business and IT continuity plans together with the service owner, testing/practicing where possible.
- Train your support team. You should now have good support material in hand for service introduction, such as the agreed ITSM processes for the service and the supporting documentation created during the project.
- Prepare your communication templates, distribution groups etc. for the smooth service go-live and service delivery operations.
Deploy (for service delivery)
- Make sure you have a rollback plan.
- Ensure that potential bugs are documented as known errors or problems, and there’s a knowledge transfer from project to operations. Also consider the creation of FAQs or knowledge articles.
- Check whether all deliverables from the original service acceptance criteria have been met and that service introduction can be considered completed. If yes, you can be better assured that you will have smoother go-live and handover.
- Gather lessons learned, give feedback to the service introduction process owner, and improve the process gradually.
In today’s fast-moving IT environment and partner-based ecosystem, the use of standardized service introduction procedures to create, or on-board, new services is now even more crucial. It’s not magic, just a structured way of working. Every organization does most, if not all, of these activities, but the question is: Do you perform the activities in a controlled way, early on when you can influence the decisions made, or do you start firefighting after the go-live when the stuff starts hitting the fan? Surely your service delivery and service introduction capabilities deserve better.
If you enjoyed this service introduction article, here’s something helpful on availability management. Want more? Here are informative ITIL 4 service value system and ITIL 4 service value chain articles.
Elina Pirjanti
Elina’s day-job as a trusted customer advisor in the service management space brings her to the heart of planning and solving strategic, organizational, and governance-related challenges. She is also known for her efforts in supporting and speaking at itSMF and service management events around the world.
2 Responses
Great read,
Many thanks
Shahram
Thanks for sharing useful articles. Would like to receive topics on ITSM tools and Service Introduction including any white papers and blogs.