Instead of IT processes, maybe it’s time to think about capabilities…

Following up on what I started in  up on a concept I started in my previous posts: “It was never about ITIL,” I was thinking the other day about processes. Specifically, the incident management process. Through my career I’ve been in many a company that tried, with varying degrees of success, to deliver on that process. One thing they all have in common is that the incident management process is basically the same everywhere you go.

(I will focus on the incident management process since it’s meat and potatoes and easily understandable by pretty much anyone in IT. YMMV on others, but the gist is the same.)

Anyone in IT with some reasonable experience can describe the process with their eyes closed: something breaks, you check what it is, you attempt to fix, you fix, customer happy. End of process. (Broad strokes, but you get the idea).

So why many companies fail at this, and many other processes? I think that they see the process as an end of itself, but they don’t focus on improving the abilities of both people and tools to deliver on what they’re trying to do. Fix the issue. There are other things outside of the process that need to be considered that build upon the capability of an organization to deliver on what it says it’s going to do. The capability of doing something differs vastly from the processes that are involved.

Let’s go back to basics. Basically, processes transform inputs into outputs. Right? So, using an example from the culinary world, the process of preparing an animal for consumption is, if you think about it, the same across the world. You dispatch the animal, clean, cut, prepare and deliver to whomever is going to consume it. (BTW, sorry vegans. But I guess it’s the same with plants?). There are variations to this process based on where you are in the world; there are regulations to adhere to in many parts of the world versus loose regulations, if any, in other parts. The process remains the same. Just like incident management, it hasn’t changed in ages.

The objective of the incident management process is to “restore service to normal operation as quickly as possible and minimize the impact to business operations…”. Many companies try to execute the process to meet the objectives of it, but what if we focused instead on the organizations capabilities to deliver on those objectives?

Let’s go back to the kitchen, then. Let’s say that I and a world class chef go head to head to prepare a nice Kobe beef burger. Who do you think will cook the best one? The one that has the best ability to do so! (hint: not me!). The process of cooking a burger is the same for both; procure protein, place on grill, heat to desire doneness, serve. But! He’s prepared, he’s experienced, and even with poor tools I’m sure he can do a better job than I can. He has the capability to do this better than me.

Let’s take it a step further. What is the difference between a fast food burger joint and a higher end burger restaurant? They’re both selling the exact same thing (with some variances) and are executing the same process to cook (again, with variances). But what sets them apart? Other things that sit outside of the process that enhance the organization’s capability to deliver! For example:

Strategy

The fast food joint caters to one type of customer, while the higher end one caters to another. They know who their customers are, and what they expect. In ITSM there is such a thing as knowing how your customers use your services, which services they use and so on. Not worth it to pursue issues that you don’t control

Design

Look back to the restaurant example. You go to any of these fast food places around the globe and they’re all the same! Consistent. Familiar. You don’t even have to know the local language to order something, whereas the local joint is unique and bespoke. Design is probably one of the most important elements that an IT organization can use to ensure customers are satisfied, yet it is seldom used. Sweat out design elements, where you can think ahead of many of the things that can happen in operations, and you can probably prevent many things from happening at the operational layer

Transition

I’ll be honest. I’ve never worked in the fast food industry, but I’m good observer. All of these fast food places have very detailed manuals, checklists and procedures carefully delivered to ensure that people do what they’re supposed to. That’s a function of transition, not operations! It’s knowledge, changes (that come from the ‘mothership’ to the franchises) and a controlled environment that is precise to deliver the exact same ingredients, every day, every time

Improvements!

Do you think restaurants don’t act upon feedback? They do. And especially the small ones. It’s their life blood! So much so that negative reviews in Yelp are (sometimes) taken as a big offense. They do listen, and these suggestions for improvement go up and down and around the system to ensure that they’re acted upon and worth of attention. How does your organization act when feedback comes from your customers?

So, what’s my takeaway from this? If your customers are complaining about your incident management ‘process’ (or any other, really) take a step back and think about capabilities; do you understand your customer? Is your design equipped to deliver success down the life cycle? Do you understand how every moving part is related and are you prepared to arm your operations people for success? Are you willing to act on feedback, that may be negative, with objectivity and creativity?