Service Value System and Continual Improvement Model

A guiding principle is a recommendation that can guide an organization in all circumstances regardless of changes in its goals, strategies, type of work or indeed the management structure. Seven guiding principles we'll look at in more depth in a moment, but here's the list. Number one, focus on value. As you've seen so far with the service value system, value is absolutely at the center, and the co-creation of value is absolutely at the center of everything we do in service management. Start where you are. Chances are that when you put in service management together and service management practices together, services together, there are always going to be elements that you can reuse and that are already successful. You don't have to start from scratch every time.

 

Progressing iteratively with feedback. This is what makes you particularly agile. I think gone are the days of the huge monolithic service management service management implementations. I can remember working on one with an organization some years ago where there were probably going to be six months into an implementation of service management processes before the customer saw any value. That's just not acceptable these days. Collaborate and promote visibility, making work visible. Again, one taken from the Agile world and the Lean world. And collaboration, making sure that the various stakeholders within service management are collaborating.

 

Think and work holistically. We've already seen from the four dimensions of service management what think and work holistically is all about. Keep it simple and practical. Again, borrowing from Lean, making sure that everything that we do adds value. And finally, optimize and automate. So making sure that your processes, once they're adding value, they're simple, that you've optimized those processes, those practices and in particular where you can by putting intelligent automation in to do with the things that you need to do over and over again that a machine can do more accurately and more consistently than a human probably can.

 

As we've already said, everything links to value. If you've got a service and you don't understand what the value is, then why are you keeping it? Value is defined by the customer's needs, something that we've looked out a little bit earlier on in this particular course. Value is achieved through support of the intended outcomes and the optimization of the service consumer's costs and risks.

 

So again, if you remember earlier, we looked at value outcomes, costs and risks, and making sure that we were balancing those. Value, though, changes over time. So you've always got to keep your finger on the pulse of value in an organization, that the value that somebody gets from a service in six months later, might be completely different.

 

So for example, if you look at cell phones and mobile phones and their existence, maybe 10 years ago, people had value just buy coverage. Now it's all about, well, can I get 4G or 5G, or whatever else the next innovation is. So you must always make sure that you're talking to your customers, and over time, ensuring that you're focusing on the value.

 

If you're going to invest in a service, focus on the value and the area that the customer finds particularly valuable. Now, there's actually a process around being able to do this. So let's show you what that is. The first stage is finding out who is the consumer and what is the customer's perception of value. So understanding who are the people who were using the service first, and what they find valuable.

 

As I said, if you want to enhance the service, how are you going to be able to know where to invest without knowing who's using the service, why they're using it, and how they're getting value? So why does the consumer use the service, and what do the services help them to do? So we think about the example we used earlier on. We talked about home shopping.

 

So why does a consumer use the service? What does it help them to do? It helps them to a greater range of products. It helps them to make sure that they're getting what they need, when they need it. How does the service help the consumer to meet their goals? Oh dear, I've forgotten our anniversary.

 

I need to make sure that I've got a bunch of flowers for my wife. So I can use the service to meet my goals. Yeah, I want to stay married. So don't forget your wife's anniversary. And finally there, what are the costs and financial consequences and risks for the service consumer? So again, understanding what are the outcomes they need.

 

What are the costs they are avoiding by using the service? What are the risks they are avoiding? But what risks and costs are we introducing? So if you're going to focus on value, you absolutely thoroughly understand what people value about a service. I'll give you a great example. I recently arrived in the US and I was tracking my Lyft from the airport to a hotel.

 

And I was absolutely amazed that when I sent them a text to say I was ready to be picked up, they sent me back a link so that I could track exactly where my van was, on Google Maps or on Bing Maps, so that I could look and find. They know that what's valuable to the customer is knowing exactly when I'm going to be picked up from the airport to get to my final destination. So what have they two chosen to invest in in the service? They've chosen to invest in the customer knowing exactly when and where their ground transportation is going to turn up.

 

