Lessons From Beyond the Clouds

My Adventures in the world of thin client computing


We sometimes forget that IT strategy should be driven by business imperatives, and that those business imperatives don't change just because the technology does.

So when we start to look at Cloud and SaaS from  an ITSM perspective we should always keep those business imperatives in mind. It also helps to remind ourselves that the problems the business want the cloud to solve are existing ones.

One of the most interesting projects I've been involved in recently replaced all the client's desktop computers with thin client devices, accessing all applications over a combination of an intranet and the internet and a mixture of internal and external hosting. The thin clients and the infrastructure were all provided  as part of an outsourcing deal.

It was a fascinating experience with novel technology and as you might expect there were major hiccups along the way. What struck me time after time though  was that the challenges and issues from an ITSM perspective were all old familiar friends, but seen in a new light. As the French say

Plus ca change, plus c'est la meme chose

Let us begin with what the business were trying to do, and this was very much a business led change. 


They wanted:

• Reduced and predictable running costs and total lifetime cost
• Scalability 
• A stable platform to enable rapid roll out of new services 

A longer term requirement was to enable their internal services to be made available to other partners and directly to their customers.

Lots of implications obviously follow from these high level objectives. Not all of them were perhaps realised at the time, and others were over emphasised during the roll out of the project at the cost of reducing the overall benefit delivered. Other objectives were also added on during the life of the project, such as integration with the business's green policy.

What about the service management perspective?

Many of these will already be familiar to you, I'm sure.

Service Transition

A major issue, as with so many projects, was that the project team made decisions with a significant impact on the  quality of service that could not be delivered without seeking the approval of the service management team, 

Testing

Many supposedly key aspects of the service were contractually specified as requirements for service acceptance and as targets for the service once it had gone live, but no effort was made to design and build tests during the project stage. Had an attempt been made to develop tests, and integrate them with UAT then someone might have noticed that many of the targets and service levels were nonsensical or ambiguous .

Targets

What do I mean by the targets being nonsensical? Pay attention because this is extremely important. I mean they were:

• Impossible to measure. I mean logically impossible, not just difficult
• Not relevant to the actual quality of service
• Not measuring what people wanted them to be measuring
• Not within the control of the supplier(s) to deliver

In many case these flaws could be traced back to targets being inherited from previous contracts and SLAs. Although the thin client solution highlighted their short-comings the truth is they were never good measures to begin with.

Those that were impossible to measure were often ones that were not relevant to the new architecture. For instance those measuring performance at a component level that no longer existed, or which were now hidden inside the cloud.

Often these were also measures that even if they could be measured couldn't be consistently mapped on to the customer or user experience. As an example because of  the way the system was designed to dynamically reconfigure itself it could run perfectly well one day with two portal servers unavailable, but the next day just one portal server failing could bring the entire service to a halt.

A far to common failing of targets is the seemingly universal flaw in logic which goes like this:

"I want to measure X. I can measure Y. Therefore Y must tell me about X"

How stupid is that, but we do it all the time. Do you measure average call waiting time on your ACD system? What is it that you actually want to know, measure and achieve? 

Write them down. Now.

Yes, I am looking at you, write down what you actually WANT to know.

Some suggestions:

"Do customers ring off because they get frustrated with waiting?"

"Does the call queuing system work effectively?"

"Do I need more staff on the help desk?"
"Do my users have reasonable expectations of the service?"

"How long does it take from a user first ringing the service desk until they speak to someone who can help?"

"How many customers are unhappy about how long they've had to wait for their call to be answered?"

"How many times does a customer call the desk before their call is answered?"

Now ask yourself if average time to answer recorded by an ACD system answers any of those questions.

A classic I came across on this particular project was that it was two years before the service desk provider let slip that they only counted waiting time after the caller had listened to the "Welcome" message. Their target was to pick up calls within 20 seconds. The welcome message typically lasted 45 seconds. Go figure.

And if you want a service delivered over the internet you can't hold your application supplier responsible for the poor transaction response time experienced by a user living on a canal boat moored in a cutting.  It didn;'t stop the user complaining though.

Contracts

Something I've never understood about ITIL, especially considering OGC's wider role, is that it has never addressed that in the UK most IT services are dependent on outsourcing, and contracts are therefore key.

Where do I begin? Well to follow on from the previous section too many contracts are written with what went wrong the last time in mind, which might be wholly irrelevant today. 

Secondly far too often the parties agree on the words, but not on the meaning of the words, and again I'm afraid that ITIL does not address this. We can all agree that a service change should go to the CAB, but that is of little use if we don't agree what we mean by a change to the service.

