Have you ever experienced an IT project landing into production where IT support and business users are surprised (and most likely unhappy)? Someone forgot 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?

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.

The fundamental issue is that projects and production services 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 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.

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 approach can save a lot of headaches for both the project and the IT operations side of the equation. When people start thinking about the service management 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

Below I list a few examples of the tasks involved, 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.

Waterfall Project Management

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.

Plan:

  • Nominate the service manager. You need them to be part of the project right from the beginning and to talk with the business.
  • Agree 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, 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 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, 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 operations.

Deploy

  • 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 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 start hitting the fan?