Truth hurts. 3 Truths About Your Service Model Design

Do you know what a great business looks like in the desert? Not a business. That's a good idea gone wrong.

In this post we will cover another good idea that can go wrong real quick – a Service Model.

For those contemplating, in the middle of it, or have just gone through this process and are looking back at it and thinking how can you do this better, faster, cheaper next time, this post is for you.

In this post we are going to cover the three (3) truths about your Service Design:

• It’s not about the standard you follow
• It’s not about technology
• If you need to change, you change.

It’s Not About The Standards

Before you start, or you client starts on your or their change journey, we have to admit one thing – if the Organisation we are trying to change, can’t or won’t change – then maybe WE – the people that are tasked with supporting, leading or guiding the Organisation through the change, need to change. That is – change the way or method we are attempting to change them with.

Often when I join a project, programme or organisation and help them with their transformation, they’ll say “we're a ITIL shop, or COBIT shop, or Agile shop, or Lean shop, or Six Sigma shop, or SOA shop, or BPMN shop, what they are effectively saying is “this is how we have done things around here, and this is how we will do things in the future”.

When you hear that, you have to ask “so, how well did that work out for you?”

You can generally work out how well that worked by the length of time they have been at the transformation or the number of times they have tried it. That can be comforting for some, but the skill here is to separate the method from the person, also called ‘take the emotion out of the equation’.

There are two (2) things you need to be looking out for when you hear the ‘this is how we do things around here’:

1. What you want to be hearing, or looking for in the response to that question where they not actually saying ‘this is how we have done it, and how we will do it in the future’ but actually “we have a preference towards XYZ approach, but we are not closed off or opposed to other methods, standards and approaches”. If you can detect that, you are in with a chance, and
2. It takes a combination of tools, techniques, methods and approaches to transform an organisation. There are no one-size fits all. Different stakeholders see the world differently from others, some are more detailed and need to see the detail, some are more big picture thinkers and doers and need to see the big picture. Trying to get the CEO or C-suite to sign off on detailed process maps is going to be a complete waste of their (and your) time, as is showing financial data and costings to Operations staff. You have to use the right tool for the job.

There’s a little missed trick here I see often, and that's IT will ‘rename’ technology or technical concepts, as business concepts. Unless you are Apple or Microsoft, who are one stage could have said they were a ‘technology’ only house or an IT Organisation (and then they both probably wouldn't say that), they have an IT department that supports the Organisation to execute the Organisations strategy to achieve its Vision.

To impose ‘IT concepts’ on to the Business and get the Business to adopt to the technology – would not be very fair. In a lot of organisations the IT department – although it can contain a sizable 100-200 staff members, is only a fraction of the size of the overall headcount of the Organisation of 1100-1300 staff, yet - the ‘rest’ of the Organisation has to change and use terms that are (1) not native, (2) intuitive to them, but (3) adapt to the 100-200 staff that support them, and we wonder why there is such a high failure rate in digital business-transformations? I wrote about this is a previous post.

To help address the ‘this is how we have always done things around here’, you need to agree with your stakeholders the three (3) L’s:

• Layers – there are different layers within the organisation, Executive/board, Operations, Project.
• Language – different layers have their different language. Use it.
• Level – at those different layers, stakeholders understand different levels of details. Use the right level.

It’s Not About Technology

Designing (and implementing) your Service Model, despite what the name might imply, is not about technology (I’ll leave some tips below, see if you can spot the answer).

Before we get too far, what is a Service Model. A Service Model is also known as a High-level Customer Journey. It is how the Organisation is setup and structured to deliver its service(s) to its Customer(s).

The steps to define the Service Model or the elements of the Service Model - i.e. the parts of the Organisation that are involved, engaged and interact with each other to give that Customer a seamless value-adding User Experience is as follows:

• Step 1 - Identify the User

Note - that wasn’t - identify the 'service, business service or technology service', it was literally - identify the User.