Now it's very, very important with start where you are you don't just focus on reusing technology, or reusing processes. But you look at all four dimensions of service management. So it might be that you'll be able to reuse suppliers, it might be that you're able to reuse technology, information, people, skills, and so on.

 

Understanding the role of measurement as well, what you want to do is make analytical decisions about reusing services and elements of services. So looking out and seeing what exists and being as objective as possible about what exists. Now quite often people will be very, very attached to particular tools or services. And the subjective view is oh, we don't want to lose that tool or that service.

 

Sometimes yeah, you've just got to give it the bullet. When examples, though, of successful practices or services are found in the current state, then you've got to look and see how they can be replicated on, re-factored, or expanded hard to achieve the desired state. So what do you need to do to this? Is it economically viable?

 

What's the risk of re-factoring this to be able to use it again and reuse it? But I'm afraid that sometimes you just got to recognize that nothing from the current state can be reused.

 

Whatever you do, don't try to do everything at once. Sometimes it's unavoidable if you're implementing a service, but very often what you can do is is introduce elements so the customer is getting value pretty much straight away. So starting with something small and building it into a large improvement. I remember an example recently where one organization who were using iPads to go out and collect information and send that back to base, so that they didn't have a double enter information, pictures they took at the location where they were doing the investigation.

 

They were able to send them straight back to base without any problems. What they did, though, rather than implement everything at once, was that the first thing that did was made sure that they could fill in forms on site so that they didn't get any replication errors, and they save the time of double entering data back at base. And then they built iteratively that service. Feedback is an important part of that as well, because obviously if you're going to build something iteratively, then you need to understand is it actually providing the value that the end user wants.

 

So feedback is going to help you to understand whether the end user and customer perception of value created is valid. You will probably have the hypothesis this is how they're going to find this valuable, is that actually meeting its goals?

 

The efficiency and effectiveness of your value chain activities, the effectiveness of the governance around the service, as well as the management controls. So if people want to use the service, people want to access the service, do something differently, is that all working? The interfaces between the organization partner supply and network it's not uncommon now to have services where you've got multiple partners working together.

 

And so to make sure that you've got all those partners working together, and that certainly has helped with the explosion of SIAM, Service Integration and Management, helping organizations to understand whether the services are working together. And the demand for products and services.

 

So obviously the feedback, if you see the feedback saying that the demand for your service is going that way and it's going up, then you're doing the job right. If you see that the feedback and the demand for the service is going down, then maybe that feedback tells you that the consumer now isn't getting the value the user now isn't getting the value they expected from the service. So don't underestimate the role of feedback.

 

Cooperation and collaboration are better than our isolated work what we frequently refer to as silo activity. What's important about collaboration and promoting visibility is absolutely that you involve the right people. That doesn't always mean it's just managers or it's just sponsors. It's all of the potential stakeholders that we looked at before. And that's quite difficult for some organizations, to change their culture where a lot of the decisions have been made by management and management alone.

 

Remember, inclusion is often better than exclusion. What that doesn't mean, though, is let the whole world have a say on everything. You've got to limit it in some circumstances just so that things can happen quickly and in an agile manner.

 

Focus on cooperation and collaboration is absolutely essential much, much better than silos. And if you look at approaches such as DevOps and Agile, and Site Reliability Engineering, they're absolutely trying to get away from the idea of having silos that are based on technology knowledge or whatever else it might be. Identify with whom you should be collaborating that's all down to stakeholder management, which would be a key part of the planning stage of any service management or service improvement initiatives.

 

Making sure that you're communicating for improvement. It's all about, how are we going to get better? Taking away the whole idea of blame culture. It's not necessarily and that actually is very, very difficult for organizations.

 

Remember some years ago, organization was working with, somebody made a monumental mistake one day in prime shift, a mainframe computer. You used to be able to key load them turn a key that effectively rebooted the mainframe computer. A guy did that in the middle of the night one night. We managed to sort it out. The next day, the operations manager was, right, who's to blame for that? And I said, don't care. What do you mean, you don't care? I said, I don't care. It's why did that happen that's way more important and making sure that it doesn't happen again.

 

