The shortcut to successful ITSM. OPS, did i just say that?

Last couple of months i have read an increasing number of posts and articles addressing ITIL and the challenges with achieving good IT Service Management. All of them are good, some even exceptionally good. I read them and agree with them but they seem to have one thing in common. They are all pointing out the fact that the initiative must be Customer focused. The guiding star needs to be business value. I do not disagree with that. For sure not. Enable business and business value should be the guiding stars and a Customer focus should be main ingredient. 

Reality check.

I made a quick un-scientific search for articles and posts a few years back in time and guess what, we said the same thing back then. There might have been a few differences in the words used but the message was clear. Customer focus, Business value, IT as enabler seems to have been the receipt for ITSM success.

This gives us what?

If this is what we today promote as success factors for ITIL and ITSM i guess we will get the same result in a couple of years as we have today based on our recommendations a few years back. And what was that again. IT organizations still struggling and the community still promoting the same mantra, IT as enabler, business value bla bla bla. 

How can ITIL help?

Do I have an easy answers? No! There are no easy answers. There are no silver bullets. There is hard work and practice. What do I mean with that? If we take a closer look at ITIL there is something called ITIL Maturity levels which i really like. It actually states that every organization, in relation to ITL, has a maturity level that defines where they are positioned based on this maturity model. When taking a dive into this model we find that it is more than just the five main levels. It is multidimensional and a organization can carry out activities belonging to maturity levels both above and below their "actual" level of maturity. This makes things complicated even when simplified to 5 levels of maturity. 

What should we promote?

Is it easy enough to say Customer focus and Business value? I really do not think so. If we consider the ITIL maturity level model, there should be at least 5 different answers (and things are not even that simple). All of them shooting for Customer focus and Business value as their "End game" but there is usually a long way there. If we can not come up with better answers that are more inline with an IT organization needs we will just continue like this until all trust is spent. I know there are really good ITIL and ITSM practitioners and consultants out there but that is not enough. They might know what is needed but the general message is still not useful in the sense that it can be used by an IT organization in general.

ITIL and ITSM contains a lot of culture and you do not change culture. You can change behavior and behavior will eventually change culture. Culture is partly a result of behavior and not the opposite. That would mean that we have to start with a set of practical recommendations that is achievable on the lower levels. Considering that most IT organizations are at the lower maturity levels I guess that the first steps should not be to address IT as a Business, which is the highest level of maturity according to the ITIL maturity model, but that is still what we do.

Each level has its requirements, roles, activities and results. We can not cut corners or do shortcuts. There are effective ways to speed up progress but we can not jump ahead of time. I have the impression that many IT organizations tend to identify themselves higher in the maturity model than they really are. When this is the case there are important fundametal parts missing from lower maturity levels that will result in that the next level will be harder to accomplish, in some cases almost impossible. This is usually due to that some activities that are performed, and some results that an IT organization actually achieve, really are mapped higher in the maturity model but that does not count for everything that they do. We should try to identify ourself in the maturity model from the lowest level of activities and results we achieve, not the highest. This approach enable us to establish all the necessary requirements to evolve and establishes a solid ground to stand on to take the next step in the maturity model. Not to forget, the change of behavior that is established makes sure that the change of culture is also in the progress.

The shortcut to ITSM.

The shortcut to achieve good ITSM is not to think that one can go to the highest level of maturity at once. The shortcut is to establish, practice and verify that each maturity level is fulfilled before trying to address the next one, even if there are few parts of the next one that is already carried out. One step at a time with no leaps of faith. Does this mean that we need to do everything that is written in ITIL. For sure not. To achieve the "End game" there is a lot to do but the key is to identify the basic parts for each maturity level to enable the next step. Not to address the next step and later on realize what was missing. 

I want information and a purpose

I love my work. I am officially a process nerd in everyone's eyes :) But long ago i started to asked myself why. Why do i like it so much? Is it something magical in the processes modeling that makes it so interesting? Is it the creation and visual blooming that occur on a whiteboard when you start drawing it? Is it the pleasure when verifying that the outcome was actually what it was supposed to be? is it the feeling when CSI work starts to show in metrics and KPI's?