That’s the first tip (the ‘subject’ is in the title)

• Step 2 - Identify their Journey
• Step 3 - Identify the Touch Points
• Step 4 - Identify the Good Points

This is what works well, if you are changing something about this journey, you don’t want to throw the baby out with the bath water i.e. you want to keep the good things. What you do is improve or remove the bad things.

• Step 5 - What are the Pain Points

This is the articulation and visualization of the concerns and needs identified early above in the Stakeholder Mapping. Now you are seeing where in the User Journey these pain points appear, which now you get to elaborate on, because you have context of where they occur now in the User's interaction with the Organisation.

• Step 6 - What are the Improvement Opportunities

These are the candidate of inputs into the solution options, to address those Stakeholder (i.e. User) concerns and needs. As you learn more about the Stakeholder and building up the picture of their experience and interaction with your Organisation, you build up a better and deeper understanding of their concerns, in their own words. In Lean, that’s called Voice of the Customer (VOC).

 Next tip - it’s about the Customer.

Here’s the bonus part…

• Step 7 - Identify the Processes that support those User Journeys, or phase of User Journeys.

What’s is in a Process? - People, Process, and Technology. By understanding what Processes you currently have that support those User Journeys, you know for each process:

• You need People to carry out the work,
• You need a Process to follow, and
• You need Technology (and data) to enable it.

In an ITIL or SOA world, you will either have whole systems or applications supporting all or part of those processes with services, technology services or microservices. But do you know where those 'services' are?

Those ‘technology services’ are literally and figuratively a long way from the Customers mind or point of view, and a long way from the WIIFM in their head and what they are looking for, namely – in terms of the 3 L’s – it’s in a different language, at a different layer, and different level of detail they are familiar with or understand. If you are speaking to the Business with this language, you are going to ask yourself, is what you are saying going to resonate with them, or is it going to be noise?

If You Need To Change, You Change

Sometimes the teacher needs to change.

What’s the definition of insanity? Doing the same thing again and again and expecting a different result.

So is - speaking over someone and expecting them to listen, or presenting to your key stakeholders on your project and/or program information and concepts that are either too high level its doesn’t 'land' with them they don't understand what you are trying to deliver, or its 'too low' in the detail that it’s either overwhelming or too confusing – to your surprise (and frustration) you didn’t “have them at hello”, you had them at “'when is his/she leaving?' or worst 'it’s going to be him or me'.

If you look at all the good speeches of all time or read the latest books of audience engagement the number one thing they will attribute to a successful speech and presentation is one thing - it resonated with the audience.

Why or how did it resonate with the audience?

Most cases it resonated with the audience - is because it hit the 'right notes'. The right notes being - it was pitched at the right layer of the Organisation, with a language the audience understands - often it is in their own language, and at a level they can understand.

The number of times I have seen and been in meeting rooms when the subject matter for the audience was, for the wrong audience.

Tip - if you have to present to a board or room of business stakeholders, either business leaders, department heads or C-level, it helps to do two things:

1. Prior research

Understand what the main concerns and issues are.

When I join a programme this is one of the first activities I do (after determining and agreeing the Vision (I covered this is another post here).

First you understand the Scope via Organisation Mapping (this is wrapping your arms about the scope, what part(s) of the organisation is in scope - divisions and teams), then within those teams, who are the stakeholders (Stakeholder Mapping) and what is their role, responsibilities and concerns and needs. This is where you start building up the picture of What’s In It For Me (WIIFM) for the customer.

It is this point that you start to build up a picture of what the audience is looking that you 1) understand it, and 2) you address it, as you will later be pitching aka presenting back to them your analysis, findings, designs, solution options and road map to implement it.

If you don’t understand their concerns, it doesn’t matter how much work you put in, and how pretty your documentation and presentation is, it will not resonate with your intended audience. What you have done, despite going blue in the face, is created expensive shelf ware.

