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, October 26, 2010

Integrating Suppliers Into Process Governance

While You Can Hand A Supplier The Keys of Your Process You Need To Keep a Firm Hand On The Ownership Papers

At times I feel this blog is a diary of the current discussions we are having with our clients about the challenges they are facing with their IT Management objectives. This article is the result of several recent discussions all along the same theme.

As we have discussed in several other posts the reality is that all organizations integrate external suppliers into their value chain but few do so well. At the heart of the challenge is the misguided belief that when you outsource a service to an external provider you are also fully handing over the reigns of process ownership and governance to them. While it is true that the suppliers are part of the governance structure they themselves should not hold the role of overall enterprise ownership and accountability for an Enterprise IT Management process or IT Service.

In my view, part of the challenge comes from the actual term we use for using external suppliers. The term “Outsourcing” gives the impression that I am externalizing both the delivery and ownership of the process and service. However, what is in fact happening is that as an IT Service organization you are choosing to integrate external suppliers into your “Internal Value Chain” as part of your service strategy. This is a concept that ITIL addresses in the Service Strategy and Design books and the subject I address in the following article. 

Your IT Outsourcer - A Brother of Another Mother “You may not share the same DNA but you’re an extended family just the same.”

I particularly like the definition of outsourcing eSCM uses in their reference model in that it describes Outsourcing as the act of delegating a specific responsibility.  As a Senior Manager I understand fully that while I may delegate a task I still remain accountable for what I have delegated and stay involved from a steering and improvement perspective.

Here are a few case studies of the recent discussions that have prompted this article:

Case Study 1: A Global Energy Company has outsourced several major service towers to different providers (eg: End User Services, Service Desk, Hosting, Network, Telephony, etc)based on a cost optimization strategy. Challenge: while each supplier is contracted to deliver their respective services based on ITIL best practices each provider has its own processes and presents the required metrics from a different process definition. Result: Even though they have agreed to collaborate, there are no common processes shared across internal and external providers.  This is causing significant customer satisfaction and service delivery issues.

Case Study 2: A North American Office Products distributor decided to outsource their services to a prime supplier leaving only 5 full time IT people in place to manage the supplier contract. The ownership of the processes has been totally outsourced to the prime supplier without any recourse to require improvements without engaging in contract negotiations. Challenge: The current contract is focused on financial objectives and does not include any requirements to follow service management practices other than some high level measures and SLA targets. Result: The 5 remaining IT staff have no mechanism to steer their supplier toward improvements or steering the provider without renegotiating the contract.

Case Study 3: A US Government Agency is looking to outsource multiple service contracts to different Suppliers and asking one of the contractors to be responsible for establishing processes across the other peer level providers with the only contractual clause in place being. “Willing to collaborate” Challenge: Without this provider being designated as Prime with contractual obligations for the other providers to follow a common process this is a disaster in the making. Predicted Future Result: What do you think smile ?


Each of these scenarios is a recipe for a great deal of pain for the practitioner / client organization. The key to success for these case studies is the need to establish a tiered and distributed process governance / ownership approach where overall or enterprise ownership is retained by a role within the practitioner organization which has a direct line to process owners within each functional tower. (Both internal and External)

Enterprise and Distributed Process Governance Structures

The goal of the process governance structure is to create a set of tiered roles that support the deployment and integrity of a common process across multiple groups or functions while maintaining a single point of accountability for Enterprise Process Ownership.

This tiered ownership structure ensures that there is common understanding and carefully structured execution of the following four core areas as related to process compliance and governance:

  • Common Process Flow
  • Global Process Policies
  • General Process Roles
  • Key Performance Indicators (KPIs)

To ensure that processes are practiced consistently across organizational and regional boundaries the following roles are required:

Enterprise ITSM Process Governance Board

