Pink Elephant
The IT Service Management Experts

Troy's Blog

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



Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL® IT Governance and Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL 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


Troy On Twitter

Recent Entries



Other Blogs


Tuesday, November 28, 2006

Change Management and Air Traffic Control

For the last post on Change Management I used an airline analogy since they always seem so appropriate in relationship to this process. Doing so triggered my memory of another meaty metaphor along the same lines.

For this story I have to give full credit to my good friend George Spalding and he will probably accuse me of using his best material but at least I give him full credit.

Before I launch into the tale I would like to provide the context that many organizations struggle with the concept of a business case for creating a single process for Change Management where we see all changes recorded in a single forward schedule of change which is reviewed and approved by a change advisory board.

Traditional objectors to this policy are usually the ERP group who in their opinion have being doing change the right way before the rest of IT could even spell the process. Or perhaps it is the application development group who don’t actually see themselves as part of IT and they have their own special process for promoting changes into the production environment.

The common thread that runs through their arguments of justification is that they have more than enough controls and very mature processes so they don’t need to submit themselves to the bureaucracy of the overall IT change process. Now to be fair the first part of their claim is more than likely true. The SAP group has been doing Change Management according to a best practice for years. However, even the most mature change in isolation may still cause a service outage if it is implemented in ignorance of all the other changes happening in the datacenter that day.

Now for the airline analogy:

Consider that the shared datacenter is like the primary and only runway for a busy airport. Landing changes safely in the production environment is exactly like lining up aircraft for a landing while they are still miles out and ensuring they land safely with no casualties for those people who are in the plane or to those who are living their busy lives on the ground. Many different types of planes of varying sizes need to land at this airport all the time and the runway is called on to meet the needs of a private two person planes (standard changes) all the way up to big commercial Boeing 747s (big projects)

Remember that the goal of Change Management in layman’s terms is to efficiently and effectively handle lots of changes while minimizing the impact to the people that work and live around the airport.

Now that you have this picture firmly fixed in your mind consider that having multiple change processes that do not talk to each other is the same thing as having multiple air traffic control towers on the single runway working blind of each other activities.

Sooner or later we are going to have casualties to deal with.

How would you like to fly into an airport under these management practices.

George’s and my thoughts what are yours?

”The system of life on this planet is so astoundingly complex that it was a long time before man even realized that it was a system at all and that it wasn’t something that was just there.” ~Douglas Adams


(3) Comments
Posted by Troy DuMoulin on 11/28 at 12:02 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Friday, November 24, 2006

Change Management from Havoc to Control - Forward Schedule of Change

The story goes like this:

An airline steward goes forward to the cockpit of a commercial aircraft. Opening the door the steward is alarmed and shocked to find the co-pilot at the controls and only concentrating on one aircraft instrument.

When questioned the pilot explains that he is in training and can only focus on one key operation at a time. Last week he concentrated on altitude and this week he is concerned only with onboard communications.

Sounds improbable, but this is not unlike managing the dozens of IT changes that occur each week as separate and unique actions.

While there is ample proof that most incidents are caused by failed changes, that does not necessarily mean that changes in and of themselves are negative. Or even that the person who is implementing the change is out to cause mayhem and havoc.

The fact is that change is necessary and beneficial. However, many changes which appear sound in isolation cause challenges due to unforeseen conflicts or dependencies. It is for this reason that changes should not be implemented in blind isolation in the same way our pilot above cannot fly his plane by only looking at one instrument at a time.

For this reason ITIL describes a forward schedule of change that provides an integrated view of all proposed changes for a specific period of time. It is critical that these changes from various sources are considered together and not in isolation.