And that can be a big change for a lot of organizations to go through. Finally, increasing urgency through visibility. It's not just necessarily a manager saying, look, this is more urgent. Using tools such as Kanban boards and so on, everybody can see in front of them what's urgent. And you've got the whole team collaborating and cooperating and looking and saying, look, this is a way that we can all see that this is the most urgent now. And we can work on that and move forwards together.

 

We've already seen the importance of working holistically, in the four dimensions of ITIL and service management. We've got to make sure that, whenever we make a change in one particular area it might be a supplier contract it has a knock-on effect right the way around the system.

 

So, to enable us to understand that, we need to have end-to-end visibility of the systems and the value chains and the work streams, so that, we make a change, we can absolutely understand what the differences are going to be elsewhere. And if we need to compensate anywhere else for the changes we made in, whether it be technology. For example, if you make a change in technology, does it invalidate a contract? Does it need new skills? Does it change any of the workflows? So, lots of things to think and work holistically about.

 

Keep it simple and practical. Always use the minimum number of steps needed to complete an objective. Outcome-based thinking is important, as well. And that should be used to produce practical solutions that deliver the valuable outcomes. So for example, you've got to know what the outcomes look like to enable you to do that in the minimum number of steps. You've got to aim towards a goal.

 

If a process, a service, an action, or a metric provides no value or no useful outcome, then eliminate it. I know organizations that produced reams and reams of reports about various service management services and processes. And I say to them, so what decisions does that reporting help you to make? And they just don't know. So why are you producing it, is the obvious is the obvious retort to that.

 

So making sure that you know what to eliminate and what to keep Start with a very uncomplicated approach. Make sure you do the basics. I've seen again, some organizations who've put processes and practices together for service management. They try to handle every eventuality in the process.

 

And they've just tied themselves up in knots. And if you Google over-engineering you usually see one of their processes on page one of Google. Make sure before you start you agree on not just the outcomes, but the objectives of what service management or the service is actually trying to achieve.

 

Optimization means to make something as effective and useful as it needs to be, so you optimize. It might be that you optimize a change model. It might be that you optimize the incident process. You optimize a service to reduce the number of steps somebody needs to take to maybe make a purchase if you think about one-click purchasing through Amazon and so on and so forth.

 

Automation then typically referring to the use of technology to perform a step or series of steps correctly and consistently with limited or no human intervention. The one thing I would say about automation though is intelligence automation.

 

Don't start out by trying to automate something incredibly complex straight away. No matter what tool vendor says to you that this is the silver bullet. Often, it turns out not to be that silver bullet. So the big rule for automation is intelligence automation.

 

Continual improvement in ITIL uses this particular model. Now, it's a model that survived in ITIL right the way back in pretty much the same form all the way back to a version one of ITIL. And in the 20 or so years that I've been working on service management and service improvement initiatives and continual improvement initiatives, this model has served me well in pretty much every engagement that I've ever had. And the model starts out by understanding the vision. What's the business vision, the mission, the goals, the objectives of the organization? And in some ways, for example, if your organization wants to improve and become more efficient, your organization wants to save costs, your organization wants to improve relationships with its customers, wherever it happens to be then understanding what's that vision, painting that picture of what good looks like for our organization without that and strategic view of things, then you're really going to struggle. What was it that Sun Tzu said in The Art of War, that tactics without strategy is the slowest route to certain defeat?

 

So understanding what the vision is. Next up is, where are we now? So performing baseline assessments. The baseline assessments, again, using the four dimensions of ITIL. Look at the technology and information. Look at the people. Look at the suppliers. Use the different dimensions of ITIL. Where do we want to be?

 

We've got vision. We've got mission. We've got goals. We've got objectives. Now let's have some measurable targets for improvement. So it might be that we want to improve our customer satisfaction rating by 20% over the next six months. We want to reduce the number of failed changes by 20% over the next three months.

 

