Building ITSM Buy-In is an Inside JobYou can't rely on outside vendors to do it for you, writes ITSMWatch guest columnist Troy Du Moulin of Pink Elephant.
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.
While it is true that external resources can provide the missing expertise, knowledge and pair of extra hands you so desperately need, its equally true that theyre 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 youre bringing in external consultants to document what you already do, then its 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 youre changing what you do to follow an external best framework such as ITIL or capability maturity model integration (CMMi), then what youre 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 its self-destructive to assume that you can hire out all the work to an outside firm. What youll end up with is a nice process manual, no one in the company believes theyve any part of designing (even if you involved them in interviews and workshops) and will treat it as a not invented here deliverable which wont 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 projects design for the organization to believe itll 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.
- Its 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 its the process of building and gaining agreement ― not consensus ― thats 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, its 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 its 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 youre driving down the highway)
As individuals and key stakeholders take an active part in the design of your new processes theyll begin to feel the necessary emotional attachment to their deliverables and want to see the blood, sweat and tears theyve shed be effective and successfully deployed. Its 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 worlds 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 ITILs 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.