There is a lot of joy in the work, thats for sure. But the last years i have seen a pattern. What really is the essence of my satisfaction is in the construction of it all. When you start, you know what triggers it and you know what the outcome should be. In the beginning, everything in between, is just a blur and it is here it starts. Finding all INFORMATION. It is everywhere and it is endless. There are people involved, everyone has their requirements and suggestions. Opinions flow and everything is discussed e.g. tools, user interfaces, routines, sequences etc. It like a wonderful bowl of spaghetti, all nestled in one and each other. 

Sorting out the structure, dependencies, sequence and foremost identify all relevant INFORMATION needed to get to the outcome, is what triggers me. The more information you can get hold on the better, if you are able to structure it, otherwise it can be a nightmare. What i have realized is that i do not want a process, I want an information flow. Information guides me, not a process. I do not care if we are working on the Incident, Change, Problem, Event or any other process. That is so irrelevant as long as the outcome is clear. What is the purpose of gathering the information, who needs it, where does it come from, when is it available, in what context, how should it be structured, when is it needed and the guiding star: what are you supposed to do with the information once you get it, and dont give me any "it is nice to have".

I conducted a brain teaser the other day. I challenged myself to define the major information flows required to replace all the operation processes defined in ITIL. One information flow replacing 5 ITIL processes. I know, it was doomed from the beginning but i did it anyway as an experiment, to challenge the paradigms i have and with a lot of simplifications. Some interesting thoughts arise from it though. Information defined in a process that is needed in the same process is usually structured the way the process needs to consume it. The logic used is based on the logic from the process. When initially designing a process you do it one by one and therefor it makes sence focusing on logic for a specific process. Some examples are -Incidents, they are categorized and structured the way we think is good when it comes to firefighting and analysis of that. -Changes, they are categorized and planned through time and with impact assessments due to the importance of that. And it goes on like that throughout the most of the processes. What if the Incident process had to structure, store and manage all Incident information base on requirements from Change and Knowledge Management, or the Change process had to store and manage all change information based on requirements from Event and Incident management and so on. 

So my mind was set. I would structure all information from one view but which would i take. I started to think of many different views and i asked myself the following question. What do i know about the environment I am trying to define? We are still talking about all the Operation processes in ITIL. What could be the common view? Hmmm the conclusion was that the only thing i know for sure is that whatever we do today, will not look the same in a couple of years. Could i use this somehow in my view for structure? And i could. I asked myself what i could use as a base for something unknown and it was so obvious. Continues Service Improvement (CSI)  is a perfect base for the processes. If we have a process today and we know it will change over time it is CSI that will make it happen. SCI does not only improve something to be quicker, bigger, taller. It changes it as well. SCI is not only vertical, it is also horizontal. If the customer is the focus for SCI and all the processes are based on the ability to perform SCI improvement i think we have very good conditions to actually amaze people.

So if my information structure should be based on SCI, meaning that everything should be initially structured and based on the ability of measuring, reporting and improvement, what would happen? The first thing i noticed was that it all had a big meltdown. Suddenly there were no processes any more. From an improvement perspective the analysis required data from every process every time. That means that already from the the first step in every process, which is registration, the information should be stored and structured from a CSI perspective. That is the only way to secure that it will transform over time, as will the requirements of it (and if CSI is focusing on the customer you can figure out the rest). All this lead me to a quite interesting information flow covering all the major steps in each operation process. 

Just imagine the change impact assessment and risk assessment quality when incorporating historical statistics for issues involving affected HW or SW, persons involvement , time of day, historic availability, incident ratio related to changes, early life support outcomes and the list goes on. Everything i mention here is fully possible already today. There is nothing odd about it. It is already out there. But when i take a closer look at the information itself, how it is structured, shown in UI, ad hoc availability etc. I see that there are limitations due to that the way information is consumed from the process itself often rules and other processes "use what they can", if they want. The information is not isolated but but it is not effort less to use either.

