Building ITSM Buy-In is an Inside Job

Documenting processes is rarely on the Top 10 of an organization’s "fun and interesting things to do" list, however it is a fundamental necessity once the organizational complexity no longer supports an organic or immature approach to key management processes. Other key drivers that may force a company to the drafting table are risk to the business mission or the legal requirement to comply with audit and legislation.

Whether your organization is motivated by these or other reasons, the time will formally come to put pen to paper and map out the who, what, when and why of what you do -- or perhaps even what you should be doing. As each organization reaches this point, it is inevitably faced with not having enough resources to accomplish its process design goals.

External Consultants

How and when to use external resources is an important decision that can either fast track you to defining your processes 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’s equally true that they’re seen as outsiders with limited ability to change perception and practice. The end result? The consultants excel at some tasks but fail at others if used unwisely.

For example if you’re bringing in external consultants to document what you already do, then it’s feasible for them to hold a series of workshops and interviews to piece together the intricate workings of your existing policies, processes and roles, then hand over a written account. However, if you’re changing what you do to follow an external best framework such as ITIL or capability maturity model integration (CMMi), then what you’re really talking about is a transformation project where you have to convince a distributed and culturally diverse organization that it needs to change long held behaviors, beliefs and tools.

In this second scenario it’s self-destructive to assume that you can hire out all the work to an outside firm. What you’ll end up with is a nice process manual, no one in the company believes they’ve any part of designing (even if you involved them in interviews and workshops) and will treat it as a not invented here deliverable which won’t be followed.

Building Buy In

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 I say, the internal stakeholders will not feel connected to the new process unless they have the perception they were involved in its design. If you accept this premise, the key question and constraint continues to be how you free up the internal resources to work on this project in some meaningful capacity.

Here are a few important assumptions:

• You need to involve key stakeholders in the project’s design for the organization to believe it’ll work for them.
• You may need to use external consultants to bring to the table the key value elements of experience, knowledge, resources and fast track templates.
• It’s 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 probably already engaged in other activities making dedicated commitment challenging.
• 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 the 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 is that it’s the process of building and gaining agreement ― not consensus ― that’s 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’s 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.

In my experience, there are six key ingredients for a successful recipe when building transformation teams:

1. Establish a formal project with project sponsorship, governance and controls necessary to accomplish any major initiative.

2. Develop a small part time internal process design team that will work on the process deliverables two to three days of week, schedule permitting. This team should consist of internal subject matter experts, change agents from key stakeholder groups and receive support from your external adviser and software administrators responsible for process automation.

3. Define an extended internal stakeholder group of middle and senior management roles that provides feedback and approval on your process deliverables via email feedback loops or workshops to optimize organizational acceptance.

4. Early on, define the ongoing process governance, support and execution roles that will use the process after it’s deployed.

5. Leverage other organizational support groups such as corporate communications, human resources, internal audit, procurement and software development to support your initiative.

6. 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’re driving down the highway)

As individuals and key stakeholders take an active part in the design of your new processes they’ll begin to feel the necessary emotional attachment to their deliverables and want to see the blood, sweat and tears they’ve shed be effective and successfully deployed. It’s 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 cut short this effort or relied exclusively on external resources believing that this level of involvement and internal investment is not really necessary. Later, they find out that ramming change down the corporate throat without consultation or involvement may have short-term success but has resulted in eventual rejection of the change once the hand of compliance is lifted.

Troy DuMoulin is one of the world’s foremost ITIL and ITSM experts and AVP of Product Strategy for Pink Elephant. Troy holds the ITIL Service Manager and Expert certifications and has over 12 years of experience leading enterprise wide IT service management programs. He is a frequent speaker at industry events and is a contributing author to multiple ITIL and ITSM books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement. Troy has also worked with the Information Systems Audit and Control Association (ISACA) on COBIT® 4.0 development and alignment with ITIL.