Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the ITIL Galaxy and Beyond
Don't Panic

Home

Author

Troy Dumoulin Photo

Troy DuMoulin, VP, Research, Innovation & Product Development

Troy is a leading ITIL® and IT governance authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Service Manager and Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.

 

The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronym’s like ITIL, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."


Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams

Syndicate

Troy On Twitter

Recent Entries

Categories

Links

Other Blogs

Archive

The ITSM Grieving Process

Change Is A Process With A Beginning A Middle And End and A New Beginning!

The longer I work in the field of IT Service Management the more I understand that the single most important contributor towards the success of an ITIL project is the act of facilitating and managing the necessary changes of belief, values and actions that are required to adopt ITSM principles. This is the 2nd in a series of 3 articles that focuses on the primary goal of transformation versus focusing on such things as documenting ITIL processes and configuring tools. (Both necessary enablers but not the goal itself).

For more on this concept please read: Establishing Or Assessing an ITSM Program

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.

 

Applying The Grieving Process To Change

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.

 

Transformations Require Flexible and Evolving Leadership Styles

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

 

Posted by Troy DuMoulin on 09/27 at 08:55 PM
  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? smile

    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 smile

    “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
  6. Page 1 of 1 pages

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Please answer the question asked below:

Is the earth round or flat?