So what will happen in a couple of years? Do we have processes or do we have information flows and rules that guides us from a improvement perspective? I do not know. but i know why i like my job :) I feel like the character Sherlock Holmes, and every day is a new episode with a new mystery that has to be solved. A new unknown that has to be broken down to particles, logically assembled together to create magic. 

I will continue to design and create processes but the process is a byproduct of something larger. The information flow and the improvement requirements is ruling my world. I want information and a purpose.

I want to amaze someone every day.

I have a picture in my head of a circus clown walking around giving children animal balloons, looking into their big eyes filled with amazement while the balloon is slowly transforming into the animal of their choice. I want to amaze people as well. Hell, thats why i go to work every day. But do I amaze people every day. No i do not, but i would like to. There are so much things that "I would like to". I imagine going to work where people were amazed by the things we could do for each other. 

I would like to see the face of the Incident Manager when a new Major Incident has occurred and before she even picks up the phone, all information about the last 24 hours of "tickets of any sort" is nicely structured based on the service and infrastructure involved in the Major Incident.

I would like to see the face of a customer getting a phone call from the Service Desk informing that the issue she experienced earlier is now solved and the customer realizes that she had never reported the issue in the first place.  

I would like to see the face of a manager when her group or function presents their short term and long term improvement plan, without her asking for it. Plan based on quality measurements and KPI's when she understands that it will solve the stuff her boss been nagging about. 

I would like to see the face of service customer when IT, in a constructive way, explains the implications, alternatives, risks, options and costs associated with their latest demand in an understandable way without one single IT term.

I would like to see the face of a coworker when a colleague steps up and says that I think you are doing a great job and leaves without expecting and answer or gratitude. 

I would like to see the face of a customer when IT calls to offer a new service which solves the issues identified ahead.

I would like to see the face of a Service Desk agent when she answers a call and all information of the caller is automatically shown and interactive on her screen. The callers used services and applications, related events, related ongoing and resolved incidents, related earlier issues, related scheduled and performs changes etc.

I would like to see the face of a service responsible looking at a KPI dashboard realizing that it actually says something. No analysis is required and countermeasures and success factors are obvious and clear.

I would like to see the face of the service management tool responsible when a requestor specifies new demands by explaining their expected outcome, purpose and information required to get there instead of requesting new fields, forms and buttons.

I would like to see the face of a Operations Manager when realizing that the Problem Management Process he really did not want or understand actually solved the long running issues they have been struggling with and a happy customer just call him to tell him that.

I would like to see the face of a coworker using a whiteboard marker that actually work.

I would like to see the face of me when this list is fulfilled.

Well as you can se there is a lot of things "i would like to" and the list continues. Some day I will get there. That is my unswerving conviction and firm belief. call me a naive, thats ok. I think it is a compliment. 

What does a 5 year old know about Service Management

More than a week has passed since we arrived here in Torrevieja, Spain. I have spent every hour with my family and foremost my 5 year old daughter. She has a wonderful way of looking at her surrounding which is not influenced by anything else than her own needs. What can she teach me about Service Management regarding that she only sees the world from her own needs and nobody else's. well, it turns out that it is a lot. One would think that everything she does is based on that the supplier, thats me, facilitates it for her. Nothing could be more wrong. It turns out that I am the customer and her needs are connected to mine. Let me clarify. If we are playing in the pool and it is lunchtime I would say that we need to go and eat. Her reply is, of course dad, then we can play some more afterwards. She projects our need to eat, to gain more energy to play. This way I get exactly what I want. Her getting out of the pool without any fuzz and kindly accompany me to the meal. She gets a dad that can't say no to some more pool time due to her excellent behavior. 

Later on that evening we all go to a big shopping mall in the area. She knows that there are carousels there and tags along, again by acting excellent. Once there, the wife wants to enter and browse every shop in the mall and here she amazes me again. My daughter pulls my hand and says. Mom can look in the stores while we have ice cream over there and points with her finger. My wife thinks it is a great idea and off we go to buy ice cream. Just next to the ice cream shop there is a carousel. In the line she looks at me and says. You can have an ice cream and you can sit right there on the bench while I take a ride on the carousel. How do you say no to that? She is the happiest kid in the world when her hair waves in the air while riding a big bunny. I feel like a king just looking at her and knowing that my wife is in shopping heaven. 

