Is your business suffering from “bad ITSM”?
What does “bad ITSM” look like? Some examples:
- Every request for change (RfC) goes before a change advisory board, because there’s no criteria or models defined that would facilitate reviewing a RfC any other way.
- “Services” are not defined. Instead, the IT organization has a list of the applications, systems, and activities that it supports or performs. Many of the items on that list appear in what is being called a “service catalog”. There is no discussion of how the things on the list add value or provide required outcomes to the business.
- “Service level agreements” are just whatever IT configured within its ITSM tools. No documents describe the value of what IT is doing or how that value is measured or reported. There is no evidence of reviews with the business regarding what is configured within the ITSM tools as “service level agreements”, much less any signed agreements between the IT organization and the business it serves.
- New projects and applications are primarily evaluated based on cost and resource requirements, instead of desired outcomes, opportunities for improvement, and current investments and capabilities. As a result, IT winds up trying to do all projects instead of the right projects- often using the same resources that are already being used to support existing applications, systems, and activities.
Look familiar? You’re not alone. Unfortunately, the above scenarios describe many ITSM implementations – “bad ITSM”.
What is the cause of bad ITSM?
Usually there is no single cause of a bad ITSM implementation. In some instances, a business case was never developed and agreed. If the business case was developed, it focused only on buying technologies rather than articulating the business value and return on investment of the ITSM implementation.
In other cases, a holistic approach to implementation was not used. In these situations, the implementation took on a ‘frankenstein’ approach. The IT organization identified a solution looking for a problem, took some data from here, a tool from there, drafted a couple of resources that weren’t doing anything else and somehow cobbled it all together into some sort of ITSM thing.
Sometimes the initial implementation was very successful. But due to a lack of communications or an agreed plan or management support, the ITSM train lost momentum. The sense of urgency quickly faded and the organization moved on to the next big thing.
But there is good news, even in the face of the bad ITSM implementation. The good news is that you’ve started. But if nothing changes, “started” is where the ITSM implementation will “stop”.
What is the cure?
Like many medicines, the pill may be bitter and hard to swallow. But if the right medicine is used, the result will be improved ITSM health.
The tendency with many bad ITSM implementations is that the organization looked at process improvement only at the process level. The ITSM implementation gets lost in the details of the process and optimizes only a few parts (or a single part) of the overall IT value stream. ITSM becomes the bottleneck rather than the enabler.
The cure? Stop looking at ITSM as a collection of parts. Good ITSM is not just about implementing this process or that tool. Good ITSM must be all about the business you’re serving – in its entirety. This means you must take a “big picture” view and drive ITSM from the top-down.
Why? Because the better your ITSM implementation helps the business achieve its the goals and objectives, the better your ITSM implementation will be. But to do that, IT organizations have to take a different approach to ITSM to ensure the “big picture” view.
Get the “big picture”
Having trouble seeing the big picture? Here’s a few techniques that will help.
- Use “Outside-In” thinking. An “Outside-In” mind-set looks at a business from the customer’s perspective, then designs the processes, tools, and products based on what the customer requires. Good ITSM must take the same approach – look at ITSM from the business perspective and define how IT contributes to what the customer requires.
- Develop Value Stream maps. What is a value stream? A value stream “comprises all the people, activities, departments, and hand-offs necessary to create and deliver value to the customer, be it a product, service, or information”.  A value stream map illustrates that a process (or processes) is a part of a larger ecosystem. Using value stream maps can help prevent a ‘tunnel-vision’ approach to ITSM that results from focusing on process improvement at the expense of the overall value stream.
- Define the Service Portfolio – really. I almost didn’t suggest this approach because many organizations don’t get the concept of a “service” correct, which then contributes to “bad ITSM”. But I also believe that ITSM can be used to help ITSM, and defining a service portfolio is a great way to see the “big picture”. A well-defined and maintained service portfolio demonstrates that the IT organization understands how the services it provides contributes to the success of the business it serves. As business conditions change, the service portfolio changes as well. In other words, IT sees (and is part of) the “big picture”.
Click here to subscribe to my newsletter!
 Michael A. Orzen and Thomas A. Paider, The Lean IT Field Guide (Boca Raton: CRC Press, 2016), p 22.