While change nirvana at a CMM level 3 or higher would be great to achieve overnight that is not the way many organizations approach improvements with this process. Consider that it may be necessary to walk before you run. The following paragraphs describe a set of iterative improvements for Change Management from communication to control.

  1. Change Notification: At a very basic level of maturity Change is focused on communication of when and how a set of changes will take place.  The principle of the process at this level is simply to provide a heads up on what is being tossed over the production fence.  Communication is largely done through email, and if there is a formal meeting to discuss the changes, the attendees are required to have a very pressing reason why a change should be delayed.  Most changes at this level of maturity are passed through due to a lack of effective power.  The process is seen mostly as a nuisance, which simply delays getting “real work done.” The process may seem limited at this point but it is better then complete ignorance and is a step in the right direction.

  2. Change Control: The next level of Change Management is often referred to as Change Control.  The basic premise of a process at this level of maturity is that all changes should be scheduled in accordance with each other and placed in what ITIL calls a forward schedule of changes.  At this level of maturity, the process can drive compliance effectively and there is a lead-time policy that indicates how long in advance a change must be submitted, based on identified complexity and business risk.  A formal meeting is typically held to discuss the change schedule with the primary purpose of approving the upcoming schedule as apposed to the changes themselves.  Typical, problem areas with a process at this level of maturity are the handling of urgent or expedited changes.  This level of maturity is required in order to support the processes of Configuration and Release Management.

  3. Change Management: The fully mature change process starts much earlier in the change lifecycle then what has been defined above as Change Control.  At this level of maturity, there is some defined mechanism for approving the conceptual fact that the change should actually occur as well as the coordination and scheduling element of the act of making the change in the production environment. It is important to understand that what an organization actually calls Change Management may have a restricted scope and often does not cover the full extent of the ITIL principle of Change. For example, major initiatives may be conceptually approved through a project management methodology, application enhancements may be approved as part of a software lifecycle process and standard changes may be referred to as a move, add, change process (M.A.C). The key is that we understand that regardless of how or where we conceptually approve these changes these approvals are part of an overall Change Management process. Consider that in actual fact there are always two points of approval in the change life cycle; (1- Conceptual approval – can I do it, 2 – Promotion Approval- can I do it now).  However, while conceptual approval may occur outside what is formally called the Change Management process all changes regardless of source, size or complexity must meet at the forward schedule of change and be approved in coordination with each other.

My thoughts, what are yours?

“When you blame others, you give up your power to change.” ~Douglas Adams

(2) Comments
Posted by Troy DuMoulin on 11/24 at 10:12 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Tuesday, November 21, 2006

Service Owner – The Missing ITSM Role

There has been much written about the role of the process owner being a critical success factor for any effort that attempts to manage cross functional processes across a silo based organized. However, processes are not the only things that need to be managed across the deep management chasms that separate our IT domains.

Consider that most IT Services are also agnostic to organization charts and require the same enterprise accountability and oversight. This role has been largely missed in the ITIL literature to date.

The Service Owner is accountable for a specific service (Infrastructure, Application or Professional Service) within an organization regardless of where the technology components or professional capabilities reside. To ensure that a service is managed with a business focus, the definition of a single point of accountability is absolutely essential to provide the level of attention and focus required for its delivery.

Much like a Process Owner the Service Owner is responsible for continuous improvement and the management of change affecting the services under their care. In both cases these horizontal roles are effective or not according to the level of empowerment (true power) given to the lucky person by the executives of the IT organization. The Service Owner is a primary stakeholder in all of the IT processes which enable or support it. For example:

  • Incident Management: Involved in or perhaps chairs the crisis management team for high-priority incidents impacting the service owned.

  • Problem Management: Plays a major role in establishing the root cause and proposed permanent fix for the service being evaluated.

  • Release Management: Is a key stakeholder in determining whether a new release affecting a service in production is ready.

  • Change Management: Participates in Change Advisory Board decisions, approving changes to the services they own.

  • Configuration Management: Ensures that all groups which maintain the data and relationships for the service architecture they are responsible for having done so with the level of integrity required.

  • Service Level Management: Acts as the single point of contact for a specific service, and ensures that the Service Catalog is accurate in relationship to their service.

  • Availability and Capacity: Reviews technical data from a domain perspective to ensure that the needs of the overall service are being met.

  • IT Service Continuity: Understands and is responsible for ensuring that all elements required to restore their service are known and in place in the event of a crisis.

  • IT Financial Management: Assists in defining and tracking the cost models in relationship to how their service is costed and recovered.

Is this role missing in your organization?

Troy’s Thoughts

“If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family anatidae on our hands.” ~Douglas Adams


(18) Comments
Posted by Troy DuMoulin on 11/21 at 11:11 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Page 1 of 4 pages  1 2 3 >  Last »