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


Sunday, May 27, 2007

The Service Organization – Part 4


In this post, I am building on a series of earlier articles dealing with the implications of managing IT services within a traditional silo-based organization.

The premise of these articles is based on the observation that when you define IT services and their supporting ITSM processes across the vertically oriented technology domains you are introducing two new virtual management structures and in essence creating a matrix organization.

If you want to start your reading at the beginning of these articles you will find the series at the following links:

Otherwise you can pick up the thread of the argument here where we discuss the evolution of a new form of shared service organization focused on Enterprise IT Governance and Service Delivery.

The Shared Services IT Function

In ITIL V3 the concept of a Value Service Network has been given a lot of attention.  The key premise of this model is that there are three primary types of IT Service Providers that work together in some combination to provide value based service outcomes to the business customer.

The three primary provider types discussed in this Value Network are:

  1. IT service providers, which are embedded within and are funded by a specific business unit in order to focus on the needs of that customer
  2. External IT service providers which provide contracted services to either an internal IT service provider or directly to the business customer
  3. Shared service providers which provide common IT services to several business units at varying levels based on need.

Link: Service Value Network Graphic

A key message of IT Service Management is that Enterprise IT is made up of a combination of each of these three provider types.  One aspect of IT strategy is defining the right mix of all three types and then ensuring that common processes and tools are deployed across the entire Value Service Network in order to ensure each service provider delivers their services collectively in accordance with business requirements and agreements.

An interesting trend that can be observed in many IT organizations today is the evolution of a shared services group that focuses on aspects of Enterprise IT Governance and Service Delivery.  One of the primary drivers behind its gradual creation is the challenge of managing a complex Value Service Network without a central governance function which exists and is empowered to work at a level spanning all of the various IT silos managed by the three provider types.

In many companies today the historical context of task segmentation discussed in Part - 1 of this series of articles has left the governance of IT in a largely distributed model.  The result of this distribution is that groups, that by right should have an enterprise mandate and authority find themselves in an infrastructure or application based-silo with a conflict of interest on one hand and a lack of authority outside of their particular silo on the other.  As IT organizations realize this challenge they begin to extract out of the traditional IT infrastructure and application silos the groups and functions that provide a shared enterprise governance service.

The Evolving Service Delivery Organization

The concept of a shared services organization is not new to IT.  For reasons of efficiency and lower transactional costs IT organizations have been consolidating shared infrastructure, networks, data centers and major business applications for several years. However, a more recent trend is the consolidation of professional service groups into a new shared services organization focused not on technology optimization and cost reduction but on ensuring the delivery of business value from strategic IT service assets.

As organizations become aware that services are agnostic to technology silos they also understand that many of the professional services they provide such as project management, consulting, internal audit, application development, IT service management, engineering and architecture need to be centralized for reasons of both efficiency as well as governance.  The centralization of these groups and their eventual consolidation under a single shared services model is what I am referring to as the “Evolving Service Delivery Organization.”

For example; many organizations have already established a separate corporate Project Management Office (PMO) or have created an IT Security and Risk Management group as separate IT functions that now reside outside the traditional application and infrastructure silos.  Some IT organizations have also moved other groups out of their technology silos, such as IT planning and architecture.

To understand these actions, we need to understand that in each case these groups were separated or extracted from the infrastructure and application verticals for some of the same basic reasons.  Each group has an enterprise mandate but often find they struggle with a conflict of interest by being placed within either an application or an infrastructure group with a vertical or domain focus.  To resolve this issue, organizations have structurally removed them from their traditional positions in the organizational chart and have created their own management groups specifically focused on servicing the enterprise.  An unattractive alternative to this approach would be to create multiple redundant groups in every management silo offering the same services, where in some cases they actually compete with each other for business. For an example of this model I suggest reading the post titled A Risk by Any Other Name is Still a Risk.

The inherent conflict of interest, removal of redundancy and the goal of enterprise Service Delivery that has driven these changes are the same challenges faced by the Service Management roles of Service and Process ownership. 

What can be seen occurring over time is the creation of a third executive management silo that houses the enterprise service delivery and governance functions of IT management.

Typically, you see a natural progression of an organization’s move to this Service Delivery model through a very predictable sequence of stages.

  1. Cost pressures or legislation force consolidation of key services and functions.
  2. Enterprise IT functions such as a PMO, Security, HR and IT Finance are created or consolidated as separate management structures.
  3. Initially, these groups report to either the application or infrastructure executives.
  4. Organizational or authority challenges force consideration that these functions actually belong outside of each of these silos.  The individual groups are transitioned as stand-alone functions.
  5. For a time, these separate functions report directly to the CIO; however, as more and more enterprise functions are defined, a span of control issue is created with too many direct reports to the CIO.
  6. To resolve the span of control issue and the organizational challenges, a new Senior Executive is established and is given the mandate of IT Governance or Service Delivery which includes the oversight of these enterprise functions, including ITSM.
  7. Eventually, the Service Delivery organizations represent the enterprise IT function to the business and facilitate the primary business engagement processes between the customer, the IT service owners and IT engagement roles supplied by SLM. This process is front ended by the IT Service Catalog.