It turns out that my daughter is the supplier that fulfills my needs but she makes sure she gets paid. The days continue like this where she identifies my needs, justifies them with something she needs and, BOOM, she has a sale. You might say that c'mon, this is what kids do. They manipulate you this way and you as a parent think it is amazing and falls for it. All I can say is that you are so right. But I prefer it this way. We agree and get along. Well there are days where things do not ..... Lets just say that there are days :) 

If I could identify the needs of my customer, make sure they where fulfilled and made sure I got what I wanted for it I would say that I had a pretty good Service Management day. Wouldn't you? Kids can teach us to see things in a simpler way. In their world nothing is complex and anything is achievable. 

Who is the customer of IT?

I know, business first. The following scenario is not a contradiction to service management and customer-centric focus in any way or an attempt to say its wrong, i am a strong believer so do not get me wrong. I like to challenge anything comprehensive and try to simplify it a bit too far. Lets just skip the traditional thinking and look at IT equipment as means to do something. The person that is trying to do something with the help of IT equipment is an IT consumer. The consumer has goals and needs just like anybody else independent if they work within IT or not. Hopefully everybody's goals are aligned so that they all work for the same cause, business and IT. Lets take a look at a normal situation where IT has staff that handles tickets in an ticket handling tool. There is also a Business application where business staff performs their work.

In both cases there is an application and a users of that application. One significant difference though is that the IT staff is using their application when there is an incident/change/request on the business application. I know it is very simplified but anyway. Who is the customer in this case? Where can we do improvements that could have significant positive impact on the final cause that all are working to achieve. Should not we treat IT staff the same way as business staff? IT staff has goals and ways to achieve them with help of IT equipment (the ticket handling application for one). Now this is getting a bit complicated if we say that IT itself is delivering services within IT. But is not that the case?

When talking about IT Service Management we always talk about the business customer and the importance of understanding their needs and to empower them in achieving their outcomes. IT should measure it's contribution to that and so on. I do not disagree but i play with the idea of performing IT Service Management within IT. There are probably tons of stuff we could do better by behaving more as service providers within IT itself. Lets continue on the scenario mentioned earlier. 

Lets treat the IT support organization as the customer. That includes anybody within IT (could also be external providers) that is involved in handling an incident/change/request (lets call them interactions). Of course the handling of any "interaction" inherits it's circumstances from business needs but nevertheless, it just boils down to different targets that the IT staff will try to achieve. That is their outcome. To handle the interaction and achieve the outcome based on specific targets. The needs/targets vary from interaction to interaction but they are still there. What would happen if we treated the support organization as the customer and started to define the services that they are consuming with IT service management. Lets empower the support organization to reach their goals (what ever they might be) and measure our ability to enable/empower that, just as if it would be the business. What would happen if we did and succeed? 

One thing is for sure. Any business that would rely on that support organization would probably experience it big time. And now we have not even talked to the business about IT services or involved them in anything that they might not even be focused on or not understand. I know that this would not enable IT to drive and evolve the business which pretty much is the end game but anyway. What it would do, is that if IT could succeed internally, we would learn the IT organization the practice of IT service Management, establish new behavior and culture, and be good at it before we try to practice it on somebody else. We would experience all the good and the bad and learn from our misstakes, first hand.

I am thinking if we can not do it small, why on earth do we think we could do it big. When we nail the small we could proudly and confidently embark on the big. Just a tought :)

Why an SLA does NOT give you IT Service Management

IT Service Management .... what does it stand for? If we take a quick look at Wikipedia it says that it "refers to the implementation and management of quality IT services that meet the needs of the business". What does that actually mean? That IT should implement something AND manage it in a way that meet the needs of a business. So what are the business needs then? Well, how long is a rope?

That a business has goals i guess is a no brainer. But what are the business needs? What is IT's contribution in this? if we take a closer look at business goals, where do we end up concerning IT? If the business is using IT to try to achieve their goals, IT should measure the business ability to do so. Is it not the only thing that matters? If business is achieving their goals to a certain level, IT's responsibility should be to provide better ways of doing just that or more. Try to wright that in an SLA. 