Give yourself some measurable targets. And then say, how do we get there? Going to the planning stage, defining the improvement plan. This is where your knowledge of service management, your knowledge of ITIL, comes in particularly important, because you've got all of those 34 practices, all of those tools that you've got to use to create what it is you've talked about in your vision, your mission, and your measurable targets.

 

Once you've defined how you've got there, then you've got to take the action basically, to just execute the improvement action. Do it, but remember to do that iteratively, if it's all possible, with feedback. So using ITIL's guiding principles. And then finally, once you've done something, that feedback. We're asking the question did we actually get there?

 

So evaluating your metrics, evaluating your KPIs, to see whether you actually achieved your targets. And then taking it right the way back round to the top is, how do we keep the momentum going? And we've probably all seen it a classic situation in an organization where we have a service improvement initiative, and what we're going to do is we're going to reduce the amount of incidents in an incident backlog.

 

What people do is, they work and work and work and and work and work and work like mad, and they reduce it. And then when they stop working like mad, the number of incidents suddenly starts to increase again. And what we've forgotten to do, often, is keep the momentum going. What do we do to stop that incident queue and that incident backlog building up again? So that's the continual improvement model. What we're going to do now is look at each one of those steps in a little bit more depth.

 

Now what I'm going to do here is I'm going to illustrate this particular improvement model with an example of my own, of a piece of work that I did over about two years with one particular organization in the UK. So we start out with, what is the vision. Now obviously, the corporate vision, something that I always look at before I start on these engagements the corporate vision was this. This was a health care provider in the UK actually, an ambulance service in the UK.

 

And what we did was we did some work with them. And I went and talked to the CIO of the organization to start out where to understand what the vision was for the improvement that we were going to make. And she gave me three different objectives. Objective number one was a fairly simple one. And objective number one was to do with regulation. There's a regulatory body that processes had to pass, so make sure that what you do for me is going to get us past this regulation.

 

I don't want those guys coming in and having to manage those. And so get me through that regulation. But she said, I've got two other objectives. The first one was to improve communication, but in one particular area. And this communication was in the IT team. So between teams, that were silos, and there were people, and there was a blame culture.

 

And what they wanted to do was look at it and say, you guys have got to be working together. You've all got to pull in one direction. And the other one was to do with the communication, and in particular, the communication around failures and fixes, and changes with the customer. So I was given three objectives.

 

Communication within the IT team, communication with the customer, and something that was regulatory. And I said, great, I like working with the three objectives. Now the way we work with those three objectives is effectively, what we do, every idea we have for improvement, we measure against one of those three areas. So we can say we've got an idea for an improvement. OK, how does that help us, is that going to get through the regulations.

 

Is that going to improve communication in the IT team. Is that going to improve communication with the customer. All three of those were at play. And we use them almost as a checklist for every idea we had. And I was given one more element. And that was to make sure that what I had was broad based involvement.

 

So effectively, what she said to me was, I want you to involve as many of our people as is possible. Because she believed and I do as well that the more people that you can get owning an initiative, and having part of that initiative, the easier it's going to be to where to get that initiative to work.

 

If you make an improvement, and it's an idea that somebody has, and they don't follow that idea through, it's a very, very difficult conversations to then have with your manager. And you helped to design this process, and now, you're not following it. Talk me through that one.

 

So it's a difficult conversation I guess, to have with one's manager if you do. So the idea of this, what is the vision is understanding what is it going to be. What's going to be the key areas that we need to focus on as part of our improvement.

 

Now in the particular improvement initiative I've been talking about, we took a whole host of different baselines without knowing where you start. You have no way of knowing how long it's going to take you to get to the finish, how far away the finish line actually is away. So that's one of the things that we're looking at in here. We also got to be very, very holistic about the things that we look at in taking our baselines. So what sort of things did we baseline? Well, we baselined the skills in the organization that people had. They were communication skills and a whole host of other things. We baselined what tools the guys were actually using. We baselined the processes that they were using. We also then baselined the results that they were getting with those particular tools, and the skills, and the processes.

 