Based on this set of observable evolutionary steps, the following picture presents a model of an example of Service Delivery organizational design.  It is interesting to note that many organizations have begun to follow this path without perhaps realizing why.

Link: Service Delivery Organization Graphic

Without a doubt, the move from a Technology focus to a Value Service Network Orientation has impact on organizational design as companies restructure around the concept of being an end-to-end service delivery organization.

For those readers which would like to have the full whitepaper on this subject I have provided the link for your interest. Service Organization Whitepaper

Please let me know if you find this helpful.

Troy’s Thoughts What Are Yours?

“Anything that happens, happens, anything that in happening causes something else to happen causes something else to happen, and anything that in happening causes itself to happen again, happens again. Although not necessarily in chronological order.” ~Douglas Adams


(2) Comments
Posted by Troy DuMoulin on 05/27 at 09:48 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Tuesday, May 15, 2007

Balancing Process Formality With Innovation

“You need chaos in your soul to give birth to a dancing star” ~ Nietzsche

Following on from the last post on Continual Service Improvement I would like to explore the following questions:

  • How much process formalization is necessary or beneficial?
  • At what point do we cross a line with control and formality and begin to stifle innovation and creative thought?

I am sure you have asked yourself these questions or have been challenged by your co-workers with the statement that all of this focus on process and control will hinder and not improve service delivery.

The answer to these questions lies in finding a balance between the two extremes of rigid control and abject chaos.  Neither extreme is healthy, conducive to sanity not to mention organizational productivity.

Contrary to popular belief, the adoption of Service Management is not about locking down, establishing rigid controls and corralling the IT Cowboys.

Adoption of Service Management is about establishing a consistency and balance of service delivery that is in line with the expectations of providing a utility of service that does not place the business at risk while at the same time exploring new opportunities to leverage information technology. 

The challenge that most IT functions have in achieving this balance is that our culture and often our incentive and measurement models value and reward innovation over and above consistency and reliability.  The old axiom “You get what you measure” is true in this context.

At Pink we have a service for measuring and reporting on process maturity.  As part of this service we conduct a cultural assessment which measures the balance between the organization’s focus on innovation versus respect for rules.  Almost without exception, the cultural climate comes back to indicate that there is an imbalance between the two extremes in favor of a hero culture that rewards shooting from the hip and asking questions later.


In light of this concept of balancing between extremes I would like to introduce you to the concept of Chaos Theory.  In short, Chaos Theory is based on the principle that any complex system needs to find a balancing point between rigidity and chaos to retain its vitality.

Brief Look At Chaos Theory
Chaos Theory was not initially developed for use in a business context; however, its premise can be used to describe the behavioral tendencies of all complex systems regardless of their nature.  I use it in this context to illustrate the tendency of a process to move naturally towards a state of chaos when not monitored and measured for quality and improvement.

“Complex systems seem to strike a balance between the need for order and the imperative to change.  These systems tend to locate themselves at a place we call “the edge of chaos.” We imagine the edge of chaos as a place where there is enough innovation to keep a complex system vibrant, and enough stability to keep it from collapsing into anarchy or chaos.  It is a zone of conflict and upheaval, where the old and the new are constantly at war.  Finding the balance point is a delicate matter.  If a complex system drifts too close to the edge of chaos it risks falling over into incoherence and dissolution, but if the system moves too far away from the edge, it becomes rigid, frozen, and totalitarian.  Both conditions lead to extinction. Too much change is as destructive as too little.  Only at the edge of chaos can complex systems flourish.  By implication, extinction is the inevitable result of one or the other strategy. (Too much change, or too little)”
Ref: Norman Packard “Adaptation Toward the Edge of Chaos” & A.B. Cambel “Applied Chaos Theory: A Paradigm for Complexity”

Finding a balance between innovation and bureaucracy has been a constant challenge for countless organizations.  Those IT functions that fail in this goal are most often perceived negatively by their customers, are outsourced or enjoy some form of protection from external market forces. If an obvious imbalance exists the IT organization will either be perceived as immature and reactive or as overly bureaucratic and inflexible.  Both extremes do not serve the needs of the business and are not the goal of Service Management. 

Achieving a balance is always challenging and even more difficult to sustain.  As was stated above, internal and external forces continue to pull from both sides.

An analogy you can use to illustrate the concept of Chaos Theory is a boat on a river above a waterfall.  The river is a powerful force pulling the boat towards the waterfall and certain disaster, while the rowers in the boat are pulling against the current to keep the boat from crashing on the rocks below.