If you know you have to change but don’t want to admit it. Here’s a little test.

Put yourself in this situation - You are the new CEO. You just joined the Organisation - you don’t have any attachment to the history of what has gone on before, you are focused on results. What would you do?

The key to this is "a good consultant doesn’t have all the answers' he/she has all the questions".

 "a good consultant doesn’t have all the answers' he/she has all the questions".

When I join a project, I am the first to say whether I know the client’s business or not. Most of the time and I admit it, I don’t know their business, and I don’t know the answers, but I have a process. It is my job, as it is any consultant to ask the questions to get the answers out of them.

If you or your consultant or change team come into the situation with all the answers, they are not going to learn anything - namely learn what is wrong, what the problem(s) they are there to solve, what language they speak or the level of detail they need to hear and see, none of anything will land. You will be literally speaking another language to an audience who will 'nod and agree today, that will later push back and reject any formal designs or decisions.

2. The right information

We can all talk about how we live in the information age, and how there is so much information out there, and in our daily lives, and when trying to communicate your message or get through to your customer, it’s all about 'how to cut through the noise.'

This has to be the number 1 rule how to not cut through the noise - keep (attempting) to drum it into the recipients head until they can’t take it anymore, despite the recipient giving clear and visible signs and signals that they don’t understand, it’s too much information, or too little.

It’s not the Business, or recipient that needs to change, it’s YOU!

If you have to change, what does that change look like?

That change looks like a couple of things, but first you need to identify it. Here’s how you identify you need to change:

Step back and look at what exactly is not working?

If it’s too much detail, tone it down a bit. If it’s too little, provide some more.

How do you know the right level? Ask.

Has a customer survey been circulated, and responses received? What did the results day? did they say, 'too much detail?' There are no tricks to this. You need to listen.

Ask yourself - how much information have you got in your packs you are asking your business to review?

If you’re packs have 160+ slides, that’s too many (they exist, I have seen them)!

Humans don’t have the best attention span at the best of times, asking them to understanding different concepts, contexts, implications and dependencies in one sitting isn’t going to end well for you and it’s not going to end well for them. 

Break it up.

There is a reason why a well-structured Business Case has different cases - five in fact - the Strategic case, Economic case, Commercial case, Financial case and Management Case. Each case targeted to different stakeholders.

The CFO and finance colleagues are looking for their ROI and payback, that they will weigh up against all other projects and initiatives across the organisation to support the decisions they need to make. The CEO and other department heads are assessing the management implications to support their decisions they need to make.

So, as Business and Service Designers what did we learn from that?

Nothing... we still try to put as much information into the one presentation or pack and get the target audience not only to understand it, but also interrupt it and then sign off on it?!

Don’t be surprised if conceptually they agree to it as part of the discovery work, and some 4-6 months later when you come back after superficially presenting colour 100+ slide PowerPoint presentations (aka death by PowerPoint), they kindly (or fiercely - depending on how hard you push), you will most likely be meet by equal but opposite resistance.

So, what’s the answer - piece meal. Same one you build a house - building block by building block, blueprint by blueprint.

Show your Business or stakeholders you are impacting - there is a process to developing your Service Design, and each step of the process is made up of discrete building blocks, and blueprints, and you will build up the picture of the final Service Design over time, and if done right, you do it from a Customer-focused perspective, in a language they understand, at a level they understand. I covered this in a previous post here.

There are my 3 truths about your Service Design. 

Hope you find that helpful.

Thank you for reading this!

Sincerely,

Heath Gascoigne

P.S. If you want to join the Business Transformator community of like-minded Business Transformators, join the community on the Business Transformator Facebook Group here.

P.P.S. Have you taken the test yet? Take the Transformation Test and get your FREE 54-page personalised Transformation Scorecard Report and learn your Transformation Score now, check out The Transformation Scorecard here.

For more information, visit https://www.hoba.tech