Following up on what I started in \u00a0up 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\u2019ve 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.\n(I will focus on the incident management process since it\u2019s meat and potatoes and easily understandable by pretty much anyone in IT. YMMV on others, but the gist is the same.)\nAnyone 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).\nSo 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\u2019t focus on improving the abilities of both people and tools to deliver on what they\u2019re 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\u2019s going to do. The capability of doing something differs vastly from the processes that are involved.\nLet\u2019s 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\u2019s 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\u2019t changed in ages.\nThe objective of the incident management process is to \u201crestore service to normal operation as quickly as possible and minimize the impact to business operations...\u201d. 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?\nLet\u2019s go back to the kitchen, then. Let\u2019s 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\u2019s prepared, he\u2019s experienced, and even with poor tools I\u2019m sure he can do a better job than I can. He has the capability to do this better than me.\nLet\u2019s take it a step further. What is the difference between a fast food burger joint and a higher end burger restaurant? They\u2019re 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\u2019s capability to deliver! For example:\nStrategy\nThe 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\u2019t control\nDesign\nLook back to the restaurant example. You go to any of these fast food places around the globe and they\u2019re all the same! Consistent. Familiar. You don\u2019t 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\nTransition\nI\u2019ll be honest. I\u2019ve never worked in the fast food industry, but I\u2019m good observer. All of these fast food places have very detailed manuals, checklists and procedures carefully delivered to ensure that people do what they\u2019re supposed to. That\u2019s a function of transition, not operations! It\u2019s knowledge, changes (that come from the \u2018mothership\u2019 to the franchises) and a controlled environment that is precise to deliver the exact same ingredients, every day, every time\nImprovements!\nDo you think restaurants don\u2019t act upon feedback? They do. And especially the small ones. It\u2019s 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\u2019re acted upon and worth of attention. How does your organization act when feedback comes from your customers?\nSo, what\u2019s my takeaway from this? If your customers are complaining about your incident management \u2018process\u2019 (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?