Why is Service Design important?

Over the years I’ve seen many IT departments forget to ask their client (internal or external consumer of IT services) what their needs and requirements are from IT, now and for the next year or more.? They tend to build their IT support models on best practices alone, and whilst this might get them up and running, the lack of client engagement leads to poorly designed services that result in disappointing user experiences, negative feedback, fractured relationships, and escalations that often involve every IT person and Senior Leadership team in the organisation!

Casting a net of negativity to the whole of IT, we miss the fact that IT is critical to business continuity and growth. IT holds the future of the business in its hands, and this is why Service Design is so important.

Within the IT department, you find teams firefighting client escalations, trying desperately to respond to their Senior Leadership requests as quickly as possible; resulting in those teams feeling frustrated, isolated, overwhelmed, stressed and undervalued. Yet nobody can get to the root cause of the issue, instead they try to drive improvements within the IT realms, without ever engaging and understanding the client.

It is a vicious circle. So how do we prevent the blame culture? How do we enable our teams to work collaboratively together and bring their best selves to work every day? How do we delight our client?

I give you the wonderful world of Service Design!

Knowing what IT underpins the business processes is fundamental in supporting your design of IT services. This ensures they are fit for purpose, deliver value, support the identification of risks, support continuous improvements, create innovative partnerships, all the while helping the business to drive growth and support its future. Where do you start, I hear you ask…? first step is understanding your client.

Understand your client!

Understanding your client is critical to the success of Service Design, and making sure IT services are fit for purposes that deliver value to the business.

Key Stakeholders

Looking at the structure of the organisation, interview key business stakeholders (the client) to understand their role and the function of the business unit. Ask what is important to them. To their boss? How are they being measured? Understanding this will help you to know what IT services are most critical to the success of that business function and the team’s delivery to their customers. There are typically five lenses judging the quality and success of a service, they are:?

1. The client - how much are they prepared to pay, what is important to them?

2. The user - how will the service be used and what is important to them?

3. The management team - how much will it cost to deliver and maintain?

4. The providers/support teams - how will it be supported?

5. The market - what are the competition doing?

Often conflict begins in Service Design because of a lack of alignment between these stakeholders/groups. For example, clients may want a cheaper service and may be happy to accept a slower system performance for example whereas the users will complain about this.

Culture

What kind of culture does the organisation have? Where is the company HQ? This will help give you a high-level understanding of how the company might run. But it does not stop there. Company culture maybe prevalent throughout the organisation, however, if the Client has offices located in other parts of the world, you may need to consider the local country culture as well.

Then you will have your stakeholders, and they will have their own individual culture For example, they may want to have a very close relationship with their IT contacts and receive detailed information of the performance and latest updates, on a regular basis; other stakeholders may prefer a more distant relationship, knowing that IT are there providing a service, and just want an online performance dashboard should they want to query something or carry out a spot check.

Everyone is unique, including those who work within the business units and the types of roles performed. It is important to understand the preference on how these teams want to be informed about new IT changes when you implement your Service Design. Are they happy with an email update, a post on their Intranet site, or do they want a more formal group training held?

Strategic Design

What are the clients’ future plans for their business unit? Do they have a strategy? This is important, to ensure that you design for the future and not just for today. What frustrates them about their current IT services? What new innovative solutions do you need to consider that will resolve these issues and help the business grow and develop over time? Going with the trend on what may suit the business today, but as the business pivots in the future, can the technology pivot with it?

Customer eXperience (CX)

From the interviews, you will start to form a picture of what IT services the business is most dependent on and the services most critical to their delivery. The client will not necessarily know what IT is needed, but as a Service Design Architect, you do.

Find out where their IT touchpoints are and if there are any proactive monitoring tools. This will help you design appropriate feedback loops and measurements. These insights will start to show you the tools and meta data points that will be needed for Customer eXperience (CX) performance reports.

Client Persona

Your user research should have helped you to create a client Persona for each business stakeholder. Client Persona’s are a great tool to keep in your toolkit as the relationship develops over time and something you can share with your Service Delivery Managers and/or Business Relationship Managers once transitioned into Operations.

The personas should include key information from your interviews to help with your Service Design:

Service Catalogue

Based on your client research outcomes, you should have been able to clarify the IT services that underpin the business processes, and the categories needed for your Service Catalogue. Based on your IT services, you need to identify what Best Practices (such as ITIL) are needed to deliver those services from your IT department, and potentially back-office functions such as HR, Facilities and Finance will need to be involved. Identifying these functions is called a Value Stream and are all involved in delivering an IT Service to your client.

Service Design Blueprint

