Getting the layout right
When I was a boy, like everyone else I knew, I had a model train set. It was fun to watch the train go round past my few random pieces of supporting infrastructure: station platform, signal box and a footbridge. I recall occasional fantasies of building a ‘proper’ layout with multiple tracks, pretend villages, station and goods yard.
A proper layout required budget, planning and organisation, and probably a rather single minded focus on one dream amongst other options. I was not organised, not driven, not methodical, not focused. I didn’t build a proper train layout, didn’t build my model infrastructure and didn’t grow up to be a project manager. Some with starring roles[1] in ITSM retained and developed their model train sets: I commend these guys because it demonstrates commitment to their goals – and I confess to some jealously.
It’s not always exciting
But, unlike reality, train sets have their station, tunnel, bridges, goods yard, sidings and much more in a very small area. These all make it more exciting, but lack the real world stretches of mile after mile of track going through nowhere without interesting features. And the pretend towns are full of bustle and interesting shops without the sprawl of boring houses full of boring people not doing very much of note.
I find myself falling into the same trap when teaching ITIL – we talk about problems and root causes and change impacts and business continuity plans. This is all exciting stuff, or at least it’s less boring than everyday life. In fact few things are as interesting as disasters and troubles – especially those that have happened to other people.
Success is arriving on time
But the focus on the exception means we overlook that most of the time we are doing the ITSM equivalent of chugging along quietly between towns with nothing much going on. Derailments make the news in real life – or get us involved hands on with our models – but customer success is built on arriving at the station on time.
This should be the prime target for service management where lack of excitement is generally a good thing. Most of the ‘good stories’ and interesting anecdotes relate to mishaps, disasters and – at best – near misses, whereas the real aims of operations is to have only few predictable and easily solved incidents, not to take on the challenge of understanding and resolving out of the ordinary problems.
Teach the bigger picture
Now, I’m not suggesting we should turn over 80% of ITIL courses to talking about the boring bits between issues. It makes perfect sense to focus on those exceptions that actually do dictate the outcomes, those aspects that define the nature of things. What I am asking is that we teach the bigger picture too, specifically:
- ITSM’s main aim – and the default KPI – should be for exciting things NOT to happen
- Key parts of ITSM aren’t about the unusual and understanding it – rather about making things predictable and boring
- We should celebrate making sense of the unknown and solving challenges and mysteries – but at the same time be aware that their existence is not desirable
We get this right occasionally – you will hear more talk about 99% availability than you will 1% unavailability. (Unless you are a customer of course, they tend to reverse that perception.) But we also talk far too much about response and resolve times, and not enough about incident free days, weeks, months and maybe even years.
The goal – not to see our customers
Our customers don’t help us get across a good picture of acceptable service management. It is pretty much an accepted fact that those customers – especially at the user end of the range – are most impressed by the speed and effort we put into fixing errors. Maybe it is something deeply imbedded in the human psyche that we are grateful for other folks’ efforts. But actually what we should want is not to see them.
I think it is programmed into us: certainly where and when I grew up it was. But the more logical thought we put into it, the less sense it all makes. Think, for example, about our firefighters. Of course we need skilled, brave people to deal with emergency situations: to put fires out. But, as a society, our preferred situation should have those guys all at the fire station, playing volleyball[2] and bored out of their minds. When they have an exciting day and get to ride the big red truck, then someone has had their house burn down! Actually the ideal scenario would be to have them out installing and maintaining smoke detectors.
Customers need protective assurance
The same applies to just about every service management set up. What the customers should want is not bold, decisive and impressive reaction, but a protective assurance that they rarely, if ever, need. Explaining this can be hard work, but there are some useful techniques I have found helpful:
- Do they have life insurance, and if so do they want it to pay out, or are they hoping it turns out to have been wasted money? If they don’t want the insurance on their lives paying out tomorrow they shouldn’t want your response team being busy either.
- The best way to increase the productivity of firefighters is to go around setting fire to buildings – does that sound sensible? If not then linking service management productivity with incident fix times is equally daft.
- And, finally, how about a fair metric to be judged on – damage to the business expressed in financial terms? Might that help incite incident, problem, change and other teams to work together and deliver as boring a time as we need?
[1] Rob, James and the others know who they are.
[2] Empirical observation indicates this is the pastime of choice – certainly at the fire station next to the old itSMF UK office it was volleyball most days in the practice yard.
