Processes are an Important Part of IT Service Management

When everyone in a team is working together effectively, and chatting to each other in the office, you may not see the need for formal processes. Now that lots of us are working from home, keeping us all safe from COVID-19, we need a little more consistency in our processes, to ensure that we deliver the things that are expected from us.

A very common complaint about IT service management (ITSM) is that it’s focused on the wrong things. Staff blindly follow rigid processes, to the detriment of overall value, customer experience, and necessary innovation. ITIL 4 is, in part, an effort to address these concerns, and I’ve written lots of blogs about it, explaining how this focus on processes can have the wrong results. If you want to read more about this, here are some examples:

• Service Management in 2020 and Beyond
• How Value Streams Can Help you do a Better Job
• The 7 Guiding Principles of ITIL 4: Practical Advice to Help You Make Decisions

This change of emphasis is important, because people in IT do, too often, treat following ITSM processes as their goal, forgetting that the reason these processes exist in the first place is to help create value with and for customers. An exclusive focus on processes like incident management, problem management, and release management often results in staff who are very inward-looking. They strive to make their processes as efficient and effective as possible, even when this has a negative effect on the organization as a whole and a detrimental effect on their customers.

But I was talking to a client recently, and I realized that this change of emphasis can go too far.

Tempted to throw away your #ITSM processes because they're bureaucratic and may be causing conflict and inefficiency in your organization? DON'T says @StuartRance. Share on X

The client thought that what I was saying was that they no longer needed any processes – just empowered staff who knew what they were doing and cared about their customers. And that’s simply not the case. The truth is that you need both. You certainly do need great staff, and a focus on value and customer experience, but you also need great processes, and here’s why.

ITSM without processes

When I started working as a hardware engineer, in the 1970s, we didn’t really have formal processes. IT was a craft, and technologists like me were supposed to make sure it all worked properly. Our entire focus was on the technology, and on how to maintain and improve it.

When something went wrong, we diagnosed and resolved the issue, and the customers were just happy to get their systems back. Nobody really cared about what process we’d followed. We didn’t use a problem management process to identify and resolve the underlying causes of multiple incidents, we didn’t need a release management process to plan and deliver new functionality, and we didn’t need a change management process to review and approve our changes. We just got on with it.

By the mid-1980s, I was a senior support engineer, working for an organization that made computers and software. I was given a project by my management team. They explained that some of our customers really loved us, and our technology, but that other customers kept having issues, and things never worked for them. All these customers used the same products, and my management wanted me to investigate what was going on. So, I interviewed some of the customers, and reviewed the information we had about equipment failures, and then I reported back. It turned out that our happy customers were using processes that they called incident management, problem management, change management, availability management, etc. and they seemed to be in control of what was happening to them. They loved our technology and when there were technology failures they were rarely shocked, or even surprised by them. Our unhappy customers however were stumbling from one technology crisis to the next, with no understanding of why things went wrong, or of how to recover their business processes once we’d resolved an immediate technical fault.

Processes should tell staff what they need to do, but leave them enough flexibility to do their job in a way that creates value for your organization and for your customers – @StuartRance #ITSM Share on X

As a result of this project, we started to teach our customers about ITSM, and to help them put processes in place. This made an enormous difference to their experience of IT, and to the value that IT helped them create. They regained control of their systems and services and were much better placed to capitalize on emerging technology. They used incident management to ensure rapid resolution when things went wrong, problem management to investigate the underlying causes of incidents and prevent future failures, change management to avoid errors when making improvements, and service level management to ensure they understood what they were supposed to be doing.

ITSM with processes that are too rigid

Of course, success breeds its own problems.

Implementing formal ITSM processes resulted in such enormous improvements that people thought they could make things even better by increasing the formality of their processes and making sure they applied everywhere. This led to a situation where following the process was more important than doing what the customer needed. In some organizations change management was so cumbersome that even the most minor change was delayed for weeks until a team of senior managers had reviewed and approved it, and staff who should have been focused on solving incidents were so busy filling in documentation that repair times became longer. Processes became unduly bureaucratic and slowed down innovation.

In some organizations, ITSM came to be viewed as an obstacle to be circumvented rather than a resource to be tapped.

The changes in ITIL 4

ITIL is the world’s leading framework for IT service management, and the latest version, ITIL 4, moves the focus away from processes towards a more holistic approach. It does still describe things like incident management, and problem management, but these are now described as practices, rather than processes. The emphasis is on how they draw on all four dimensions of service management (organizations and people, information and technology, partners and suppliers, value streams and processes), and on how they contribute to value streams that deliver value to all the stakeholders involved. You can read more about the ITIL 4 practices in ITIL 4 Practices – What’s New and Changed.

The solution is not to eliminate processes altogether, but to understand exactly which processes you need, and how formal they need to be in each situation – @StuartRance #ITSM Share on X

ITIL 4 does not eliminate processes from its description of ITSM, it just places less emphasis on them. Every practice describes one or more processes, and provides flowcharts, descriptions, and everything else you might need to get started. There will eventually be 34 ITIL practice publications, but only about half of these have been published so far. You can access these practice guides by subscribing to MyITIL, or you can get one year’s access by passing any ITIL exam.

How to get the balance right

If you’ve realized that your processes are bureaucratic and may be causing conflict and inefficiency in your organization, you might be tempted to throw them away and revert to the situation we had back in the 1970s. This is not the solution.

There are great benefits to using processes, when you need to do things the same way every time. A good process can provide people with guidance and enable them to do a much better job than if you just rely on common sense. It all depends on the processes you create, the precision with which you define what they are, who uses them, and how.

A process can be defined at a very high level, just describing the major steps that should be followed but leaving people free to modify the detailed activities as appropriate for the situation. Alternatively, it can be defined at a very detailed level, ensuring that everyone does exactly the same thing every time. The difficulty is identifying which of these is appropriate for a given situation.

A good process can provide people with guidance and enable them to do a much better job than if you just rely on common sense – @StuartRance #ITSM Share on X

If you really can identify exactly what needs to be done in a situation, down to the last detail, then this is probably something that you should automate. This doesn’t mean that you don’t need a process, just that the process might be improved with automation.

If the situation is more complicated than that, requiring people with knowledge and experience to make decisions, then it’s probably better to define a higher-level process, that sets some constraints but allows sufficient flexibility to do the work well.

If the situation is complex then it may be more appropriate to allow people to experiment and learn, conducting small, safe-to-fail experiments, rather than following pre-defined rules.

You may find it helpful to read about Cynefin to learn more about the difference between complicated and complex situations, how to identify them, and how to manage them.

Conclusion

ITSM processes have a bad reputation in many organizations, and some people think they could do a better job by getting rid of them altogether, relying on experienced people to do the right thing.

This approach could lead to a situation like the one we had in the 1970s, where technologists only focused on the technology, and as a result IT services were unstable and unreliable. The solution is not to eliminate processes altogether, but to understand exactly which processes you need, and how formal they need to be in each situation. Tell staff what they need to do, but leave them enough flexibility to do their job in a way that creates value for your organization and for your customers.