If the rowers give up the struggle we know that the river will pull the boat over the edge of the waterfall onto the rocks below. However, if the rowers are too successful against the current and are able to row the boat so far upstream that they find themselves in a quiet and calm eddy they begin to loose their competitive edge and find themselves getting complacent and eventually loose their relevance. 

One way to know if your boat is too far up, or too far down stream is to continually and consistently take your bearings through the adoption of an accepted best practice framework such as ITIL, CMMI, PMBOK, COBIT, etc.. and the application of balanced measurement model.

So in summary, adopting Service Management is not about words like formalization, rigidity and control.  Finding the balance between process formalization and innovation is critical for the health and relevance of all service providers.

Troy’s thoughts, what are yours?

He inched his way up the corridor as if he would rather be yarding his way down it. ~Douglas Adams

(2) Comments
Posted by Troy DuMoulin on 05/15 at 01:25 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Friday, May 04, 2007

ITIL V3 – Continual Service Improvement

“True genius resides in the capacity for evaluation of uncertain, hazardous, and conflicting information” ~Winston Churchill

This is the 5th in a series of posts which deal with what information has been shared in public events about ITIL V3 content and coverage.

We have all heard the familiar saying, “you cannot manage what you don’t measure.” Well, I would like to add my perspective to this tried and true saying with a more dire consequence.  In my view, what is not measured is not only unmanageable – it eventually degrades into chaos.

While I an not saying that when we take our eye off measurement and accountability things degrade into the world described by William Golding’s book, “Lord of the Flies” I do believe that when you leave the responsibility of doing the right thing as a best effort commitment in the hands of people who are under stress and are over-worked, this often denigrates to doing the easiest thing. It is a basic human instinct to follow the path of least resistance under stress. And, lets face it – how many of us are not under stress?!

The challenge with this observation is that measurement and verification is often perceived as an extra or a nice-to-have set of steps over and above what we are trying to achieve; however, in reality, measurement is the glue that binds actions together, ensures that the goals are met and is the critical driver for service improvement.

That being said, measurement in and of itself does not accomplish anything. In fact, most of us are guilty of measuring things only for measurement’s sake and do not act on what those measures tell us. I have to disagree in respect with Winston Churchill’s quote that I used above. True genius does not reside solely in the evaluation of information; it requires action on that information for direction, improvement or correction. Otherwise, the activity of measurement remains useless.

We see this clearly in the example of a very common IT management report on technology or service availability. The great majority of IT organizations that produce this valuable report do so for the primary reason of establishing if they have met their Service Level Agreements for the month, and then do nothing more with this information.

However, consider that this report is also a primary source of information for un-availability and should be one of the key inputs into the Problem Management process. Problem Management should be evaluating this information to identify and eliminate systemic problems, thereby achieving higher service availability over time. But sadly, this rarely occurs in most organizations.  They produce the report for information’s sake alone month after month and neglect to act on what it tells us.

The issue raised by this example leads us to a key message of the ITIL V3 Continual Service Improvement (CSI) book.

One of the central themes of this new ITIL book is the presentation and explanation of the Seven Step measurement process. This process first assumes that the organization has established and identified the following elements for the Service, Process or Technology they are attempting to measure:

  • Identify
    • Vision & Strategy
    • Tactical Goals
    • Operational Goals
  • Technology metrics – These metrics are often associated with component and application-based metrics such as performance, availability, etc.
  • Process metrics – These metrics determine the overall health of a process. Four key questions that process measures help answer are around quality, performance, value and compliance.
  • Service metrics – These metrics are the results of the end-to-end service as experiences by the consumer of the service. Component metrics are used to compute the service metrics.

At Pink Elephant’s 11th Annual IT Service Management Conference, Gary Case and George Spalding, the author’s of the CSI book, presented the following Seven Step Process:

  1. Define what you should measure.
  2. Define what you can measure.
  3. Gather the data (Who? How? When?)
  4. Process the data (Frequency? Format?)
  5. Analyze the data (Relations? Trends? According to plan? Targets met? Corrective action taken?)
  6. Present and use the information to suggested action plans, service improvement, etc.
  7. Implement corrective action.

While not an eighth step in the process, the slide Gary and George presented shows step 7 flowing back to the first question in a closed loop asking the question again - “what should you measure?” All of these questions are directed by and fed back into the objectives and goals of the process initially identified.

A key point that the authors make is that most organizations will use a much simpler process.

  1. Define what you can measure.
  2. Gather the data (Who? How? When?)
  3. Process the data (Frequency? Format?)
  4. Present the data.

To me, this process is equivalent to a hamster running on his wheel. The wheel is moving but that poor creature is going nowhere fast despite all of his valiant efforts.

“Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.” ~Douglas Adams,


(0) Comments
Posted by Troy DuMoulin on 05/04 at 01:31 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Page 1 of 1 pages