Making ITSM a Business ‘Good Practice’

I recently attended a networking event for IT professionals during which one of the speakers discussed “How to Market IT Internally and Externally.”

The presentation’s core message was that every interaction with the IT organization is an opportunity to market the IT organization. Every interaction with IT is an opportunity to influence how the organization thinks about IT.

What Do People Think about IT?

How are the interactions between your IT team and your business colleagues influencing how your leaders think about IT? Are your business colleagues thinking these things about IT?

Does any of the following sound familiar?

• “They work on an island.” IT has no awareness of what’s going on around them within the business.
• “They are focused on the wrong client.” The customer of the business is located outside of the organization, not within the business. IT is too focused on internal things, rather than organizational objectives and goals.
• “They don’t understand the business.” IT doesn’t understand business drivers, the competitive landscape, or the products and services offered by the business.
• “I can’t make sense of what they’re telling me.” IT communicates using technical terms, instead of language that is business-relevant and meaningful.
• “I can’t even ask a question unless I have a ticket.” IT is too focused on executing process instead of delivering business value and a good experience.
• “IT is a black hole.” Reports published by IT have no meaning or relevance to the rest of the organization. There is no transparency into how work gets done within IT.
• “IT never has good news.” The (rare) times communication comes from IT, it’s because a system or application is unavailable. Or there’s always a reason why a consumer can’t do something – with no alternatives offered.

If your business colleagues are thinking one, some, or all of the above about your IT organization, then that is their reality, and it’s time to change how you interact with your business colleagues. Because that reality is a result of how IT is marketing itself with each interaction it has with the business it serves.

And the way to change that reality is to change how they’re thinking. I’ll explain how to do that in a minute.

Isn’t That Why We Rolled Out ITSM?

I heard many (if not all) of these statements when I was first introduced to ITSM…and that was nearly twenty years ago. And from the reactions of those that I observed at that recent networking event, it’s disappointing that ITSM has not been able to advance the conversation. Why hasn’t ITSM helped change the thinking about IT in some organizations?

In my experience, it usually comes down to a couple of mistakes.

• ITSM was approached as a tool implementation and not as a change to how IT did its business. Here’s the scenario: ITSM implementation meant that IT purchased and implemented a few tools – perhaps a couple of those tools actually “talked” to each other and shared data (as in a monitoring tool sent an alert to the ticketing tool to open an incident record!). Perhaps a knowledge base was established, containing articles engineered by the IT team in anticipation of answering questions that consumers didn’t know how to ask. Some visually-impressive real-time dashboard reports were rolled out, depicting information and measures that were meaningless to anyone who did not work within the IT organization. Ticketing systems were implemented that routed work within IT but did little to engage the consumer.
• ITSM implementation meant loosely defining and implementing a few cherry-picked processes, intended to appease consumers’ complaints about working with the IT organization. Here’s the scenario: Maybe IT didn’t even define those processes. Instead, they opted to use process definitions found within those tools that they had purchased, having no idea about the intent or interactions of those process designs. Amazingly enough (are you detecting a note of sarcasm here?), those processes didn’t work so well for the organization; they didn’t facilitate getting work done; they didn’t achieve everything that the tool salesperson had promised.

Does this mean that ITSM (was) is a bad thing? No.

Was ITSM done well? No.

Can (good) ITSM help change the thinking of your business colleagues about IT? Yes.

But to change how your colleagues may be thinking about IT means that IT has to change its thinking about ITSM.

ITSM Must Evolve from an IT “Best Practice” to a Business “Good Practice”

Good service management can change what business colleagues think about IT. But this means that ITSM must evolve from an “IT best practice” to a “business good practice”.

What are the characteristics of a business good practice? A business good practice:

• Consistently drives good business outcomes and value.
• Enables and delivers a good experience, from the customer perspective, the user perspective, and the employee perspective.

This means that for many IT organizations, ITSM implementation must be reoriented on these goals, not internal IT goals.

3 Steps to Transforming ITSM to a Business Good Practice

Here are my recommendations for what IT can do to transform ITSM from being an “IT best practice” to a business “good practice.”

1. Engage leaders in defining your service management principles.

Your business leaders have ideas about how best to leverage and exploit its IT assets. At the same time, IT has a responsibility for the stewardship of those assets. Often, it’s unclear how leaders and IT should interact. This is where a good set of service management principles help. Engage your leaders in defining service management principles (a core concept of the VeriSM™ model). By engaging your leaders in defining these principles, you’ll develop a shared understanding of how the organization wants to approach service management issues such as risk, continuity, experimentation, stability, and so on. These service management principles then become part of the business good practice.

2. Revisit or design service management processes from an agile perspective.

Many ITSM processes suffer from overengineering; that is, the process is more about “control” than “enablement.” With an agile approach, process design or improvement follows an iterative and adaptive course. How? First, you identify and list all requirements for the process – agile calls this a “backlog.” Next, you identify only the few, fundamental, highest priority requirements and design the minimum viable process – the design that meets just those fundamental requirements. Then ask the question – does this design accomplish what the business requires and is the business happy with this design? If “yes” – you’re done. If “no,” pick the next few highest requirements from the backlog, and repeat the cycle. By taking this approach, your process designs will reflect a “just enough” design. As a result, you’ll have much better process adoption and success.

3. Shift the IT mindset from “delivering outputs” to “achieving outcomes.”

Too often, the mindset within IT is only about delivering and counting outputs. IT tends to talk about the number of closed incidents, number of changes implemented, and so on. What are the outcomes that IT delivers or enables? Having answers to these questions shifts the mindset to “what’s best for the business.” This means that IT has to understand the value streams of the organization and how its processes underpin or enable the delivery of those value streams.

Start a New Reality

For some organizations, evolving ITSM from a set of IT best practices to a set of business good practices will represent a significant shift in the way IT operates. IT can no longer act as a service provider to the rest of the organization, but rather must become a partner, collaborator, and difference-maker within the organization. A shift of ITSM to a business good practice will result in a great business-IT relationship.