Troy's Blog

While the concept of Service versus Technology Management is the compass providing direction and the ITIL process framework is the map providing the journey context and detail we still need to motivate, fuel and move the people to begin and continue on the journey. You can invest in ITIL geography lessons (ITIL certification classes) and that helps to abate the anxiety of the unknown shores and shoals. You can even invest in printed process maps and transportation in the form of ITSM tools to get you to your destination faster and more efficiently.

However you still need to get people to buy the ticket, board the mode of transportation and begin the journey that will likely take them the rest of their IT careers since Service Management is more about a way of life versus a fixed destination. So ultimately the challenge is to get your people off the comfortable couch of now, move out their door of the present and start towards a new normal. All of this new activity represents a departure from the status quo and often results in a grieving process for what has been left behind even when their current situation was not all positive your people are used to it and they like or at least are comfortable with what they are used to!!

Looking at change as a grieving process is not a new concept but one I would like to revisit with the readers of this blog.

The following model comes from the research of Elizabeth Kubler-Ross and was originally developed to help understand the stages of grief people transition through as they cope with the loss of a family member or loved one. The interesting thing is that this same model can be applied directly to understanding the emotional state of the people you are guiding through the transformational change and who experience very real emotions of anger, loss, depression through to the eventual acceptance and integration of the change. 

Understanding The Grieving Process and Its Application To ITSM Transformation Projects:

Denial: When you first start your ITSM awareness activities many people don’t believe you are really serious and that what you are telling them about will “actually” ever happen. They have seen these quality programs come and go many times and very rarely have they actually amounted to much. They look at your ITIL project as just another set of acronyms that will come and go in time without changing their lives in any significant way. So the people you invite to your town hall meetings, lunch and learns, process design workshops nod and smile enjoy your pizza and eat your coffee and donuts without any real sign of outward aggravation assuming that your effort will drown under the organizational complexities and crash into the political boundaries.

Anger: However this good will soon vanishes for many people when they realize that you are actually serious about the changes you are proposing and they see Senior Management commitment start moving beyond just standing up in a meeting to say they endorse this new idea. At this point many people who were initially positive go into self protection mode and show real anger at what they see as changes to their current existence, new levels of accountability and potential loss of power and prestige. It is at this stage of the grieving process you can expect people to demonstrate either very active or passive resistance hoping to kill the project under the weight of lethargy.

Negotiation: Realizing that their direct attacks or indirect attempts to subvert the change are not working the people going through the process now begin to barter and negotiate a middle ground where they are able to maintain some level of the autonomy, influence, and their current ways of doing things.  The cry “but we are different”, “I will do this one thing but I will never go that far!” They reengage with the change program but not because they are now supporters of the change but primarily to preserve some level of their current state believing it is better to be at the bargaining table rather than be left out of the negotiation process.

DIP: The dip represents the person’s or organization’s acceptance of the change as inevitable, inescapable and as something to be stoically endured but hated. Don’t expect them to be happy about the change, they will often now attend you meetings grudgingly providing input and feedback but they largely resent the change as something they have no further power (at the moment) to avoid but are required to support.

Exploring Possibilities: The time spent in the dip of depression will largely depend on how long it takes for the individuals and groups to begin realizing personal benefits from the change. At some point the hope is that the realization of the change will have a positive impact which is recognized by those going through the transformation which in turns begins to slowly turn the attitude from negative resentment into positive possibilities. The earlier these benefits are seen and experienced the better which of course is a strong argument to look for quick wins that can be put into place with speed before the full activities are of the change are completed.

Integration: There comes a point in all transformations when the changes that have been put in place are no longer seen as new, nor are they seen as specifically positive or negative but simply as the way things are done. At this point the transformation will have become integrated into the daily lives, routines of the people and it will be hard to consider going back to a previous state. Consider that all new things that transform society go through this trend. At some point Microwaves and Digital Cameras are just part of the landscape and it becomes difficult and even silly to consider going back to processed film except for specialized applications. The world has simply moved on and is set for the next transformation and the next beginning.

For those of us who have been through ITIL projects this curve is a familiar experience, one that takes time and to some degree re-starts for each new initiative undertaken based on the amount of change required. A key to successfully navigating this cycle of grief and acceptance is understanding it is normal, to be expected and planned for. Also consider that your style of leadership will need to change depending on where people are in the grieving process. Use the wrong messaging or leadership style at the wrong time and you could potentially pour gas on the fire and loose everything up in smoke.  Ken Blanchard’s model of “Situational Leadership” provides wisdom for us all to apply during these times of change.

My next post will describe Blanchard’s model and why and when to use the four styles of leadership (Directive, Supportive, Coaching, Delegation) during a transformation project

