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


Thursday, December 28, 2006

The Service Organization Part 1


Since the early industrial revolution and the advent of modern manufacturing processes pioneered by men such as Henry Ford for his famous Model T Ford.  Organizational design has focused on breaking apart complex processes into the smallest individual tasks. The result of which manifests itself as silo or stove pipe based organizational charts focused on groups of like activities where the right hand has little knowledge of or concern for what the left hand is doing.

This focus on task segmentation was essential at one point of history due to limitations of knowledge, skills, communication tools and a lack of collaboration technologies. Simply put the only way for large groups of individuals to collaborate in complex processes such as building a car was to give them each only one thing to do and let them focus on doing that one thing to the mental exclusion of all else. Eg: Your job is to put break pedals on the cars as they move past, you will do this as efficiently and as quickly as possible. This is what you are paid to do, nothing else, anything you do outside this task is someone else’s job.

In an IT context this translates to management silos that are created around like technologies and platforms such as servers, databases or applications. You see the culture of task segmentation clearly when the individuals in these entrenched silos such as network administrators or application developers believe fervently that they are doing the Service Desk a favor if they fix something.

The inherent problem with task segmentation is that by the very act of breaking down the complex processes into individual tasks or activities the overall picture is lost to the knowledge and understanding of those who work within in it. For example an IT Service such as Email is never found within a single technology domain but is comprised of applications, servers, databases, etc.. To not understand how it is built and delivered is to loose critical management information.

We have lost sight of the forest by focusing on the trees!

To extend the car analogy just a bit further consider that the average IT shop hires and focuses on highly specialized mechanics versus general mechanics. We have recruited and hired the best wheel mechanics in the market. No one can remove tires faster or more efficiently than our technicians. We have developed entire certification models and career paths on just this one activity. We base their performance evaluations entirely on how well they perform this specific activity and we get what we measure. However, these same star individuals would think nothing of whipping the tire off the car when it’s on the highway versus parked safely in the driveway. In their minds if they see any indication that the tire needs replacing they do it immediately without consideration of the car as a whole let alone the driver.

Oh they know there is a car but it is this conceptual thing that they don’t understand well. They certainly don’t understand the full implication of the wheel (server, switch, application) to the car. They probably are aware of the axel but little else. It would never occur to them to ask the driver whether now was a good time to change the tire since they have never met him or her. In short we have specialized by task segmentation to the point of having lost site of the purpose of the task. What IT needs are general mechanics that understand the entire workings and relationship of the major systems to support the goal of driver transportation. 

“Effective managers have long known that you manage by processes…what’s new is the enabling technology…the less developed information systems that supported command-and-control structures couldn’t do that. In fact, those structures – which can probably be traced back to the church and to the military as far back as Caesar – persisted precisely because for many years they were the only way to manage large complex organizations”.

P. Allaire Chairman and Chief Executive Officer, Director of Xerox

This will be the first of several posts dealing with the subject of IT organizational design in support of service management.

Troy’s thoughts what are yours?


(0) Comments
Posted by Troy DuMoulin on 12/28 at 04:08 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Thursday, December 21, 2006

Selecting IT Service Management Tools for ITIL Processes

The range and sophistication of tools to support IT service management has grown rapidly in recent years in correlation with the growing businesses dependency on IT services. The rapid convergence, of the industry driven by almost monthly acquisitions and mergers have allowed the software vendors to offer new levels of work flow and process integration that was impossible only a short time ago.

As organizations scale and position their products and services to compete in the knowledge based economy, the ability to exploit and automate intangible assets such as knowledge and business processes has become far more decisive then the ability to simply manage static physical assets in stand alone applications and databases.

These knowledge based products such as an organization’s web presence and e-commerce capabilities are completely dependant on IT Services. Effective and efficient delivery of IT services is likewise dependent on the development and implementation of an integrated suite of capable service management tools. These service management tools must be capable of underpinning processes described and presented in the IT Infrastructure Library (ITIL).