The ITSM Governance Board monitors the quality of the IT Service Management processes and is the authorizing body for any changes related to the four core process elements listed above. The ITSM Governance Board holds the process owners accountable for closing gaps or issues identified through the measurement activity and dashboard analysis and will:

  • Establish the effectiveness of process integration, ensuring that they are operating as a cohesive framework
  • Ensure a coherent and comprehensive approach to the design and implementation of processes across the organization to increase efficiency and minimize cost
  • Monitor the performance of policies and Key Performance Indicators (KPIs) to ensure strategic objective fulfillment
  • Develop and manage an enterprise process management dashboard for reporting organizationally specific and global process KPIs
  • Identify and coordinate enterprise continual process improvement initiatives
  • Ensure process flows, core policies, roles and responsibilities, and specific KPI metrics supporting the dashboard are synchronized across the Enterprise ITSM Process
  • Review and approve recommended changes to process flows, core policies, roles and responsibilities, and specific KPI metrics supporting the dashboard with the overall framework, audit, regulations, legislation and tool requirement in view
  • Develop a business case for funding improvement projects

Enterprise Process Owner

One of the critical gaps for most organizations is the lack of clearly defined process ownership roles. According to good practice and our experience there needs to be an Enterprise Process owner identified within the practitioner organization who retains accountability for the process even if it is largely outsourced to an external provider.

This key role is accountable for the overall quality of the process and oversees the management of, and organizational compliance to, the process flows, procedures, data models, policies, and technologies associated with the IT management process.  In the context of a Managed Services Contract the Supplier Process Owner/Manager is accountable to the Enterprise Process Owner. 
The Enterprise Process Owner needs to have the ability to influence and assure quality and compliance to the process across the organizational and departmental silos including those under the managed services contract.

External Supplier Process Owners and Managers

External Sourcing Takes on many forms:

Many organizations will outsource an IT function such as development, or database administration. In other cases they may outsource an IT Service such as the Network or Hosting.  Recently many organizations are looking at Cloud Services as a means to outsource an entire IT Service virtually such as Software As A Service, Infrastructure As a Service and Platform As a Service. etc

In each case you will need to integrate these various partners / suppliers into your overall IT management approach and process framework. In order to do this effectively there needs to be a supplier role which takes accountability for integrating with the client’s process and who is accountable as a contract requirement to follow process activities and Service Level Agreement targets.

External Supplier Process Owner / Manager:

  • Provides input into the process design phase of improvement and deployment project
  • Works with the Enterprise Process Owner to ensure that organizational or regional variances are appropriately captured in the design
  • Assumes a leadership role in the deployment of the process within their functional department or area
  • Reports the defined measures and key performance indicators for their organization to the Enterprise Process Owner
  • Establishes the Continual Service Improvement activities in line with the overall enterprise process objectives and priorities
  • Deals with non-compliance issues within their specific organization

This distributed process ownership will need to be extended across any internal and external major functional structure to ensure that Enterprise processes are effectively deployed and Managed.

Additional Articles On This Subject

ITIL Castles In the Cloud “Launching A Cloud Computing Strategy Means Outsourcing Multiple Slivers of Your IT Service Value Chain”

Supplier Managers and Olympic Hockey “The Supplier Manager Is Like the Coach Of An Olympic Hockey Team”

IT Governance a Compass Without a Map? “Does your IT Governance output provide you with a detailed strategic blueprint and plan for business value generation or is it a compass without a map?”

Process Owners – Architects Of ITIL Project Success

Troy’s Thoughts What Are Yours?

“If management is about running the business, governance is about seeing that it is run properly.” - R Tricker

(0) Comments
Posted by Troy DuMoulin on 10/26 at 05:52 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Tuesday, October 05, 2010

Documenting vs Deploying ITSM Processes

A Tale of Two Very Different Words & Goals

As the lead of our Solutions and consulting practice at Pink I have the opportunity to review and respond to a great number of request for proposals (RFPs) related to adopting IT Service Management processes.  A frequently observed phenomenon is the stated desire of the prospective client to adopt or implement in their words most if not all of the ITIL processes with a 10 to 12 month period. There seems to be some belief that consultants have a magical ability to accomplish the impractical if not the impossible!

The challenge we then face is how to gently explain the difference between designing / documenting a process versus successfully deploying one across an organization’s functional silos and various service providers.

