tisdag 15 september 2015

How come ITSM seems so hard?

The general perception of the IT industry and ITSM community seem to be that it is very hard to succeed with good ITSM. Nevertheless what framework is used as reference, it still seem to be an overwhelming opinion of unproved value. For every success case there is a dozen questionable.

 

If you do a quick and un-scientific research reading polls, votes from seminars, following discussions online etc. you quickly come to the conclusion that many are struggling. I do not mean struggling in a way that e.g. incident management is failing, but more in the sense that we are good at incident management but the customer is still unhappy. When I'm referring to Incident Management and, therefore pointing towards ITIL as framework it is due to that it is widely used and mentioned a lot. So is ITIL to blame? Well I do not think so!

 

Another finding, considering ITIL here,  is that of the five life cycles in ITIL, Service Operations is dominating in presence and maturity with a decreasing order of Service transition, Service Design, Service Strategy and finally Continual Service improvement (CSI). This strikes me as a very logical also taking into account that there is still an overwhelming opinion of unproved value.

 

Coming back to the "we are good at incident management but the customer is still unhappy". How can it be this way? If we perceive our self as succeeding, how come our business or customers experience us as failing?

 

I do not have the "silver bullet", that is for sure, but I have a gut feeling we had something to do with it :) Looking back on more than a decade trying to find different type of approaches it does not take long to see that again there are scopes and approaches that address Service operations processes e.g. Incident, problem, request but also knowledge, config and change (even if those are Service Transition processes).

 

No wonder we think we are good at it. We have been doing it for ages. If our business and customers where as interested in technology as us we would score jackpot in customer experience ratings. But they are not! They don’t give a crap. They don’t do IT. We do IT and that is the problem. We shouldn’t do IT. We should do business, with the help of, and use of, IT.

 

So the logic here is "to do business", with the help of IT. We need to understand what to facilitate. What is the use of IT meant for? Have we been doing it wrong? Probably if we consider the "we are good at incident management but the customer is still unhappy". Do we need to redo it all over again? I do not think so. What we need to do is to shift our focus and change our scope.

 

Instead of scoping processes solely  from Operations and maybe Transition, reconsider scoping processes to facilitate the complete IT commitment. How a scope could look like is:

 

Strategy and Portfolio Management

Catalog and Service Level Management

Change and Release & deployment Management

Event and Incident Management

 

Now this looks like a scope that would scare any practitioner in both complexity and magnitude. But here comes the strategy. Don't initiate a massive design phase to define all these processes. On the contrary. Skip the design phase and start collaborating with your business to establish a "as is" status description. Define how it is done today, all the way from business idea to run and correct in operation. These processes exist today, I promise you, they exist. Maybe not in writing, maybe not in a complete manner etc. It does not matter. What matters is that you get a description of the actual situation and that it is agreed upon. Skip the ITIL books and start talking to people.

 

Now you know where you are. Its time to use the fifth and most unused lifecycle from ITIL, CSI. If you can agree on a model for HOW business improvement should be identified, decided and prioritized, then you have a tool that will identify the most valuable changes that IT could do to facilitate these plans and ability to follow it up. Now ITIL works as a very good reference for how all processes interact with each other but you will still not find your answer in the books. Use the books as reference in your analysis but never use them as recipe book.

 

With this shift in focus and change of scope your stance is quite different. Your ability to identify and apply improvements that is perceived as valuable by the business should be considerably increased. Now you can, based on business priorities, include additional processes if needed, or increase content of existing processes if needed. Key here is that the expected outcome has to be identified and valuable for the business.

 

Another dimension in this is who does what? I strongly believe that when it comes to "Strategy and Portfolio Management" it should NOT be done by IT. Strategy and portfolio should be done by business. Should IT be involved? Of course! Should IT be participating? Of course! Nevertheless, the ownership should be business. All this is of course supported, interpret and analyzed by IT.

 

Well there you have it. My conclusion that approaches that has a operation and transition focus will end up detached from business comes from the fact that business priorities and value is identified earlier in the complete IT commitment and is a fundamental part of good ITSM.