We need fewer ITSM processes
There are people who work in IT who have no respect for processes. I am not one of them. Processes are incredibly useful. They enable us to document how things should be done, so that we can do them in exactly the same way every time. Put a good process in place and you get greater levels of predictability and more accurate record keeping. Compliance with regulatory and governance requirements becomes easier. In short, good processes maximize efficiency and help to guarantee quality.
So why would I claim that we have too many of them?
To answer that question, we first need to be clear about exactly what constitutes a process. The ITIL glossary tells us that a process is “A structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs.”
Many ITSM activities aren’t really processes
My problem with many of the IT service management processes people claim we need is this. Most of them are NOT really processes at all.
Many of the ITSM activities people call processes don’t, in fact, have a simple sequence of well-defined activities, with defined inputs and defined outputs. They are much more nebulous than this. They have poorly defined activities, no clear trigger for executing them, and a wide range of diverse and poorly defined inputs and outputs that are also not fully defined. Here are some examples of things that I don’t think should be called processes:
- Availability management. Obviously, we need to plan and manage the availability of IT services, and of our IT infrastructure, but there is no simple sequence of activities that can deliver this; and meaningful output needs to be much more than just an “availability plan”. The main ‘output’ of availability management should be the ability to actually deliver services and infrastructure at negotiated and predetermined levels of availability. Modern approaches to availability management include negotiating realistic and meaningful targets and then building anti-fragile solutions to ensure those targets are reliably met.
- Service portfolio management. We certainly do need to plan what services we’re going to deliver to our customers, and we definitely need to understand these services in terms of their cost and value, but service portfolio management is, above all, a governance issue, and often involves investment decisions that will determine a company’s business direction for years to come. It should be carried out by senior management, making investment decisions based on criteria that vary over time in complex ways that simply cannot be reduced to a series of pre-defined steps. If you try to treat portfolio management as a process, you may find that you were focused on entirely the wrong things, and that there were many things that you simply did not take into consideration at all. The outputs of service portfolio management are the decisions you make about how you will manage your investments. Such decisions are never going to be pre-defined.
- Demand management. I do wish that more organizations would carry out demand management as part of their IT planning. This involves talking to your customers, and potential customers, understanding their needs and how those needs are changing over time, as well as influencing customer expectations to ensure that you have a shared and realistic understanding of what it is that you have agreed, and then ensuring that you are able to deliver this. Demand management involves flexible approaches to communicating with customers, and can never be reduced to a series of simple activities.
As you can see from these examples, I am not saying that you shouldn’t do these things, just that they aren’t processes, and that they depend on non-routine activities that aren’t easy to define or document.
What’s a capability?
The biggest difference between a capability and a process is probably that the process delivers a fixed output, whereas a capability enables you to help your customers achieve valuable outcomes.
When you think of what you do in terms of capabilities rather than processes, you adopt a completely different mindset. You move away from looking for detailed process steps, documentation, and metrics; and towards looking for how you can grow and develop knowledge, relationships and maturity. An organization that operates like this will inevitably deliver more value to their customers, and be more responsive to changing circumstances.
I think of availability management, service portfolio management or demand management as being “capabilities” rather than “processes”, and I think that this difference in name is important. You can’t just get a consultant in to document a capability, as you can the steps of a process. Instead, you need to develop it over time, and with a lot of effort. It requires investment in people, in knowledge, and in relationships. The inputs and outputs are not fixed but also develop over time. The payoff is that as a capability matures so does the quality of what you can deliver. You take more factors into account during planning, and the results you can deliver are more sophisticated and valuable.
I am not, of course, suggesting that you simply abandon your ITSM processes. It is very important to identify the things that need to follow a rigid process, and those where flexibility and relationships are more important. For example, you almost certainly need to have a consistent set of steps for creating a new user account for access to a service. This should include making sure that you have all the approvals needed, and that you create an audit trail that meets your governance needs.
But even with something like incident management, I think there needs to be a combination of process activities and more flexible activities. This has been very well described by Rob England in his book Standard+Case, where he argues that some incidents and problems should follow a standard process flow, but others should be managed as cases – making more use of knowledge and experience and less use of rigid process steps.
Conclusion
When did you last review your ITSM processes to see if they deliver the value you need? Maybe it’s time to think again and consider how you can develop capabilities that will help your customers to succeed. If you insist on rigidly following documented processes for everything you do, you might not be creating the best value for your customers.
This work is licensed under CC BY-SA 4.0