IT service management (ITSM) is about much more than managing incidents and changes. If you’re not managing services, to maximize the value you create for customers, then this blog will help you get started.
What is IT service management (ITSM) about? A lot of organizations that I’ve worked with would say that the answer is obvious. It’s about managing operational issues such as incidents, service requests, and changes. And, of course they’re not wrong. These things are important; they have to be done, and done well.
But, if managing operational issues is all we think about, then we will never be in a position to provide the services that our organizations deserve.
This is why you need ITSM.
A good starting place for thinking about what we need to do is to think about what we mean by services. ITIL (the leading best practice for ITSM) defines a service as “A means of creating value by facilitating outcomes customers want to achieve…”
This should remind us that the reason for activities such as managing incidents and changes is to create value for our customers by helping them to achieve their desired outcomes. And if we are to do this effectively, we need to understand what our customers are trying to do, and how IT services can help them to do that – so that we are in a position to manage everything required to ensure that the IT we provide creates value for our customers.
ITIL describes a five-stage lifecycle, and 26 processes, which all work together to help ensure that we create value for customers. If you have an integrated approach that ensures your ITSM covers this entire scope, then you are probably doing a great job for your customers.
But many organizations just focus on a few operational processes. If this is true about your own organization, don’t panic. All it means is that you have a great opportunity to improve.
I can’t describe the whole of ITIL in depth in this short blog, but to help you get started, here are a few areas of ITSM where I think many organizations need to invest more effort. To provide a structure for my thoughts, I’ve organized these improvement opportunities by the stages of the ITIL service lifecycle:
Let’s dive in.
This stage of the lifecycle ensures that IT services support the governance objectives of the organization, and that everything done in IT is aligned with the business strategy.
One area of service strategy that is often very weak is business relationship management (BRM). BRM ensures that you understand your customers plans and intentions, and that you design and manage your IT services to support these. It provides a two-way communication channel between management in the customer organization and management in the IT organization and ensures that customer priorities are taken into account when IT decisions are made. If you’re not consciously doing BRM, or it isn’t high enough on your list of priorities, then you’re missing out on the best way of making sure that you are “creating value by facilitating outcomes customers want to achieve…”
This stage of the lifecycle is all about designing new and changed IT services, and ensuring that they are fit-for-purpose and fit-for-use. Service design includes everything from understanding your customers’ requirements, to developing solutions, engaging with suppliers, documenting exactly how the components will work together, and ensuring that the service will be able to deliver value for the customers.
Service design ensures that everything will work together to deliver the expected value. You need it regardless of whether you develop your own software, outsource your software development, or just make use of existing commercial packages. This is because a service is much more than software and infrastructure, it also includes contracts and relationships, supporting tools and processes, training and documentation amongst other things. You can read more about this in my blog Applications are not IT services.
It’s vital to integrate service design with the other stages of the service lifecycle. Some organizations have separate, siloed, teams, with little collaboration between service design activities and operational activities. This results in services that are difficult to operate and manage, poor knowledge transfer from the people who understand how the services work to the people who need to operate and support them, and ultimately in dissatisfied customers and users.
If your ITSM doesn’t include service design, then you should think about how you can increase collaboration across teams to provide a more joined-up approach to creating and delivering services.
Many IT organizations have a change management process that focuses on how to protect the business from the adverse impact of changes. I have written before about the necessity to balance this with the need to support the rate of change that the business requires (What Is Change Management For?), but it’s worth repeating here.
Change management in many organizations is slow and bureaucratic, which makes it hard for new and changed functionality to flow smoothly from design to operation.
Often this is because of the same lack of collaboration between teams that I mentioned above. If ITSM isn’t involved when services are being designed, the first time that ITSM staff engage with a new or changed service is when they are required to manage the change; not only is this far too late to ensure a smooth and effective flow of value, it can also lead to tensions between development and service management teams, with a tendency for both senior management and IT developers to view ITSM as obstructive and lacking in vision.
Another core focus area for service transition is knowledge management. Organizations that are good at capturing, sharing, maintaining, and using knowledge have a huge advantage over those that don’t. If the people who design each service talk to the people who will operate, support, and use the service about what knowledge might be needed, then they can capture this early in the lifecycle, and maintain it as they make changes. This can lead to much better overall outcomes for customers, with better training of users and support staff, more efficient incident resolution, and improved use of the service itself to create value for the organization. See my blog Knowledge Management Is Not Just About Document Repositories for more thoughts about knowledge management.
Service operation is often the main focus of ITSM. Most organizations are pretty good at managing incidents and service requests, but even in this area some things tend to be done less well. For example, problem management can deliver huge benefits by removing the causes of incidents, but many organizations don’t put enough effort into this. This results in IT costs that are higher than they need to be, increased disruption to users and, inevitably, a negative impact on the reputation of the service management team. You can find some suggestions on how to improve problem management in Hide and Seek With Problem Management.
Continual service improvement (CSI) identifies, prioritizes and manages opportunities to improve. This includes everything I have already written about in this blog, and many other things as well. If you’re not confident that CSI is being done well in your organization, here are some blogs that I have written on the topic:
But even if you’re already good at CSI, I hope that this blog has given you an idea or two to add to your CSI register.
The quote “If you always do what you’ve always done, you’ll always get what you’ve always got” has been attributed to a number of famous people. Whoever said it, it is certainly true for ITSM. If you want to do a great job of delivering IT services then you need to think beyond just managing incidents, problems, and changes. Think about everything needed to help your customers achieve the outcomes they desire, and make sure you are helping them. This way you’ll align everything you do behind the most important result – creation of value for customers.
Small improvements to the things you already do can lead to better outcomes for your customers, but you can get much greater improvements by identifying things you haven’t started doing yet and putting something simple in place.