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, April 08, 2010

The Art Of Building an ITSM Process Design Team

Sometimes the journey is more important than the destination!

Documenting processes is rarely on the top 10 list of an organization’s fun and interesting things to do with its non-existent free time! However, it is a fundamental necessity once the organizational complexity no longer supports an organic or immature approach to key management processes.  Or perhaps other key drivers that force a company to the drafting table may be risk to the business mission or the legal requirement to comply with audit and legislation. Whatever your drivers may be you will one day find that it is time to formally put pen to paper and map out the who, what, when and why of what you do or perhaps more importantly what you should be doing.

As each organization reaches this point they are inevitably faced with the fact that they have scant resources to accomplish their process design goals. They also often find out that their current processes no longer scale or need to be changed to follow best practices.  This double constraint gives them the idea that surely they are not unique and that there must be other organizations or consultants that could help them short cut the time required to define new processes with pre-defined templates and hard won experience.

While this is true it is important to understand that there is a positive and a disastrous way to bring in external assistance to help with your resource and knowledge gaps.

Using External Consultants:

How and when to use external resources is a very important decision that can either fast track you on the way to having your processes defined or end up with you wasting a great deal of money with little to no real lasting impact or value for your investment.

While it is true that external resources can provide the missing expertise, knowledge and pair of extra hands you so desperately need it is equally true that they are seen as not belonging to the inside family circle and have limited ability to change perception and practice.  The result of which is that they can excel at some tasks but will fail miserably at others if used unwisely.

For example if you are brining in external consultants to document what you do already then it is feasible for them to hold a series of workshops and interviews to piece together the intricate workings of your existing policies, processes and roles and hand over a written account of what you do today. However, if you are changing what you do to follow an external best framework such as ITIL or CMMi then what you are really talking about is a transformation project where you have to convince a very distributed and culturally diverse organization that they need to change their long held behaviours, beliefs and tools. In this second scenario it is self-destructive to assume that you can hire out all the work to an outside firm. What you will end up with at the end of the day is a very nice process binder that no one in the company believes they had any part of designing (even though you involved them in interviews and workshops) and will treat it as a “Not Invented Here” deliverable which will sit beautifully on the shelf and not be followed.

Building Buy In Through Sweat Equity and Emotional Attachment:

At the end of the day a transformation project requires organizational involvement in the heavy lifting of a process design and software configuration project. As indicated in the paragraph above the internal stakeholders will not feel connected to the new process unless they have the perception that they have been involved in it’s design in more than a casual way. However, if you accept this premise the key question and constraint continues to be how do you free up the internal resources to work on this project in some meaningful capacity.  The answer to this question is a blended approach to using both internal and external resources.

Here are a few important assumptions:

  • You need to involve key stakeholders in the design for the organization to believe it will work for them.
  • You also need to use external consultants to bring to the table the key value elements of experience, knowledge, resources and fast track templates.
  • It is important to realize that without a formal project approach to the transformation effort little change will occur. Transformation efforts never succeed as a side of the desk activity.
  • The most likely candidates for your internal design team are already engaged in other activities making dedicated commitment to the project not plausible.
  • You need to balance the involvement of high value internal resources with a need for speed to delivery.
  • The true deliverable of your project is not a completed document or process but your organization operating in a new way with new values. 

This last point is perhaps the most significant of all the assumptions and is the basis of why using only consultants to help define your new processes is not a viable solution. The key realization here is that it is the process of building and gaining agreement (not consensus) that is the true deliverable of a process design project. The actual achievement of a finished product is the icing on the cake and perhaps a minor but relevant detail for actually supporting a transformation project.

Consider that the true goal of a transformation project is to change behavior and eventually culture. To achieve this it is necessary to define a process, write it down and automate it in a software application but these are only enablers to the true outcome of transformation.

At Pink Elephant our experience tells us that there are seven key ingredients for a successful recipe when building transformation teams:

  1. Establish a formal project with the classic project sponsorship, governance and controls necessary to accomplish any major initiative.
  2. Source a reliable external trusted advisor that has a solid track record in supporting process transformation projects. This vendor should provide both strategic and operational support and come with a little red wagon full of time saving tools.
  3. Develop a small part time internal process design team that will work on the process deliverables 2 to 3 days of week schedule permitting. This team should be made up of internal subject matter experts, change agents from key stakeholder groups and be supported by your external advisor and software administrators responsible for process automation.
  4. Define an extended internal stakeholder group of middle and Sr. Management roles that will provide feedback and approval on your process deliverables via email feedback loops or workshops to optimize organizational acceptance.
  5. Start early on defining the ongoing process governance, support and execution roles that will use the process after it has been deployed.
  6. Leverage other organizational support groups such as corporate communications, HR, internal audit, procurement and software development to support your initiative.
  7. Plan your deployment and rollout strategy to occur as rapidly as possible without jeopardizing your existing service delivery. (Its not easy to change your tires as you are driving down the highway)

As individuals and key stakeholders take an active part in the design of your new processes they begin to feel the necessary emotional attachment to their deliverables and want to see the blood, sweat and tears they have shed be effective and successfully deployed. It is amazing how a far a little bit of sweat equity will go in the effort to convince people that change is a good or at least an acceptable thing.

Many organizations have tried to short cut this effort or relied exclusively on external resources believing that this level of involvement and internal investment is not really necessary. Only to find out that to ram the change down the corporate throat with out consultation or involvement may have short-term success but will also just as likely result in the organization’s eventual rejection of the change once the heavy hand of compliance is lifted.

This Article was originally written for publishing on

Troy’s Thoughts What Are Yours?

“That’s the best thing about walking, the journey itself. It doesn’t matter much whether you get where you’re going or not. You’ll get there anyway. Every good hike brings you eventually back home.” (Edward Abbey)


(0) Comments
Posted by Troy DuMoulin on 04/08 at 10:00 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Page 1 of 1 pages