Language and the Dramadriehoek

Pardon my Dutch. Customers, users, the retained organisation and different suppliers are rather like the Americans and the British. They are divided by a common language, which unfortunately they insist on talking to each other. Those of you, who unlike me, have mastered another language will know the peril of the "familiar friend" that expression you can easily translate into another language, but then has a wholly different meaning. 

Mail me for the sick joke that I could insert here but won't. It was told me by a Collector* in HMR&C**. 

The great challenge for ITIL and ISO 20k has to be understanding how you map supplier terminology onto customer and user terminology throughout the value network.

The Retained Organisation

Another opportunity to spit over you whilst attempting to say "dramadriehoek" The ITIL missing link is the role of the retained organisation/intelligent customer.  You need to understand what role you expect the retained organisation to fill, and  you need to realise that it will change over time. The RO should not be man marking the supplier and providing support when they make mistakes. THe RO should be setting the framework for supplier/customer/user interaction.

Service Credits and SLAs

Welcome to a basic lesson in economics. If I set myself up to deliver service A, and you apply constraints C which have I implications on how I can D Deliver the service...

...You get ACID, which is never good.

Punishing your supplier financially only works in a narrow subset of situations. Forget the sunk cost fallacy, what matters is how you can move forward.

Forget the mistakes of your past... what is it that matters now?

----------

* A very very senior British Customs Officer

** If you want  a good night out go to a Burns Night with  the British customs.The man himself was a "Gauger" A well known founder of itSMF was once found lying in a hedge after one such event. I know it was a good night because after five years I finally understood every word the Scottish CFO at the Passport Office said to me. Pity I didn't understand him earlier when he was teaching me accountancy.

CoreITSM 101: Call a call a call

Contract and SLA negotiation is always an interesting experience., especially when they've already been signed, which is when I usually end up getting involved.

Here is a typical scenario. The original negotiations have been intense, both side think they've got what close to what they want. The big guns have sorted out the sexy clauses. What nobody has noticed is the time bomb lying in wait. Nobody has noticed it because they think it is something they all agreed on, and anyway it is trivial and obvious what the contract means.

What is the time bomb?

It is the clause about the volume of activity that the service desk will handle.

You see for all the good stuff about service strategy in ITIL v3 it is the simple stuff that trips us up time after time. Like saying "calls" when we mean "incidents" or "incidents" when we mean "requests" or...well it goes on, and ITIL, for all the talk of providing a common vocabulary, doesn't always help.

Let me give you a couple of real world examples of the chaos that can be caused both by not using the right words and by not understanding the implications when it comes to setting performance targets and penalties.

An organisation that should know better - not least because it claims to sell ITIL consultancy - outsourced their Service Desk in a separate contract to their main outsourcing deal. The contract specified the number of incidents the Service Desk supplier was supposed to handle and the target time to answer and first time fix rate.

What the supplier did not realise was that the customer considered the number of incidents to be both a target in itself and independent of the other metrics.

Think this through.

The Service desk supplier has limited control over the number of incidents it has to handle. It has rather more control over the number of calls, but we'll save that for the second case. The number of incidents is driven by the underlying quality of the service. In this case they were also classing requests as incidents, and requests are driven by service demand, which again is largely out of the control of the Service Desk.

So we have a supplier being judged against a target that is almost entirely out of their control.

Needless to say the underlying quality of service was not there, and a rapidly changing business model meant large numbers of requests. As far as the customer was concerned this was all the Service Desk's problem.

It goes without saying that handling 25% more incidents the Service Desk struggled to meet the targets for call answering.

Result?

The customer invoked the penalty clauses against the Service Desk provider.
The customer did not renew the Service Desk provider's contract.

The tragedy is it what was a really, really great Service Desk.They were performing miracles to handle the extra calls and stay within budget - a budget that also had to take the hit of the penalty payments.

OK, I hope most people wouldn't be so profoundly stupid, would they?

Case number two is more understandable.

The customer's in house IT had always provided a good basic service and whilst the internal Help Desk wasn't the greatest on the planet it fulfilled the "log it and flog it" role quite well, and because they were good at pro actively informing the user of what was happening the ratio between calls and the combined total of requests and incidents was pretty much 1:1. Unfortunately they didn't really track the difference between incidents and requests. I'm sure you do though, don't you?

For really good reasons they outsourced both the IT infrastructure and the Help Desk to the same supplier, and combined it with a massive change in technology.