What else did we do? We looked at the third-party organizations that they were using, and the contracts and what they were using those guys for. And so we looked at a whole host of different things. Though, as you can see, actually what we looked at there was effectively the four dimensions.

 

Although I've got five up there, we looked at the four dimensions of service management. We were very, very holistic at what we looked at. But what we also did, was when we were doing our baseline and perceptions, we went out and we talked to lots and lots of people art was never a strong point of mine. OK.

 

We talked to lots and lots of people, but we talked to people both from the customer side of the business and from the service provider side of the business as well. And we talked to them at the strategic, tactical, and operational levels, so that we had multiple perspectives from multiple customers, from multiple people who were part of the service provider. And that was in lots of different geographical locations. We didn't just concentrate on the organization's head office. We went all over their estate, in their infrastructure, and talked to lots of different people. And what we had at the end was a very, very good baseline of where we were now.

 

Step three is where do we want to be. So the idea here is we look at a future state, what we want to do eventually is do some sort of gap analysis between where we are now from our baseline that we talk through to where we want to be for the end point. So where do we want to be? Now, in this particular case, what we did was, we went to the organization and we said, well, look, we need some critical success factors, some key performance indicators, so that we can understand what the end game is and where we want to get to. And so what we came up with were KPIs in the areas of customer satisfaction, KPIs from staff surveys.

 

So that satisfied the internal and external communication that we were looking at previously as our high-level objectives. So we had KPIs and targets and goals in there in terms of customer satisfaction and staff surveys. We also had KPIs that, in terms of non-conformance not that we wanted non-conformance, we actually didn't want non-conformance when the auditors came round. So, basically, they were the areas that our KPIs would end. And so for non-conformance, we are to make sure that we had a check less with documentation and that we have proved that we were following certain processes, and so on, that they had to do for part of the organization.

 

So, effectively, what we did was, having taken our baseline, we gave ourselves some targets so that we had that gap analysis between the two where we could look up and think into the next stage how are we going to close that gap. The idea is, what we're not looking for is perfection. If we set out with a goal of perfection, we're going to be sadly disappointed at the end because it's almost going to be impossible to achieve that. So what we were looking for was improvement towards those targets.

 

Now, going back to my example, the way we did it, part of the thing one of the things we did with the baseline was we got people's ideas for improvements, and in all the different interviews we did, we ended up with 37 different ideas.

 

We actually had more ideas than 37, but once we had quite a few that were replicated about improving particular areas. So once we'd sifted them through and put them through a filter, we effectively came up with 37 different ideas. What we did then was we put each of those ideas into a number of categories, and so each idea went into its own category and each category was given an owner. So somebody from some part of the organization was a category owner.

 

They were going to run with the different ideas in that particular category. And obviously, all of the interactions and the dependencies, we understood those as parts of what we were doing. So we gave each one an owner. Now, I cannot under emphasize how important that is that you give each category an owner.

 

And one of the things we did is that they weren't all management owners as well, which helped to achieve the broad based improvement that the CIO was looking for. And in each of those categories we then sat down and decided, using best practice, adopting and adapting it's good solid ITIL how we were actually going to get there. That was the next stage, what we were actually physically going to do.

 

And in doing that, what we also did was we gave each of the category owners constraints in terms of time, cost and quality, in terms of what it was we had to do for each of them. So the 37 ideas went down into I think it was six categories, and what we did was we prioritized within each of those.

 

The category owner then went away and got again multiple people involved. So the category owner usually ended up getting a number of different people involved, which again, went towards the broad based improvement which we were looking for as part of the overall solution. And there we go. That was the next stage, how do we get there.

 