It is my experience that most organizations are not able to adopt and deploy more than two or three processes in parallel at any one time and that the project will typically take 4 to 6 months depending on the scope, scale and specific process we are talking about.

Process Documentation

To baseline this discussion I’ll define the concept of documenting a process as agreeing on, writing down and creating the following deliverables.

Process Documentation including at a minimum the following artifacts:

  • Process Goal
  • Process Inputs and Outputs
  • High Level Process Workflow and Activity Description
  • Global Process Policies
  • Process Roles and Responsibilities including a RACI authority Matrix
  • Process Integration Points
  • Process Critical Success Factors and Key Performance Indicators

Following on from this list of project deliverables more detailed classification structures, priority models and tool-based procedures are developed and documented before and as the automation of the process is developed and deployed.

Documenting your process should not take more than a couple of weeks especially if you start with a rich template set such as we have within PinkATLAS.

We recommend using a process design team made up of both internal and external stakeholders. For more on this subject please read the following article.

The Art of Building A Process Design Team - Sometimes the journey is more important than the destination!

Process Deployment

If you are actually expecting to deploy and have your organization use the process the set of activities and therefore the resources required increases greatly! Now you are concerned with automating your process workflows and reports in a service management tool set. You need to consider the education and training needs of the people who are expected to follow the new process.

To ensure that you manage the real challenge of actually getting people to follow your process once it is deployed you will need to carefully manage your education, communication and people change processes throughout the life of the program.

For more on this subject see:

Help! No One Is Following Our Processes!

The Three Perceptions of Implementation

The following graphic represents a typical roadmap we would help an organization define as part of the planning stages of their program and does a good job at showing the major component pieces of a process deployment strategy.

Initially we highly recommend starting with a baseline assessment for a number of reasons other than planning which are critical to your success.

More: Why Bother With ITSM Process Assessments?

Following the assessment we establish the overall program roadmap, internal process ownership, stakeholder roles and then begin engaging in the process documentation activities which are mostly completed in the initial 4 – 6 weeks of the project timeline. Following this step you will notice the yellow line under the green line represents the tool configuration, integration and workflow automation tasks.  From Month 3 in this example the project takes on a tool focus with additional design being given to the tool specific procedures, approval flows or classification structures we mention earlier.

It has been my consistent experience that the majority of process project timeline tasks (example: Months 3-5) are focused on tool-based activities as the critical path. Finally once the screens have stopped moving around you can develop your deployment training workshops on your specific “ABC Org” process which are typically held in a lab or classroom type setting and usually last 2-3 hours with 1/3rd process training and 2/3rds tool based / use case based exercises for the organization under the scope of the new process. This deployment training is not to be confused with the ITSM education examples on this graphic which are more about gaining organizational buy in and agreement on concepts, context and terms as part of your people change process.

Now consider that the average process deployment project will have the following people requirements:

  • Process design team will include 3-5 people working part time on the design and documentation (not all of them consultants)
  • Tool administration roles (internal and software vendor) working on implementation, integration and configuration tasks (2-4 people) 
  • Process Training development and then rollout (3-5 people) in addition to your workshop attendees

So on average I would say the average organization will have 6 to 8 people working on some aspect of the process project timeline while they also try to keep their real jobs going. Now stack 2 or 3 processes on top of each other in parallel design and deployment tasks and the number of resources becomes challenging to say the least!

You might ask what about consultants? Please read the article above about the process design teams to consider the best way to leverage external resources and how not to use them.

In summary while it is more than possible to design and document 24-26 ITIL processes in a couple of years you will most likely not be able to deploy more than 6 to 8 in that timeframe even going full out.

As I mentioned above the average organization is able to deploy 2 or 3 processes at the most in parallel.

For more information on setting up an ITSM program and successfully deploying new management processes please refer to the following article:

Establishing Or Assessing An ITSM Program

Troy’s Thoughts What Are Yours?

”To get through the hardest journey we need take only one step at a time, but we must keep on stepping” Chinese Proverb

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

Don't Panic

Page 1 of 1 pages