In the contract they specified how many calls the service desk should be able to handle.

The supplier did a validation exercise and agreed on the number of calls being dealt with prior to the handover.

This isn't the place to discuss why the technology shift didn't work out as planned, but it didn't.

What is important is that because in the past there had been a 1:1 relationship between calls and incidents/requests the contract only specified expected call volumes.

So what happened?

The technology didn't work, so there were lots of incidents. Because there were so many incidents the desk got overwhelmed, so any pro-active communication went out the window. As a result the number of calls per incident also shot up dramatically to something like 3 calls per incident/request.

The supplier blamed the customer for generating more requests, although they weren't tracking the ratio of requests to incidents despite it being a contractual obligation.

The customer blamed the poor quality of service and the lack of communication back to the users.

And I invoked the penalty clauses and cursed whoever had signed the contract.

It wasn't pretty.

In this case there was happy ending of sorts because a period of stability proved that the customer had specified the call volumes to be expected with a stable service and that the desk the supplier provided could cope with those volumes.

But all that pain could have been avoided if there was a clear understanding of the differences between calls, requests and incidents.

Next we will look at the use and meaning of call, incident, request, ticket, alert and event with an emphasis on their importance in producing meaningful management reports

So what is ITIL?

What is ITIL?

I don't mean in an ITIL 101 type sense.

I don't mean in the glib way a consultant would sum it up on a .PPT slide.

I don't even mean what does ITIL claim to be.

I mean what is ITIL in reality.

I'm not an ITIL v3 expert so I cannot give you a text book answer. Instead here is my own interpretation.

To begin with - what ITIL isn't.

It isn't a standard
Yeah, we all know this. Those of us involved with developing ISO/IEC 20000 can tell you how different it would be if it was. But hey, since we have ISO 20000 so we don't need ITIL to be one


It isn't Proven Good/Best Practice
Perhaps this is less obvious.Once upon a time it was true. V1 was very much based on what good mainframe shops did as a matter of course.  There are still bits of ITIL v3 where this is true. In some areas though you are either getting blue sky thinking without any evidence to support the ITIL position, or you are getting ideas that are dated and basic. Which are which? Hmm not obviously signposted is it?

It isn't Proscriptive
Well it would have to tell you if it was, but it doesn't tell you which bits of it you HAVE to do to provide an adequate service to your customers.

It isn't a Menu from which you can Make Choices
I actually think this is the most dangerous misconception there is about ITIL, compounded by the failure to identify the things you must do to be successful. In reality there is a tendency to drop the difficult but essential bits. That's why ISO 20000 doesn't give you the option to do that. You can chose to miss out a stage of ITIL's change management process, but if you do there is a high probability  your change management process will be fatally flawed.


So What Is It?


Good question. It is neither fish nor fowl., and that I think is a major flaw.

A Compass?
Someone described it the other day as being a guide or a compass. I find that quite an attractive analogy, but one of the key things about a compass is you always know which way it is pointing. I don't think there is a clear North in ITIL.

A Philosophy?
Ivor Macfarlane used to say something along the lines of "The IT Infrastructure Libary is a set of books, but ITIL is a philosophy."

I find that quite an attractive view as well, and ten years ago it is the view that would probably have got my vote. But ten years ago the ITIL community was relatively small , relatively homogeneous and relatively self organising. Most of the people involved had an implicit understanding of that philosophy. Times have changed though, and that is no longer true. We can no longer liver with a disparity between the books and what we really mean

A Statement of Facts?
This is a view that has only really struck in recent weeks. I suspect it is in part my reaction to the view that you can chose the elements of ITIL to adopt, and that you change the meaning of what ITIL says to suit yourself.

It doesn't matter what I say or think, an incident is still  different from a problem. A change is a change, whether I like it or not, and I firmly believe there is only one overall change management process that can work. Marginal costing has a very precise meaning in accountancy. What makes something a contract isn't whether we call it a contract instead of an SLA.

Is ITIL a Map?
Slowly I'm coming to the conclusion that what ITIL is closest to being is a map of the ITSM world. There might be some areas of that world that we don't want to venture in to, but they are still there whether we chose to believe in them or not. There is a way of holding ITIL up against the real world that helps make sense of the real world, but we have to learn what the symbols on the map mean.

Being like a map isn't the same as actually being a map though, and most maps interpret the world through a political lens and can only be based on what we currently know allied to some more or less reasoned supposition.

What I am certain of though is that it ITIL is not to continue getting people lost in the ITSM world there needs to be absolute clarity about what ITIL actually is.