If the business has a target and that target is reached, is everything OK? it should right? Even if IT did a terrible job it is still good, or? Is it only OK if the business targets was reached but if they where not it is ITs fault?

IT need to stop acting like we are a grocery store and as long as people buy the groceries everything is OK. If our store customers comes home, tries to cook a dinner and it tastes awful would they blame the grocery store? Of course not. Why? Because we did not promise it would, and why would we? We are in the grocery business, not cooking business, right? But what would happen if we, as a grocery store, suddenly said that if you purchase your groceries from our stores your dinner will taste grate. Do you think we would get any complaints? I think we would drown in complaints. So lets apply some SLA to this grocery scenario. In the SLA we wright about store availability (open hours to do purchases) and bags for carrying, variety of available recipes with instructions, warranty of certain groceries etc. Would the dinners taste any better? I guess not. Even if we actually deliver every part included in our service the food would probably not taste better that the chefs ability to cook. The goal here is to have good tasting food but what are the needs? One customer is a decent chef but cant read so every time he cooks he mixes in the wrong ingredients and the result is a dinner that tastes bad. Another customer gets everything right except the heat on the stove so everything gets burnt and tastes awful. Same goal but totally different needs.

So how do we solve this? With an SLA? An SLA that is IT centric (availability, response times etc.) will never ever be in the interest or main focus of a business. So how about an SLA that is business centric? Well now we are getting somewhere, or? Lets do as in our grocery store and promise good tasting food. That should do it, right. I guess not. The question is how do we measure the chefs ability to cook. If we can quantify that in any format or way we are getting someware. That would help us to see if IT's improvments actually improves what really is in the business focus and interest, their ability to cook. Service management is about caring, behavior and culture, not about availability and response times.

One thing that we can decide on, and count on to happen is that the goals and needs of a business will always change. As soon as we have helped somebody with one thing another thing will appear as a new week point that needs to be managed/handled/improved. Today almost everything, in one way or the other, involves IT. Does that mean that we will have to deal with everything eventually? I do not know but i know one thing, an SLA will not give you IT Service Management so if you are pursuing that, start by going to your business and ask them if there is something that they think you could do to make their life easier when trying to acomplish their goals and then really try hard to do it. Then you are actually doing Service Management even without and SLA.

Design a process, communicate and implement value

As a process designer we need to think ahead. We need to think ahead and see the future value as clear as possible to be able to do a good process design. The better we can see the future, the better our process will probably become. It is a matter of time traveling and make the necessary changes in real life and it is right here i see something that we could improve tremendously.

What do i mean with that? A basic way of designing a process could be to develop a ASIS process design that clearly shows how the process is implemented. A TOBE process design to identify the gap that has to be covered. A implementation plan that removes the gap and takes us from ASIS to TOBE in an effective manner. Sounds easy don't it? Usually there is no trouble in developing the ASIS or the TOBE process. The implementation plan should be no big deal either. So why is there a general understanding in the business that implementing process is hard? I frequently hear and read that communicating during implementation of the process is what is the hardest thing with processes implementations. As soon as you show a process to a stakeholder or an process operator for verification during design you either get rolling eyes and a general lack of interest or the opposite, an theoretical acceptance but not the corresponding action in reality when implementing. How come we during the process design so often get acceptance from both performers and stakeholders but in reality we struggle so hard with the implementation and realization of it? 

Many years ago when i was a process youngster i had such firm belief that i could, and would, change the word by designing better processes. That was it. It was a revelation for me and i could see the "code" in front of me, just like in the movie The Matrix when you see the rain of letters and numbers falling down on their computer screens, i could read it. I did a lot of good during those years but boy what a fight it was. The effort of establishing a TOBE and get it reviewed, accepted and even communicated was a walk in the park compared with actually establish the changes and implementing the new way of working. The constant discussion of metrics, tools, activities, input, output, people depend on you, this is required not optional etc. Anybody could have been discouraged by this but i had seen the light so I just kept trying even harder. The more i talked about the process the more alienated i got. I was a process fool with a tool! That was a long time ago and a lot of water has passed under the bridge since then and my conclusion are that the more we talk and communicate about the processes itself, the further from reality we are perceived. 

