Visar inlägg med etikett ITSM. Visa alla inlägg
Visar inlägg med etikett ITSM. Visa alla inlägg

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.

tisdag 31 mars 2015

The secret with exceptional process design

  1. When is a process perceived as good?
  2. When is a process perceived as bad?
  3. What is process design?

 

These are questions that everybody that works with process should ask oneself. I use these questions frequently just to remind myself of the secret with exceptional process design. So what do I mean with process design? I guess you could include quite a lot in the term "process design". I have heard people say its about drawing activities and their relations and I have heard people say it is about a customer - supplier relationship and I have heard that it is anything in between. I will come back to what I think process design is but lets start with the questions in the right order.

 

  1. When is a process perceived as good?

Can you recall any occasion when a process has been the subject for praises? No? Well any occasion when a process has been the subject for positive attention? No? A big thank you? A tap on the shoulder? A friendly word? A look? Any thing?

 

That something work fine is usually not expressed in gratitude of a process. Gratification is not that uncommon but it seldom correlates to a particular process. Customer experience can be good and when it is, thing just work. Why is that? How come things just work? Is it because they have the sharpest minds? Is it because they have the best process design? Is it because they have the best tools?

 

  1. When is a process perceived as bad?

I guess that you can recall a few occasions where a process has been the subject for blame. I know I can. Why is that? Is it due to a bad process design? Bad tools? Lack of best people?

 

Whenever expectations are not met there will be a sense of dissatisfaction. Whenever expectations are met there will be a sense of satisfaction. Both of these cases will affect the trust and this trust is the basis for the overall experience and satisfaction. How do we create trust? How do we increase trust? How do we even influence trust?

 

  1. What is process design?

There is a fundamental element with any process and that is the expected process output. But it does not stop there. There has to be a profound understanding of what that output is to be used for and what the expected result of that should be. This is commonly referred to as the value. The process has an output and that output is used to create value. This is the guiding star in all process design.

 

So lets go back to trust and experience. How do we influence trust and experience? What are the basics in trust? Trust is earned. It can not be demanded, asked for, taken for granted etc. It is earned. Earned by constantly proving commitment of a common goal over time. What are the basics for experience? Experience has a more short term relevance. We could have a bad experience and still have a solid trust. But over time if the bad experiences are frequent our trust will gradually decrease. The opposite also apply, if good experiences are frequent over time out trust will increase. 

 

The secret with exceptional process design!

It does not require the sharpest minds. It does not require the best tools. It does not require the best of anything. It does however require two things.

  1. The fundamental element of process design.
  2. Relentless effort to improve.

 

The fundamental element of process design.

Remember the guiding star? The expected process output and the understanding of what that output is to be used for to create value. This has to be the primary objective in all process related work.

 

Relentless effort to improve.

Any effort to improve process output and value could be a process related issue. It might not. It could be anything. Nevertheless, our ability to improve is dictated by our ability to identify and apply improvements. It does not matter how we identify the improvements as long as we do. Use anything at hand. Process -measurements, -operators, -stakeholders, -feedback etc. and never forget the primary objective, output to create value.

 

Summary

My conclusion is that nevertheless if there is trust or not. If there is inexhaustible effort to identify and apply value oriented improvements there will be an increase of trust over time and things will just work eventually. And what did we say about things that just work? That it is a sign of good processes. The key to exceptional process design is to never loose sight of you guiding star, value. And never get tired of digging down in the dirt to find gold nuggets in the shape of improvements. The improvements can be related to education, available information, routines and procedures, tools etc. It does not matter. If it increases value, put it on the list. That is the secret of exceptional process design!

fredag 22 november 2013

How I create IT services

How I create IT services.... or is it value, hmmm service .... maybe value. arghhh  

What should I use? Service or Value? I offer services but I have to show the value. In my mind they are so closely related so its down to the semantics and on that level it does not actually matter. Either we can show and quantify our contribution or not. I guess we can call it whatever we want. 

