The Role of Organizational Change in an ITSM Implementation (Part 1)

by Gerry Geddes

 “At the end of the day an IT Service Management (ITSM) implementation is an exercise in organizational change enabled by process and technology. What this means is, work that typically moves up and down organizational “silos” will now be moving across the departments spanning the IT organization. This is how you create end-to-end products and services. In this case “hand-offs” between IT departments will happen in real time and not need to go up the chain for scrutiny. The rules for such hand offs are agreed in advance at a senior level, documented in process guides and then automated by tools.”

I am going to focus on the role of organizational change to your ITSM implementation and how you can successfully leverage this to ensure success. Let’s take a look at this Eight Step Model and how we can use it in an ITSM program.


ITSM/ITIL Success and What We Have Learned

I will discuss the key factors for success and how getting the balance right is critical.

In V3, it became the four P’s: People, Process, Products and Partners. In this case, Technology was renamed “Products” and Partners were added to acknowledge V3’s strong desire to bring supplier management into the fold. I would argue that suppliers must have all three of their people, processes and products in a mature state to contribute effectively.

When you look at the People, Process and Product elements, the success of your project can be determined by the weighting of importance from these variables. Based on my own and industry experience, we have learned that the success of your program will be split along these lines:

  • Products (or technology): 20%
  • Processes: 20%
  • People: 60%

When studying what effective organizations did right by studying lessons learned from both successful and troubled projects, the data and experience provide one consistent message. People are the key.

Let me rephrase that. If you put 60% of your effort and resources into the people, or organizational change component, and you split the rest between enabling processes and tools, you will succeed, period. Let’s look at some of the key learning’s that have come to give me that kind of confidence.


Some Lessons Learned: How Success Can Evade Us

To many senior decision makers, it was very easy to view building ITSM as just another IT deployment, the same as rolling out a new application or technology. History has shown this is not the case, and we rarely see people go this way anymore who have looked at the case studies. A good ITSM solution must and will have a strong tool behind it, but the key here is that the tool is an enabler not a driver. The tool enables effective collaboration of people across the organization by providing integrated process data and automated work flow in real time.

As the industry matured, the focus shifted to process. However, too much of the focus shifted and once again the balance was wrong. This over emphasis on process brought with it several drawbacks. The first was the cost to develop the processes was high due to large cross functional teams spending a lot of time in meetings trying to create the perfect work flow. When ITSM processes span departments to create end to end services, you can end up inadvertently stepping on someone’s turf. If this is the case, the process team meetings can become a negotiation for territory and influence with endless cycles being devoted to relatively simple processes. If the attendees at these meetings do not have the authorization to speak for their leadership, then all the outputs from the meetings need to be relayed up the line where a similar set of negotiations takes place. By the time these are relayed back to the process team, a great deal of time and money has been consumed. It’s far quicker and cheaper to start with “vanilla” process templates and customize them as necessary to meet your requirements.

Some argue that this is a good way to begin building the “culture of collaboration” that is required for ITSM to work. Unfortunately, the bottom line is that there are better ways to build a collaborative culture without spending this kind of money on process documents. o The ITSM industry took a lot of heat for this, and it is still a common trap people fall into. The total concentration on process guides and “binder-ware” is using the same kind of reasoning as with the tool problem. You can’t just cut a check for a tool or set of guides and escape the heavy lifting on the people side required to bring about organizational change. Just as is the case with technology, good process is an enabler not a driver.

This brings me to the case studies where organizations have acknowledged the importance of people, culture, and organizational change, and they still struggle. What’s up with that? The reason is, in addition to requiring the largest volume of resources and effort, the people component is also the hardest to do successfully. Typically, the problems stem from taking a broad brush approach to cultural change and trying to solve it by purchasing the change. For example, sending every IT employee through their ITIL Foundations certification without providing the supporting organizational context will not enable the change in the behaviors between all players. Another error commonly made on the people component is hiring an outside expert to lead the change effort rather than using them to coach you towards your success by co-delivering with you. All organizational change must come from within and be seen to be driven by, and championed by, the leadership of the organization.

All successful ITSM implementations have recognized this and maintained the necessary balance between people, process and products.

So, whenever you hear someone senior in IT say “Oh yes. We tried ITIL and it failed”, you can bet money it was probably due to one of the above scenarios.