Most languages/cultures have well-used phrases equivalent to the English “Easier said than done”. That indicates a universal understanding of the commonly massive difference between conceiving of an idea and delivering the result: think ‘I’d like a giant pyramid over there please”. Innovative ideas are a great starting point, but that’s all they are, much work and many sources of potential disaster, remain before realisation, let alone delivery of value. Where does this fit in service management?
I suspect this has been a recurring feature of human engineering over the last few thousand years, there seems no shortage of people who think the job is over once they have decided that something is possible. The problem for many is not necessarily the difficulty of doing it, but simply about getting enthusiasm for the slog of actual build, delivery and maintenance compared with the sharp intellectual pleasure of developing new ideas.
Service management is certainly not immune to this disease; it’s been infected for as long as I have been involved. Some easy examples leap to mind:
- Excitement and activity around introducing Service Level Management is followed by planning, initial meetings to set up an SLA structure, deciding who will represent customers etc. Maybe the SLAs are created, but ongoing monitoring and meetings to discuss tail off quickly and everything goes out of date
- Back in the early days of itSMF we had great meetings agreeing what wonderful things would be done. But three months later it was still just good ideas, and then at the next meeting we came up with new great ideas instead of delivering the ones we had. And in a few years time, we had the first great ideas again.
- Knowledge management: we know that capturing, normalising and maintaining data makes sense, saves money over time and improves service quality through reapplying fixes we already know about. The idea is wonderful but when it comes to doing the work necessary to deliver value, then it’s a case of NiMJD[1].
But for all that, or maybe because of our familiarity with this disease, it’s a well known issue. And there are some well-known ways of addressing it. Things like restricting the funding of new initiatives until benefits from earlier ones are visible, recognising the need for different kinds of people at different stages — innovators and deliverers, and so on and so forth. This is — of course — just applying lessons from everyday life to our own, working environment.
It Depends…
But actually, that isn’t what I want to talk about. In fact I think we suffer at least as much from the opposite situation — what you might call ‘easier done than said’.
What really triggers this for me is the amount of discussion over some of the more theoretical aspects of ITIL. This came to an all time extreme in the ongoing discussion on LinkedIn over whether a password reset is a service request or an incident. You have to wonder how much the sum total of human happiness might have been improved if the hundreds of hours spent generating the thousands of responses to this question had been put to better use.
Every half decent consultant knows that the answer to this question is ‘it depends’. What the consultant has to do is find out the context to come up with the best answer in the particular situation. It isn’t always the same answer for every kind of SM environment.
To a good practitioner it is simply an unnecessary question, because by the time others have debated what label to hang on it, the password has been reset and the user is working again. The practitioner doesn’t need to know what ITIL might call it to know what to do about it.
There are actually rather a lot of these situations. I tried to count in a recent foundation course how many times I used the phrase, and I think we reached double figures. What that means is that if a company wants to do process improvement then as well as the guidance (ITIL, COBIT and the others) they should take good note of what their good people actually do, and not throw it out simply because they cannot immediately match it exactly with Best Practice documentation.
More than book learning…
Service Management is not a method; it isn’t like project management where you make the choice of one approach out of several decent methods on offer. For PM the consistency of that chosen single approach can make sense. But for ongoing SM matching it to the situation is surely more important.
Worrying about the minutiae of the language is tantamount to arguing over how many ITIL angels might dance on the head of an ITSM pin. I’d rather ask why they feel like dancing — did I miss something worth celebrating?
If we follow this idea through it might make a good input to considering where ITIL education might go: because you do need more than book learning to do it ‘right’
I remember when we were about 14, having spent our childhood summers playing cricket in the streets, we wanted to get ‘more serious’ and went to read some books. They were full of complicated stuff and theory that none of us managed — bowling a googly well can’t be done from a set of instructions.
In retrospect the most real piece of advice was from Keith Miller’s book; advice on going down the wicket to deliver an off drive. He wrote ‘positioning of the feet is instinctive’. That was of no help at all at the time, but the older I get the more I realise its value. If you just apply book learning to real life — without some feel and intuition – then it is all going to go horribly wrong.
Of course Miller had an amazing natural talent, but also years of experience of trying it over and over again. Ordinary mortals do require some more guidance, but we should not allow that to stifle good judgement based on local knowledge. As a consultant I rely more on local knowledge than detailed process guidance from a book to ‘get it right’ for a particular customer.
Googlies, cover drives, change management, incident prioritisation and the rest all need some knowledge but they also need practice — and appropriate skills and mindset. I never managed off drives or googlies, but I did discover I could make a fairly new cricket ball swing either way[2] based first on what I read and then on practice and adaption to my style.
Add Gaming and Simulation…
So — should we be doing this more for ITIL and ITSM? Some book learning is perhaps an OK starting point. But we might not want our staff to take years to get competent through practice. And especially we might not want them to practice on the job.
It is a difficult balance, but the challenge of generating the relevant experience is a vital one for any organisation that wants to actually deliver good services, rather than have processes that equate to a number between 3 and 4 on the CMMI scale.
What that might mean is an ITIL — or better yet, service management — education system that focuses rather less on memorising the books and more on getting people to feel what the right thing to do is. Training courses alone can’t do that. Adding in learning through simulation and game playing might address it rather better.
We have heard a good story talked up about the future of ITIL being based on more delivery through simulation, gaming and smart new mechanisms. Certainly Axelos come to the table with considerable experience of gaming and simulation. Marry that to the ongoing pool of industry expertise they have access to and maybe the official ITIL skills industry might get more relevant?
In fact most every organisation has the capacity to practice through simulations they can build themselves. It isn’t a massive job to take some recent history and turn it into a half-day practice session. Have a major issue last year that didn’t get resolved as well as you might have wanted? Why not take that data and roles and re-run it in a meeting room?
ITIL talks about major problem reviews as if they were a do-it-once and file it away thing. But actually they could be a useful ‘get-it-out and dust it off once a year’ thing.
[1] Not in My Job Description.
[2] If you are form the baseball part of the world, think curve balls.