What we need to come to terms with is that the process is just a visual representation of a series of activities that can be sequential, parallel, conditional, mandatory etc. and is usually a combination of them all. The way we design and visualize a process has absolutely nothing to do with a operator actually performing a part of the process. It has nothing to do with why something has to be performed in a certain order or not. What we, as process designers, are experts in is to see and understand the purpose of a process and how to, by a series of activities and flows, achieve that purpose. We use our technique to represent the information required in the process and all conditions that needs to be fulfilled. We can even measure the process to see progress and outcome and propose adjustments based on that. But as i said earlier it is not a question of designing the TOBE or ASIS or even the implementation plan that is the challenge. It is in communicating and establishing the process to achieve the purpose and value designated with it. 

So the dilemma here seems to be, how do we design and implement a process without talking, showing or ever mentioning the process itself to the outside world? We need to communicate based on outcome and use a language that establish trust and ambition. The process itself absolutely needs to be designed and constructed but we maybe need to look at it as if it was confidential. Yes, it is a big secret of the trade and is never to be communicated or shown outside the design room. The only thing that is to be revealed is the purpose of the process and the value that it will bring. This would mean that we will have to change the way we speak and communicate when it comes to processes. There are some ground rules for process design so lets take a look at what should be present in a process and see where we end up. 

- A process have a defined trigger.

- A process have a defined end result.

- A process have a purpose.

- A process brings value.

- Each activity have an initial condition that needs to be met before it should be performed.

- Each activity has an end result condition that needs to be met before considered finished. 

- Each activity have a responsible performer (even if automated).

- Each activity is supported by a tool (even if performed with pen and paper).

- Each activity is dependent on information that is required to be performed.

- Each activity generates information before considered finished.

If we could se the above in a process design we could consider it to accomplish the basics in process design. But if we apply the dilemma on this situation and agree on that never mention or to show the process itself, how do we communicate about it? Well the first question is who are we communicating with? If we are communicating with a stakeholder we certainly should talk about the purpose and value the process brings. Even every activity can be described in value. So what of the ground rule list should be considered when talking to a stakeholder?

Interests of a stakeholder:

- A process have a defined end result.

- A process have a purpose.

- A process brings value.

- Each activity has an end result condition that needs to be met before considered finished. 

- Each activity generates information before considered finished.

Every point in the list above can be described as purpose and value. As you can see everything is result based. It is what we get from the activities and process itself. Each process activity can even be described in value and purpose if needed to go to that level of detail. Still, never to have mentioned or shown the activities or the process design itself.

How would the list look if we would talk to an operator (performer). This time i divide it in two parts. The first part is what i consider operator requirements. Basically what the design suggest should be achieved and available for the operator before performing her work (process activity). The second part is what is expected of the operator and must be achieved by her to consider the activity as performed. 

Requirements by the operator:

- Each activity have an initial condition that needs to be met before it should be performed.

- Each activity is supported by a tool (even if performed with pen and paper).

- Each activity is dependent on information that is required to be performed.

 Required of the operator:

- Each activity has an end result condition that needs to be met before considered finished. 

- Each activity generates information before considered finished.

As you can see it is much easier to isolate the purpose and value in each process activity if we break it down to this level and simply answer the question WHY for each process step and each statement for process design. This way we can communicate with any person about the process or even a small part of the process but disguise it in terms of purpose and value FOR her, or the purpose and value contributed BY her to achieve the overall purpose and goal with the process.

It is more about the words we use than in the format we do it in. If you are used to present and communicating using slides continue with that. Just make sure you never reveal the process design in the material. Always express yourself in beneficiary terms FOR the attendee or requirements OF the attendee. This is applicable for stakeholders, operators, managers, end users etc. The process is just a tool of the trade and a way to describe the information flow, the activities where it is used and modified/created for a specific situation. It can be used for many things and should mainly be used where both the author and receiver base their assumptions/analysis/design on processes.

In other circumstances you are better of hiding it!