How to Strive for Continual Improvement within IT

Most large companies use ITIL as the process framework for their IT operations. ITIL was in fact created at the end of the 1980’s, so something like 30 years ago. Even version 3 was first released ten years ago with its emphasis on the service life-cycle. And given this long-standing commitment to service, you would imagine things have only got better. So, why is it that business users don’t rate their IT departments very highly? For me, there are four main reasons. First of all, we do stupid things to our users, secondly we then try to get them to do all the work, thirdly, we use vendors who care primarily about themselves, and finally, we struggle to make our philosophy of continual improvements to stick.

It is a trend you see in customer service in general. A utility company will have no qualms about making you wait 20 minutes before speaking to you – plenty of time to wind you up with boneheaded call option menus and incompetent voice recognition systems. It saves them cents, but costs you dollars. Then they are surprised when you churn to another company. Fortunately, they have their best people assigned to persuade you back.

Surely, we don’t do that to our IT users? Well, I’m afraid that even if you don’t, many others do! Almost every IT department uses a call menu at the front end. And then they put their inexperienced team on first to perform the arbitrage - which of course they can’t do because, well, they are inexperienced. Have you calculated how much time your users spend logging calls and waiting for you to answer? I bet it adds up to a lot of money. Still, hopefully you have an executive support function in place to make sure your execs don’t find out how bad it really is.

Secondly, we get our users to self-serve. In principle, I don’t have a problem with this. In fact, I also think executive support is important. (There is nothing more annoying than having your board presentation derailed because one of the execs can’t log into their favourite apps). My point is, we are the experts in IT and we should be helping our users to fix their problems. Clearly if we can explain how they can avoid similar problems in the future with high quality training, then so much the better, but it should be the users who choose to do this. Clearly, if it takes us (IT) five minutes to do what takes them ten, then that is five minutes saved. Every time you force your users to figure out the problem themselves you are wasting time and money. And you are losing the opportunity to interact and find out what the problems really are.

The third point is about our use of vendors. Vendors may be essential to our success, but they can also be the cause of failure. They are incentivised and motivated in very different ways to in-house staff. IT managers have blindly followed the route that lowering costs in IT is the way to go. That is fine if the level of service improves or stays the same, but, in reality, it doesn’t. And that’s our fault, or at least the IT management team’s or whoever set up the SLA. SLAs often encourage vendors to take more and more service quality out until just before failure. This is a totally different mindset to in-house teams who will work with customers to always do their best. My point is, think carefully about the consequences of moving services out to vendors before it is too late and, in particular, how they are incentivised. And that includes cloud services too.

Having encouraged your vendors to maximise their profitability by incrementally lowering the level of service, many IT managers then stop them trying to make it right again. The commonest complaint I hear from the vendors I work with, is that they have loads of ideas for improving your operation if only you’d listen. If you haven’t given them the chance, maybe now is the time?

The final point relates to helping your team to adopt that culture of continual improvement that is at the heart of the ITIL framework. The problem with many initiatives is that the IT team members are so amazingly busy with the day-to-day that there is no time left to make improvements. To solve this, I would point you to the 4DX method as described in their book “The 4 Disciplines of Execution” by McChesney and Covey. The book is principally about how to put strategy into practice. One of the key points, though, which I think is very relevant for IT operations, is the idea of focusing on lead measures instead of lag measures. In other words, giving the IT operations teams targets that are the specific and direct result of their own individual day-by-day activities.