Why do service design?

Service design is one of the most underestimated but essential stages of service management. Chevonne Hobbs explains why.

It’s often the case that IT departments forget to ask the client about their business needs, or don’t have the processes in place to make sure those needs are properly understood. As a result, the requirements of the customers are often forgotten during the development or evolution of services, leading to poor communication, constant escalations and fractured relationships.

What’s more, the teams involved in delivering a service will often lack an end-to-end perspective of how the IT service supports the business. As problems occur, each separate function will fight their individual fires without communicating with other teams, often feeling frustrated, isolated and overwhelmed by the problems that service silos inevitably create.

Service design can eliminate these pitfalls, adding the missing end-to-end view by helping all those involved in the delivery of an IT service to understand how it underpins the respective business processes.

Service design aims to make sure services are fit for purpose, deliver value and support business objectives, as well as laying the groundwork for service improvement and future growth and innovation. Done correctly, it will also restore those critical communication channels and help IT professionals to appreciate the value of the part they are playing.

How to capture business needs and requirements

The first stage in the design of a new service is understanding who the client is and what they do. This means meeting with the key stakeholders to understand what’s important to them, what challenges they face, and what day-to-day frustrations they meet in dealing with IT.

As you build this rapport with the client, you can explore what success looks like to them, how this success is measured, and what – in IT terms – you might be able to do to improve their experience. For example, look at the capacity and availability requirements: does the potential demand for a service vary significantly from one month to the next? This information can be very useful in fine-tuning commercial agreements and SLAs.

Similarly, consider the culture of the organisation. Do they expect regular communication and detailed reporting, or do they want the IT service just to happen in the background? Does the business ‘follow the sun’ and rely on services being available in different parts of the world at different times; and does it have multiple suppliers globally, maybe offering duplicated services?

What are the IT touchpoints for the business, the critical services on which they depend, and how will new services impact existing SLA/XLAs? What does their data look like and what mapping will be required? What toolsets are involved (is there any duplication between tools and suppliers that can be rationalised)? And what changes, if any, does the business have planned that could affect the new service and its suitability for the planned role?

Researching the answers to these questions is vital before work actually starts on building a new service, and helps to create a clear picture of what is actually required and where the challenges are likely to occur.

The IT service blueprint

We’re now ready to start the service design, and I would recommend creating a blueprint for each of the services to be delivered to the business. The blueprint views the planned service from the perspective of the 4Ps – people, process, products and providers – and also includes relevant OLA/SLAs and external factors based on the PESTLE model (political, economic, social, technological, environmental and legal). Each touchpoint with the wider environment can be assessed and any trouble spots identified.

In a recent itSMF UK lunch & learn event, I worked through an example showing how the template can be applied to the new joiner process. Members can view a recording of this event in the ‘Lunch & Learn’ section of the event recordings page.

Next stages

Once the blueprint has been agreed and reviewed with all stakeholders, work can also commence on the supporting governance model, communication plan, and more detailed high-level design framework, incorporating tools, RACIs, data mapping, availability, security, S/XLAs and KPIs.

Then finally, it’s time for the transition into operations – the most exciting part of the project – where the benefits of all the detailed planning and design work will hopefully pay off. A good subject for a future blog!