Whether we call it one or the other, it seem hard to do when it comes to IT. Why? I will use an example of service I have encountered outside of IT which I would like to explore in this post. In sweden (where I live) there has been a strong trend last couple of years in the retail market that is starting to show very good success and revenue. I, as a grocery customer, am custom to cope with ever lasting chore of dinner planning for my family. But things are happening in this space that can contribute in a very good way for me as the customer. Before that, just a quick look at my reality. The process for my dinner planning is pretty strait forward (just to call it a process, talk about nerd). It is my own process and I guess it is probably common. I have designed it to achieve one of my weekly goals, put healthy and delicious food on the table every day of the week. I also try to achieve that at a specific time suitable for everyone in the family, and to a reasonable prize. The process looks like this.

-Come up with at least five dinners meals ideas
-Define all the ingredients
-Make inventory to cross out any ingredients that already exists at home
-Go to the store and purchase all ingredients once a week
-Stash all ingredients in appropriate storage
-Prepare dinner on a daily basis ready for a specific time
-If necessary, complement unforeseen groceries on a daily basis

Thats a pretty strait forward process and it serves me well. The performance is still very depending on that I can prepare the food I come up with. The more variation and exploration I bring to the table, the higher the risk is that the meal will not be delicious, which is my primary goal. But now back to the changes that has been happening in the retail space for the last couple of years. They are offering a home delivered, pre-decided, grocery bag including:

-Five dinner meals with high variety 
-Healthy ingredients
-Step-by-step instructions with a complete time estimate
-Fixed prize
-Home delivery once a week

This is the same grocery store that I have been doing my own purchases in. This could turn out to be valuable for me and support me in my process by decreasing my workload and even increase my ability to serve more healthy food, which was not one of my strongest capabilities but still a very big concern. If I were to buy this weekly grocery bag I could se the following.

pros:
-No more trying to come up with meals ideas
-Higher variety of meals
-Step-by-step instructions
-Meals probably ready on estimated time
-More healthier meals
-No more defining ingredients
-No more inventory
-No more going to the store
-Fixed prize or at least very predictable

cons:
-I can not influence what to eat
-Meals that might not be delicious and accepted by family

Unchanged:
-Prepare dinner on a daily basis
-If necessary, complement unforeseen groceries on a daily basis

This brings up the question of Value. What is the outcome in relation to risk and cost. At an initial look the purchase cost seems reasonably comparable. The difference from my own purchases seems neglectable. There are though a higher risk associated with the taste of the food. The variety could be acceptable as long as the taste stays high above average. More healthy food is a win from all angles. The total effort is decreasing and to sum it up, I gain more verity, higher health and less effort but I also gain in risk for my goal which is delicious food.

whether I choose to purchase it or not is not the main issue here. I only use this as an example to try to answer my initial question. What is Service and Value. From a supplier perspective they for sure call it a service because it is precisely that for them. For me as the customer it does not matter what the supplier call it. If I can not break it down to calculate the value for me, I will probably not become their grocery bag customer. If I do not think the outcome is worth the risk and cost associated with it I will probably not become their grocery bag customer. If I do not understand in what ways it is contributing I will probably not become their grocery bag customer. 

This means that for me to understand the value of this service I have some work to do. Here is a weakness. This forces me to do work to understand the value it brings to me. Now dinner planning is a pretty easy example and therefore the calculation is not that hard to make but when it comes to what IT contributes to, the calculation becomes more complicated. This is where IT needs to step up. We can not force the business to make this calculation. They will have to make the decision whether the outcome is worth the risk and cost, their value, yes. But IT needs to be become much better at putting the equation together.

IT is like that grocery bag supplier. We supply all the bits and pieces in one big bag but we forget the customer process and the recipes. We are not clear with what and how the ingredient are used in an understandable way and we are not clear with how this effects the process. If we could apply the recipes metaphor to how the information is consumed by our business they would tend to be much more interested in our IT services or whatever we choose to call it. Our ability to put together the equation for each recipe need to increase and then the conclusion of each meals value and the bag's value could be in reach. Each ingredient separately will never accomplish that.  

