That is an important lesson because many ITIL/ITSM programmes focus on the more exciting prospects when putting together a business case. Twelve months into the programme it can then look like a disaster because the deliverables don't match the promises - even though the programme has actually been a success.
To see why this is let us look at t a little bit of theory. In tune with the whole ethos of CoreITSM I'm going to try and keep this a simple as I can.
This is the Kano model.
You can go away and look it up at the end of this lesson, at which point you'll realise just how much I'm simplifying things. But for now I'm focussing on what is important. OK.
The Must Do Basics
Right, using the Kano model as a tool, think about the concept of basic requirements. That's the bottom curve. These are the things that if you aren't doing right the business are going to notice and complain about.
So start doing them right and everybody will live happily ever after!
Except that isn't the case because doing them right will not have a long term impact on your happiness, or, more importantly, that of your customers.
At the end of year one people will be telling you what a great job you've done getting request fulfilment down to an acceptable number of days. User and customer satisfaction might even go up a a few percentage points.
At the end of year two people will be "like, so what."
After all you are only delivering the service they always expected. Last year they noticed the improvement, but this year they won't notice you delivering the dull old specified service. Not only that, but even if you pull out all the stops, say you get a new user account down form 8 hours to 6 hours, does anyone care if 8 hours is good enough? And you'll have to pull out all the steps, because in year one you will have delivered all the quick wins....won't you?
So what do you do? Well you can move on to address another area of service where you aren't yet delivering the basics. That is always a smart move and there probably will be another basic area to move on to because the chances are high that the pain those long request fulfilment times were causing was masking the pain of something else you've not been doing right.
The Desired Performance
That straight line running straight through the middle of the graph is labelled performance. Start doing them better and the customer will be less unhappy, carry on doing them well and the benefit doesn't stop once you've met the customer expectation. Reducing year on year IT costs for instance, or better still enabling the business to reduce year on year costs. The first couple of years you manage to do it the customer will start to rethink their opinion of IT, the third and fourth years you do it IT will be held up as a shining example.
Here is the good news. There are some things that, once you are delivering the specified service, put a broad smile on the customers face. There's more, these are things that if you aren't doing now the business won't ne that bothered about it. This is the top curve labelled excitement. Here is the bad news, and it is two parts. The first is that until you are delivering the basic service the business won't care how well you are doing in these areas. The second is that things that fall into this category can be hard to come by in the IT services world. This is real Apple territory.
What we might be able to do though, is hit a few points on this line. Winning an award for instance, or getting a senior manager an invite to be a key note speaker at a major industry event.Chose your moment to exploit these.
There are aspects of a service that customers and users don't care about any way. Whether we do them or not neither pleases nor displeases them. Often in IT we make the mistake of thinking the customer cares about something when it is really only important to us. Establishing a CMDB? Who cares outside of IT? The business do care, of course, about the benefits that a CMDB can deliver, but often we mistake the means for the end, and then wonder why the customer doesn't find it a compelling business case. This is the region of indifference within the circle.
I really don't know how to break the news to you, but there are some things we do in IT that the business positively don't like! That's the line running from top left down to bottom right labelled inverse. Things like engineers turning up in sweaty clothes, or treating users as idiots. Just stop doing those things now.
So What Do We Do Now?
Go away and check which of the Kano categories the planned benefits of your ITSM programme fall into. The best way of doing this, of course, is to speak to your users and customers using a simple triple question approach:
1. If we fell short of the availability target would you be:
2. If we met the availability target would you be:
3. If we exceeded the availability target would you be
If the answers are C, B and B than Availability is a Basic requirement of the service.
Build your business case around an undestanding of what success will mean to the business, not what it means to IT.