While no longer in print the books, “IT Infrastructure Support Tools” and “Service Delivery Tools” are available from the OGC for the guidance of organizations wishing to select service support and delivery tools, or tool vendors wishing to develop software solutions compatible with ITIL process models. These books provide detailed data flow models for each of the 10 core ITIL processes as well as best practice guidance for selecting and configuring an IT service management tool. They can still be purchased as a PDF download at the following link. You will find them included as part of the “Environmental management, strategy and computer operations set”

TSO Back Catalog

One of the main objectives of the ITIL service management framework is the administration of information used to manage the quality and optimization of IT services. As a rule, a tool should support 100% of the required mandatory functional requirements and 80% of desired functional or nice to have tool requirements. The following sample lists of compatibility requirements are taken from the two ITIL books referenced above.

Incident Management
The objective of Incident Management is to provide continuity to the customer by restoring services as quickly as possible in the event of a service disruption or incident.

Sample ITIL tool compatibility criteria:

  • Incident records can be created, changed and deleted
  • Each incident record has a unique ID
  • Time and date will be automatically recorded in the incident record
  • Incident records are separated from problem and change request records
  • Incident records can be classified according to priority and category
  • Incident records contain status information
  • Incident records can be linked to configuration items
  • Incident records can be linked to the caller
  • Incident records can be linked to and routed to support partners
  • Incident records can be associated to problem records
  • Incidents are monitored and tracked against tolerance breach
  • Support for notification and escalation on tolerance breach
  • Provides management information about the process

Problem Management
The objective of Problem Management is to ensure stability of the IT infrastructure and IT services by structurally and permanently removing the errors within the IT environment.

The ITIL Problem Management process consists of four major elements: support of incident control, problem control / error control, and proactive problem management.
Sample ITIL tool compatibility criteria:

  • Problem records can be created changed and deleted
  • Each problem record has a unique ID
  • Time and date will be automatically recorded in the problem record
  • Problem records are separated from incident and change request records
  • Problem records can be classified according to priority and category
  • Problem records contain status information
  • Problem records can be linked to configuration items
  • Problem records can be linked to and routed to support partners
  • The terms ‘problem’ and ‘known error’ are used as intended in the ITIL-library
  • Problem records can realize a change in status to known error
  • Problem records can be linked to change records
  • Problems are monitored and tracked against tolerance breach
  • Support for notification and escalation on tolerance breach
  • Provides management information about the process

Change Management
Ensuring that standardized methods and techniques are used for efficient and prompt handling of all changes in order to prevent change-related incidents.

The ITIL Change Management process provides best practice guidance to control and manage the complete lifecycle of a change request including:

Authorization & Planning

Sample ITIL tool compatibility criteria:

  • Change request records can be created, changed and deleted
  • Each change request record has an unique ID
  • Time and date will be automatically recorded in the change request record
  • Change request records are separated from incident and problem records
  • Change request records can be classified according to priority and category
  • Change request records contain status information
  • Change request records can be linked to configuration items
  • Assessment information can be recorded against the change request
  • Change requests can be authorized or rejected
  • Communication of authorization or rejection is automated
  • Change coordination can be facilitated through the build, test, and implementation phases
  • Change request records can be linked to and routed to support employees
  • Facilitation with change scheduling
  • Change records permit the recording of post implementation assessment and review information
  • Changes are monitored and tracked against tolerance breach
  • Support for notification and escalation on tolerance breach
  • Provides management information about the process

The Pink Elephant PinkVerify product is based on these same books and a more comprehensive list of criteria can be freely downloaded at the following link.

PinkVerify Assessment Criteria

Troy’s thoughts what are yours?

“The big corporations are suddenly taking notice of the web, and their reactions have been slow. Even the computer industry failed to see the importance of the Internet, but that’s not saying much. Let’s face it, the computer industry failed to see that the century would end” —Douglas Adams