We need to start small. Each business department have their process and subprocesses just like mine handling family dinner planning. Pick one that matters for that business or department. That process or subprocess has an expected outcome. IT contributes to that outcome, figure out how! There are ingredients (information) that are put together to meals (outcomes) and there is an effort (process and preparation) that realizes a business goal (deliciousness). Break it down and put it together as the business consumes it. Not the way IT sees it. We see technology and solutions (bread, meat, vegetables, dairy etc.) and that is not how IT is consumed. The business compiles pieces of everything to create a meal. That is what we need to identify and most importantly, understand! As long as we do not understand the business goals we will have no chance to construct recipes (IT services) and eventually be able to calculate meaningful Value. 

So the reason I am using the term IT services instead of Value is because I work within IT so I am a supplier. When it comes to communicating and defining my services for a business, I concentrate on trying to understand the business goals and how my ingredients are put together to achieve that. I create recipes. I also contribute with any variations I might be able see, to increase the business value of my IT service. Im a chef on a mission :)

måndag 16 september 2013

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. 

onsdag 7 augusti 2013

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. 

torsdag 27 juni 2013

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 :)

tisdag 25 juni 2013

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.

fredag 7 juni 2013

ITSM, why the distance between theory and practice

During all the years of practicing ITSM i have always wondered why there is such a gap between the written word in books and online compared to challenges that you actually face while trying to implement and practice service management. You would think that you are in for a frantic roller coster when reading of organizational challenges, CMDB's, services, metrics, attitude, operations, customer-centric, processes and outside-in approaches. When gathering all challenges and hurdles you would need to cope with, on the road to ITSM, its easy to pick one or a few topics that are the least vague from you perspective and start with that. 

A few years down the road you ask yourself why you have not got any further with the initiative than you have. Feels similar? I have met countless companies that gladly have showed their initial approaches and plans, their implementation strategies etc. They range from small pragmatic to full scale projects but they all have something in common. That is that if they had the chance of doing it again they all would do it differently. It does not necessarily mean that they have failed the mission but on the question "what would you have done differently today" they all get that spark in their eyes and off we go. The easy solutions and corner cutting strategies burst out and the quick wins are lined up. I ask my self, why is it like this? Does all experience come to the conclusion that we did it wrong and there is a easy way out but that holy grail is always out of reach?

I do not have the answer on that but let us continue on the same path. Could it be that when initiating and pursuing service management, any organization, and i mean "any", like in all, learn things from them self, and their organization, that they actually did not know earlier? Could it be that even with the best knowledge within the topic of service management their is always a big portion of self awareness that is always overlooked? When looking back on all the companies i have meet i can see professionals with great knowledge and there is a well spread mix of internal as well as external resources or both in the initiatives with management commitment. If self awareness is an important part of the success of service management then i guess that goes hand in hand with unique challenges as well. After all it is attitude and people it is all about. We try to define it with processes and support it with tools and follow-up with metrics but what is the point if the attitude and people are not onboard. 

So how do we practice and perform changing attitude of people? could it be that simple that instead of embarking on a big service management program we need to practice what we learn to actually learn? What would happen if we did a lot of service management practice but in a very limited space? I mean if we could define one or a very few services in a limited space and go all-in on those. Limit the number of people involved and make it all happen within that limitation. I do not mean go short cuts or corner cutting but all the way with everything. A few people feeling all the benefits of service management. It seems that if we actually had a service which really meant something to the customer and really enabled the provider to do the "right" things instead of "good" things I reckon it would sell itself? if everybody could see, smell and touch all the benefits with working this way it would adopt itself, would it not? The service management initiative could support people change their attitude and ways of working instead of fighting or trying to convince them. 

I like the idea of inspiring people's curiosity and their inner confidence of "the right way". It is very hard to discharge a working solution that can be demonstrated hands-on. On the opposite hand it is very easy to discharge something which cannot be proven more than in theory. Could that be a way we successfully can change attitude? Well you be the judge.