The next stage towards writing your Service Design is to create a service blueprint for each of the IT Services identified. An example would be the New Joiner process, as this service touches upon various functions, including IT and back-office functions such as HR. We will use the New Joiner process in our Service Blueprint example below.

Collaboration

To begin, it is important to do this exercise collaboratively in a workshop with the business functions as the key stakeholders who are delivering the service. It is also worthwhile including your client stakeholders who will be on the receiving end and who can provide valuable feedback on the touchpoints. This will be an educational insight for the client and will help highlight where there might be efficiencies within the process where they might be unhappy. If it is something that can be improved, this can be built into the service design.

Risk Log

It is necessary to keep a Risk Log throughout the journey. Highlight any risks or issues that have been discussed with the client that need to be factored in, all the way through to your Service Design workshops, and into Transition. Any IT Risks that cannot be mitigated through Service Design need to be discussed with the right stakeholders and a consensual decision made on how the risk should be managed.

4 Ps of Service Design

The 4 Ps of Service Design are: People, Process, Products (Tools) and Providers (AKA Suppliers). I like to blend these capture points with an added understanding of any other factors that might affect the service, using PESTLE (Political, Economical, Social, Technological, Legal and Environmental).

Example: New Joiner Process

Below is a step-by-step guide to building your Service Blueprint. This is of course hypothetical, in that there will possibly be more, or different teams involved; you will notice the process steps are high-level and linear for this example. It is the role of the Service Design Architect who needs to find the most efficient way of delivering the service and identifying where tasks can be worked on in parallel that drive pace, but still keeps the quality of a service to the client.

1.??????? Process steps need to be documented with your stakeholders to ensure all steps have been captured. I recommend you do this in a linear way first, to help you build out yours and the team stakeholders’ understanding of how each process step will be delivered. When the delivery of each task is clearly understood, you can write the process up again using a process tool to show where work can be done in parallel to other tasks. The narrative of delivery can be described in your service design.

2.??????? People / Functions are next to be identified against the process step. As a Service Design Architect, it is also important that you start writing down the roles & responsibilities of the people who perform these tasks, including the RACI (Responsibilities Matrix stating who is Responsible, Accountable, Consulted and/or Informed) models to help articulate how and when handovers should be given to the next team. You will also be able to document the KPIs (Key Performance Indicators) to help measure the performance of the teams working against this process. When reporting against these KPIs it will help the teams find where further efficiencies need to be made if the process is not working as expected once in Operations.

3.??????? People / Function Emotions need to be uncovered. We ask our clients as part of the interview process how they feel about their IT Services today; we need to do the same with the teams who are delivering the service. This is when you will uncover fundamental gaps in how the service is going to be delivered by the functions.

An example of a situation might be when Team A thinks Team B is taking too long to work on the task and hand over to them to complete their tasks. Team B feels misunderstood and under constant pressure when they are trying to work at their fastest. Team A also feels misunderstood and under constant pressure from the client to deliver. The reason this situation is present is usually because the two teams do not understand each others’ roles and there is no OLA (Operational Level Agreement) in place to set expectation of when the task will be handed over to the following team. This also leaves the client in the dark because they do not know where the service is at in terms of delivery, and there are no expected timescales to know how long they must wait before sending out an official escalation or complaint.

4.??????? Providers AKA Suppliers and Vendors. You need to know what Providers are involved to enable your IT Service to be delivered to your client. This is when you start to think about Supplier Management and seeing if there is a potential opportunity for a SIAM (Service Integration and Management) model or if a SIAM model is already in place, you will need to make sure your design meets the requirements of the SIAM.?

It is at this point you might come across multiple Providers delivering the same services. We had a situation where a client had multiple Wi-Fi providers for their offices across the country. Each supplier had their own unique contract, with different deliverables, measurements, penalties, and charges. When you are in a situation like this, see if it is possible to merge into a single provider. You also need to check the maturity and capability of these providers, and they meet the requirements of the business today and of the future.

5.??????? Product Tools and how they might be integrated is critical to your design. If you are designing an end-to-end service, you need to see what is automated and what is manual. Manual work will affect the delivery of your services and how you will measure end-to-end SLAs (Service Level Agreements); how tasks will be tracked, monitored, and when they have been handed over according to your RACI.

You need a single source of truth for your data and knowing what meta data requirements are needed and where they are coming from, will need to be known to create dashboards and reporting tools. You also need to consider your capacity management, information security management and service continuity management requirements for your client.

6.??????? OLAs in the Service Blueprint image are shown as a linear model which equates to an SLA of 12 business days. But does this meet the requirements of your client? Does it need to be shortened? Can the OLA be negotiated with any of the teams? Can any of the tasks be done in parallel where there is no dependency? Find ways to reduce the OLA and overarching SLA.?