(1) Comments
Posted by Troy DuMoulin on 12/21 at 08:00 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Monday, December 18, 2006

Theory of Constraints & Continual Process Improvement

In “The Goal” Eli Goldratt presents the Theory Of Constraints (TOC). TOC introduces primary measurements for the analysis of systems based on productivity and ultimately, profit. The core truth of TOC is that every system or process has at least one constraint or bottleneck, and that the identification of this constraint should be the focus for any improvement activity.

TOC advocates that organizations take a three-dimensional view of three core business concepts, Inventory, Operating Expense and Throughput. Although executives from financial and manufacturing organizations are familiar with these terms, IT managers are less likely to apply these indicators to their world. To relate these financial terms to IT one needs to expand the definitions beyond their traditional concepts. In essence, you need to be able to map all activity related to a system or process in terms of one of these three factors.

Inventory: All of the money, investment, outstanding issues, pending changes, unresolved incidents, excess capacity, etc. an organization has tied up in an un-sellable, un-finished, un-resolved, undeliverable, or pending state.

  • Pre Process Inventory:Stuff that is currently waiting in queue in a raw or input state that is to be handled or transformed by a system or process. I.e.: Calls that are waiting in the ACD system or emails that have not been answered by the Service Desk.
  • Active Inventory: Stuff that is currently within the system or process and is currently being transformed into a desired or sellable output state, i.e.: Change Management records that are currently being assessed, authorized and scheduled.
  • Post Process Inventory: Stuff that has been successfully transformed into a desired output but has not been delivered to a client, sold, confirmed resolved, or generated profit, i.e.: The Service Desk’s feedback calls back to the users to confirm that an incident, which has been resolved, can be permanently closed.

In TOC, the concept of Inventory contradicts the conventional balance sheet definition of Inventory as an “asset” and redefines inventory as a “liability.”

Operating Expense: All of the money, time, energy, thought, resources, overtime, etc. tied up in the process of converting raw data or inventory into the output of the process. Increased inventory in any state requires a proportionate increase of operating expense to carry the increasing levels of inventory. The natural outcome of increased operating expense is the reduction of cash flow for the organization. In respect to processes that deal with intangible inventory such as un-resolved incidents, cash flow can be translated into reduction of time or resource availability.

Throughput: Defined as the speed at which inventory is moved through the end-to-end process, and delivered to the customer in order to realize the goal of profit, resolution, deployment, etc. By increasing the rate of throughput, the inventory is reduced by moving it in, through and out of the process. By realizing the goal of the system or process, the organization realizes the coveted return on investment, which could mean cash in the pocket or more time to work on other things.

Goldratt observes that these three core principles are inseparably linked and that a change in any one of these three dimensions will automatically result in a proportionate change in the others. The perspective taken by TOC is that the biggest gains are realized by increasing throughput. However, to increase throughput the bottlenecks to the process need to be identified and eliminated.

To do this, an organization needs to look at the process as a set of multiple mini processes, which in turn have inputs, activities and outputs. These mini processes will then pass on the post-process inventory to the next step in the process. When the overall process is viewed in this way one can begin to identify where inventory is piling up in a pre-process state due to a lack of adequate capacity in the downstream activity.

Question: What occurs when you remove a bottleneck?
Answer: Another bottleneck appears elsewhere in the process.
Result: The identification of the next area for improvement to Increase throughput, and the cycle of continuous improvement continues.

In conclusion, Goldratt’s Theory of Constraints places a practical tool in the hands of individuals involved in the ongoing management and improvement of business processes.

Troy’s thoughts what are yours?

I’ve come up with a set of rules that describe our reactions to technologies:

  1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
  2. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
  3. Anything invented after you’re thirty-five is against the natural order of things.

~Douglas Adams,  The Salmon of Doubt

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

Don't Panic

Page 1 of 3 pages  1 2 3 >