Troy’s Thoughts What Are Yours?

“To spare oneself from grief at all cost can be achieved only at the price of total detachment, which excludes the ability to experience happiness.” ~ Erich Fromm

1. Hi Troy,

   I would like to comment - or more accurately, ask about - Service versus Technology Management.  I recently took the Operational Support & Analysis.  The section on functions was very helpful.  Though it is well understood having worked in IT for 15 years, it framed it conveniently.  But now I find I am terribly confused about what a service is.  I reference your “Defining IT Success through the Service Catalog” daily.  It seems that functions can also be services.  Like solutions development.  As a customer, I can order it.  But ultimately, this produces a system.  I can’t log an incident against solutions development but I can log one against the system.  Alternatively, if email is a service, it seems I can log an incident against email - I don’t even need to reference the system (assuming there is only one).  Where is the dividing line between service and technical management?

   Another point I repeatedly hear is that there will likely be very few services in the catalogue.  But there are many systems.  Doesn’t each system enable a business process?  In this case I don’t care about any service… I just need my system to work.  When I ask about what services a customer uses, I invariably hear the system because this is what they use to do business.  It seems systems are on the same tier as services sometimes, because I need the system but I also need the group to develop it or maintain it.

   I have studied this and studied this, taken the courses, lived it day-to-day, and still I am totally confused.  What the heck is a service?

   Sincerely,
   Rachelle Chevalier

   Posted by .(JavaScript must be enabled to view this email address)  on  10/02  at  10:08 AM

2. Hello Rachelle

   Your questions would be easier to answer in a conversation but here are a some responses to your several questions

   “I reference your “Defining IT Success through the Service Catalog” daily.  It seems that functions can also be services.  Like solutions development.  As a customer, I can order it.  But ultimately, this produces a system.”

   Solutions Development is a professional service which can absolutely be ordered or requested and in the end produces a new or modified system. Solutions Development may also be the name of a specific function but that is coincidental. The name describes their service offering. You can have a single function that often will provide many services. For example your Security Management group will support a Information and Risk Management Service with other sub services such as virus management, security audits, etc..

   
   “I can’t log an incident against solutions development but I can log one against the system.”

   The is generally correct, you log incidents against the Technical direct consumable or indirect/supporting services which enable a business outcome. 

   “Alternatively, if email is a service, it seems I can log an incident against email - I don’t even need to reference the system (assuming there is only one).  Where is the dividing line between service and technical management?”

   Please read the post “Its Classified” You need to do both. There needs to be a Technical Classification “CTI” where you will reference the system as well as a business service classification where you will associate the Incident to a business outcome such as messaging.

   “Another point I repeatedly hear is that there will likely be very few services in the catalogue.  But there are many systems.  Doesn’t each system enable a business process?”

   A service structure is a tiered structure where the highest tier will typically have relatively few items. The second tier of services or sub services (Eg: IT Support: Service Desk / Desk Top Support / Remote Support) etc. From an application service perspective It is possible to have a one to one system to service relationship but it is more common to see multiple systems support a service outcome. Eg: 6 IT Systems support the IT Service of Power Generation or Deep Water Drilling.

   You reference the fact that the System is part of the customer vocabulary and this is normal since they login to it and use it every day.  Thats fine and it does need to change but please realize that Exchange is the current means by which you deliver the Email service. Several years ago you used CC Mail, today Exchange and tomorrow you may move to a new system. The key here is that the system is transient but the service remains stable and we need to educate IT and the business customer that the true service or value offered is Email or Credit Card Process not the name of the system.

   There is one other element that you have not mentioned but is worth looking at. What is the difference between a Product and a Service? Perhaps products are part of services. Please read the Post: The Debate over Products of Services.

   Hope this helps Rachelle

   Posted by Troy DuMoulin  on  10/04  at  10:24 PM

3. The key here is that the system is transient but the service remains stable and we need to educate IT and the business customer that the true service or value offered is Email or Credit Card Process not the name of the system.

   Posted by painters and decorators manchester  on  03/10  at  01:49 AM

4. ITIL and ITSM are two four-letter words that grind IT operations to a halt, and cause customers to become more disenchanted with IT personnel than ever.

   Posted by .(JavaScript must be enabled to view this email address)  on  03/30  at  11:23 PM

5. “What is the difference between a Product and a Service? Perhaps products are part of services.”
   I would say that a product is something that you are selling to the customer, something which they feel they can consume, although not always the case. A service on the other hand, the customer doesn’t need to feel that they have purchased something just received a service, they are still empty handed. Products are definitely part of a service.

   Posted by Painters and decorators North West London  on  04/28  at  08:46 AM
Page 1 of 1 pages