When thinking about your SLAs, you need to consider Availability Management. By understanding your client’s business, it would be good to find out if they have any busy periods throughout the year where their IT services must be at their best performance.

Take airports for example; we know airports are at their busiest over the winter and summer holiday seasons; we know this from how expensive it is to travel at this time of year! When looking at Availability there might be an opportunity to reduce this at quieter times throughout the year.? Doing this can be commercially more favourable to your client because there is less demand for your IT team and could be the best time to implement any new changes to the IT Services when there is less risk to your clients’ business reputation and profits.

7.??????? PESTLE (Political, Economical, Social, Technological, Legal and Environmental) is another set of factors that can be considered when observing any potential risks to your service. The image above shows some examples, but if we just take the first one ‘Technological issue in new joiner struggling to find company policies & processes’ – a solution to this could be implementing an Conversational AI front-ended Knowledge Management system, that allows the new joiner to ask questions through a HR portal or creating a home for knowledge and Q&As via channels such as Microsoft Teams; asking questions about company policies, processes and how to get their IT equipment and to access support through the process.?

Consider the PESTLE factors that are potential showstoppers or can be managed through a workaround. Plan the solution as part of your Service Design. If there are any serious factors that are considered as a Risk, these need to be tracked on the Risk Log with the agreed approach with your key stakeholders.

Your Service Blueprint is now complete! Follow the same steps for each of your IT Services that will reside within the IT Service Catalogue. Other considerations as part of this section are how the teams will manage and forecast Demand Management and Pipeline Management for the requests coming through from the client. One way to help manage the forecast is through a Governance Model. This is covered in the section below.

Governance Model

Your Governance Model should be focused on three core areas. They are Strategic, Tactical and Operational. I would recommend a monthly Service Review Board to discuss the performance of the services with MI (Management Information) Reports, which show service level, technology, and process performance. I would then recommend a separate Strategy meeting that is set up on a quarterly basis and focused on client feedback, Continual Improvement and where the business is going.

From an operational perspective, having regular touchpoints is important; daily office floor walks to see how the business is getting on, meeting key stakeholders for a coffee or lunch, light and simple that helps to build a trusting relationship. Consider the stakeholders who are right for these meetings and if there are any other meetings that need to be scheduled that support the client and the services you are delivering.

Communication Plan

Having a documented Communication Plan is the key to success when implementing a Governance Model. It should hopefully be all on one-page, and it should show your client the structure of the meetings, who they are to be with, why you are having the meeting (include a high-level agenda), the frequency of these meetings, how they will be conducted either face-to-face or remotely, and the medium of the information being shared, i.e. MI Reports from an online dashboard, PowerPoint presentations, Excel spreadsheets, et cetera. ??

Continuous Improvement Feedback

Ensure you have found what feedback mechanisms need to be put in place that support the analysis and discussions for Continuous Improvements to the services being delivered. You could also consider having XLAs (EXperience Level Agreements) in place that help measure the customer experience and report on those.

High-Level Service Design Document

You should be in an excellent position to pull everything together into a High-Level Service Design document for your stakeholders to read and for you to feed into the Transition Plan.

Breaking this down into four headings to capture the key components, but I recommend that you create a template that works for you, your business, and your clients to understand the model you have designed.

1. Introduction

Note the document audience and document version control. Include scope of services for a Service Catalogue.

2. IT Services

Documented best practices (with a focus on their pragmatic application), roles & responsibilities, RACI models, and information on the service availability, capacity, security, BCP and supplier management. Include information on the tools being used in the delivery, and data mapping requirements that need to be captured for MI Reports and service functionality.

3. Service Level Management

Information should include the supporting hours for the services being delivered. The Service Levels – SLAs, OLAs, XLAs and KPIs. Detail how the feedback will be captured for CSIs and strategic planning.

4. Governance Model

The agreed or suggested Service Governance model with the client, based on Strategic, Tactical and Operational meetings that need to be held throughout the year, including a Communications Plan, MI Reporting requirements, key stakeholder mapping and an escalation matrix.

Transition Considerations towards Operations

With all the excellent work conducted through the client user research, service blueprints and governance model into a High-Level Service Design, it is good practice to ensure the Service Design Architect supports the Transition Manager with their project plan and ensure the benefits and values are being realised along the way. I have broken this down into four sections, to help highlight the key activities to be performed in a high-level transition plan in the image below.

This concludes the activities needed when designing new or improving IT Services. I would be interested to know what your thoughts are on my approach where you have experience in this space, and the considerations you needed to make when designing services.

Finally, next time you design a service for your client, remember this quote from Maya Angelou...

?