A simple process that is designed with help from the people responsible for the activity can be very valuable, but if your processes are complex and hard to understand then you may need to think again.
When I was a small child, I was taught to cross the road. We all had to recite the following words:
“Stop at the kerb
Look right again
If all clear then cross”
And we were encouraged to chant these words whenever we needed to cross the road.
Of course, as small children, we didn’t really understand the dangers, and like many others I thought that chanting the magic words would in some way protect me from the nasty cars. I’m not sure I understood that I was supposed to look out for cars and listen to see if there were any cars that I couldn’t see. And what was I supposed to do if I did detect any? Hide from them? Run across the road very fast? What I did know was that if I chanted the right words then I could cross the road. Later research showed that I wasn’t the only child who used these words as a magic chant, rather than as guidance for how to cross a road.
“By the late 1960s, it was clear from a number of studies that the ‘kerb drill’ was outdated. Research now suggested that children learnt it by rote and did not always understand it and that, more damningly, those under nine could not distinguish between the kerb and the gutter, or between ‘left’ and ‘right’.” - joemoran.net
I see something similar in many of the IT service management (ITSM) processes that my customers put in place. Too often they require people to follow a predetermined process, without necessarily understanding why and regardless of whether or not it seems to make any sense.
Many organizations run regular change advisory board (CAB) meetings, to review changes. I see lots of these, and they often seem to me to be very similar to the road crossing activity I learned as a child. The magic CAB meeting is in place to ward off the nasty consequences of a failed change, but there is very little understanding of exactly how it contributes to risk mitigation. What should a CAB meeting do that a competent change submitter can’t do for themselves? What value does it add that compensates for the clear negative impact it has on change throughput? Surely there must be a better way to ensure that every change is reviewed by someone competent to do so, that communicates what is happening to everyone who needs to know, and that facilitates the rate of change the business needs?
I see something very similar in many service desks. The staff are given a script to follow, and they are told that they must ask the questions on the script regardless of the specific issue in front of them, or what they have already been told by the person logging the incident. So, someone phones up and describes an issue they have with their laptop, mentioning that they have rebooted it multiple times. The person on the service desk, follows the script, exactly as they have been instructed, and asks the service user to try rebooting the laptop. Obviously, this doesn’t actually help to resolve the issue. But worse than that, it irritates and frustrates the user, and may make future communication more difficult than it needs to be. It’s great to provide guidance and checklists for service desk staff to use when they are talking to end users, but they are no substitute for training your staff to think about what they are saying and then expecting them to say the right things.
Hospital operations are a great example of where a checklist has been shown to be useful. Obviously, surgeons know that they aren’t supposed to leave swabs and tools inside patients, but mistakes do happen. And getting the surgeon to follow a checklist has been shown to have a significant effect on reducing errors.
“Using a simple surgical checklist during major operations can cut deaths by more than 40% and complications by more than a third, research has shown” – BBC
What is interesting in this case is that the checklist doesn’t tell the surgeon how to do their job – that takes years of training. The checklist is just a single page that can be completed in a few minutes, but it helps to prevent the most common errors.
But it’s never that simple. Surgical checklists alone are not a guarantee of improved clinical outcomes. Analysis of how and why these checklists work reveals that “Effective implementation requires training, coaching, and a change in safety culture,” and that is another lesson that we can apply to ITSM.
I am certainly not suggesting that you should throw away all your ITSM processes. But it is important to make sure that, like the surgeon’s checklist, they are simple and effective. If you create a complex process with many steps that cover every possible situation, then this is very unlikely to be adding value. What you need to do is:
If you have long and complex ITSM processes that prevent your staff from working effectively, then maybe it’s time to review and simplify them. It may seem that the easiest way to do this do is to devise your simplified checklists and processes, and then impose them. But if you do that, you may find, like the well intentioned adults who taught me my Kerb Drill, that the results are disappointing You can’t just install a new culture, but by involving people in the design of simple processes that help them work better, you can start to achieve cultural change – and this may make an enormous difference to customer satisfaction, employee satisfaction, and your ability to do a great job. So why not empower staff with the skills, knowledge, tools, and trust they need to do a great job for your customers? You might be surprised at how well they do.