Now, what we did in this particular case was we went into two week slots. We gave people two weeks. And we gave them targets within those two weeks. And we'd review. So we were doing that. I don't think we set out to do anything in an agile way or have anything like scrum masters or whatever in place. But we just decided on those two week slots, simply because what we wanted to do was actually show that through small improvements here, we were going to get a much, much larger picture. So we wanted to see these people were previously very, very skeptical about service improvement.

 

Yeah, and OK, we've seen it all before. And that's because they'd been engaged in service improvement programs that they needed the Hubble Space Telescope to see where the finishing line was, which was never going to be a good idea.

 

So we did those small two week improvement cycles just to show them that they were actually making progress towards the goal. Now, as I say, we weren't completely rigorous about that. Actually, one of the two week slots over Christmas was actually three weeks. So we weren't really, really rigorous, as I say, over those two weeks slots. Now, one of the other advantages was, for an organization that wasn't used to continual improvement, was that very, very quickly, if we needed to, we could change course.

 

And so that was something that we wanted to be able to do. What we didn't want to do was go charging off in one direction and then six weeks later say, whoa guys, you know that's all wrong, because then we'd have said, what we needed to do is change direction. All that work you've done has been wasted. You've got to change direction now. And that would immediately have made people massively skeptical again. So if we wanted to change course, what we needed to do was a little change of course just to keep people onside. So that was part of what we did in terms of delivering the improvements.

 

Well, we did that in a kind of iterative way as well. What we did was the overall program had goals that were set for six months in those overall goals for the program. And we were measuring against those. But what we did with the primary stakeholders was within that. Every month, we had the review with the primary stakeholder.

 

And that's where we could look at the KPIs every month and decide were they still the KPIs because within that six months, it's quite possible that the needs of the business change and that we might need to change direction at some point. So every month, we were looking at the KPIs and our progress towards them with the primary stakeholders. Now don't forget what we just said about the way that we actually implemented this.

 

Within each of those months, what we had was a two two week cycles although one of them was a three week, as you remember but we had two two week cycles within those, within those months. So what we had was that constant review cycle, so we knew very, very quickly if we were going off target, if we needed to reallocate resources.

 

Hopefully, what we were going to get at the end of six months was we were going to get what we were going to get was lots of people who were very, very happy with the outcome and were giving us a big tick.

 

So there were a few tactics that we used in terms of making sure that we kept the momentum going and we didn't, as I say, run out of steam. And one of those was to do with rewarding and celebrating so rewarding the correct behaviors, celebrating some of the successes that we actually had. And there were a number of real, real successes, particularly with the customers of the primary service in the organization, which was to do with emergency call outs for ambulances that the way that they dealt with those people certainly the customer service and the customer the SLAs were only going one way.

 

And they certainly, were the watermelon SLAs that we've talked about previously. So we're rewarding and celebrating was part of what we did. We also made sure that we had a permanent owner for continual improvement, and a new service delivery manager joined the organization only a smallish IT department so it wasn't as if they needed many different people. But we made sure there was a permanent owner for continual improvement to help to keep that momentum going.

 

And when he actually saw that there was perhaps a chance that people were losing faith with it, he was there with a really, really infectious enthusiasm that help to keep them going. And one of the other things we did was once we reached the review meetings with the stakeholders, when we were four to six when we were about four months in, we'd started looking already at objectives for the next round.

 

So we were already thinking about, what's the next part? What's the next way? The idea was that what we wanted to do was get the organization very, very good at these improvement cycles, so we were looking at making sure that they absolutely understood all the way from top to bottom. It's about the vision. It's about making sure that you've got that baseline. It's about making sure that you've got objectives. It's about making sure that you plan if you don't plan, what is it?

 

Fail to plan, plan to fail is the old adage actually making the improvements, learning more about service management, how good service management works, making sure that you've hit your numbers, hit your KPIs, making sure as well that we weren't in a position where we were reaching for perfection all the time because we knew it didn't exist. We knew that improvement was the key to it. We had that broad-based involvement. We had the customer taken along and that's what enabled us to keep that momentum going.