Leading an ITSM Implementation from the Middle

Posted by Brian Flora on Aug 3, 2017 9:58:41 AM

In ITIL, ITSM, Service Design

I had a few conversations with a student in an ITIL Foundations class I was teaching recently. He was an IT Operations Manger looking to implement ITIL in his organization. He’d been shopping around for Service Desk software and reviewed the offerings from the usual suspects in that area. However, two significant obstacles stood in his way:

  1. The CIO was not behind the project and was somewhat resistant to change.
  2. In keeping with the above, there was no budget for the initiative.

The student was rightly frustrated with the lack of support from leadership in his organization. He asked my opinion: Can process improvements be achieved without executive buy-in and without spending any money? In the long run, the answer is probably No, but it is possible to begin an initiative on the cheap and build support along the way. In short: lead from the middle.

Here’s one way to go about it:

  1. Start with a quick baseline assessment of the current Service Desk/Incident Management process. Map out the process as it exists today, and compare it to the Incident Management process described in Service Operations.
  2. Pick a few Key Performance Indicators (KPIs) for the Incident Management Process and/or the Service Desk Function that you have the capability to measure (mean time to resolve, customer satisfaction, average call hold time, etc.). Take baseline measurements of these KPIs to establish a basis for later comparison. At the end of the day, you’ll need to show Return On Investment – pick KPI’s that will allow you to show cost savings, improved availability, improved customer satisfaction, etc, so you’ll be equipped to build a solid business case later.
  3. Work on bringing the existing process closer toward the ITIL description, as allowed by current tools, etc. Make the Service Desk the owner of all Incidents all the way to resolution and closure, for example. Establish a standard logging procedure and categorization scheme, if none exists. Develop a basic system for establishing Incident Priority, etc.
  4. As these process adjustments are implemented, continue measuring KPI’s. Ideally, you should be able to document sustainable improvement in a relatively short time.

This approach has a few advantages. First of all, by developing the process first, the requirements for any new Service Desk tool will become more apparent. This way, the tool can SUPPORT the process, instead of trying to use the tool to FORCE the process.  It will likely be easier to demonstrate the need for a new tool if you can show how it will better support the process than the existing tool set. Moreover, measurable results can help to build support from customers and executive management for additional process improvements. Again, there is no substitute for demonstrating ROI.

It’s worth noting that I did not suggest starting with a Service Catalog or the establishment of Service Level Agreements. While that would generally be a good place to start, in reality these things are all but impossible to implement without the support of customers and executive management. We’ll have to notch up a few quick wins first in order to earn some of that support.

At some point there will be a need to create some other “Champions” within the organization as well; these types of organizational change initiatives can’t really be done by a single person. Given a bit more budget and executive support an education and awareness campaign underpinned by a combination of customized onsite training and ITSM simulation events would be ideal.

Also, in this situation I probably wouldn’t mention “ITIL” any more than was absolutely necessary. After all, ITIL is only the set of books; IT Service Management (ITSM) is what we’re really after. Chances are the goals and benefits of ITSM align quite nicely to the CIO’s objectives (improved availability, IT agility, cost awareness, improved customer satisfaction, regulatory compliance, etc); they key is to demonstrate improvements in those areas without necessarily putting the ITIL label on your efforts.