Lieberman Software recently took the chance to talk to acknowledged world expert Kevin Behr, IT Governance Consultant and co-author of Visible Ops, on why implementations based on the Information Technology Infrastructure Library (ITIL) can still end in failure and how to avoid it.

Lieberman Software: Can you outline how you arrived at your methodology?

When Gene Kim, George Spafford and I wrote the book Visible Ops, we had a lot of clients in common. Over the years we had developed a list of people with ‘good Kung Fu.’ These are clients that spoke a completely different language than everybody else. What was happening to them wasn’t predictable. Outages were happening all the time and they didn’t know why – their environments were very uncontrolled. These high performers, that we began to call them, spoke a different language – there were very few grey areas, these people believed control was possible, and they were able to get a lot more work done. We decided to study these people and figure out what made them different. That led us to found The IT Process Institute with Gene Kim to really start asking some basic questions about what it is that these folks do that’s very different. We created the controlled benchmark where we examined the processes that high performers actually use.

We benchmarked and surveyed thousands of organisations. The first discovery we made was that the high performers were very much better than everybody else. We carried out three different waves of this research.

If you read The Machine That Changed The World by Womack, Jones and Roos which was the book that described the beginning of what was the lean manufacturing movement, they describe the evolution of a process that can make cars in half the floor space with half the defects with half the cycle time and half the inventory than before. This turned out to be Toyota and a lot of the Japanese manufacturers.
We took that journey as our touchstone . But what we found in IT was much more profound. The difference between the bottom end and the high performers was not half or double as in car manufacturing, in some cases you had factors of 14x the differences between a low perfoming IT department and a high performer. Some places would manage 6x more applications with the same number of staff, or they’d get a tremendous amount more project work done several orders of magnitude faster.
What stood out for us was that they seemed to use less processes than the low performers and less controls. They just selected the right ones. And so we were able to put together a list of foundational controls and processes – the ITPI benchmark. I laugh when people tell me they are implementing ITIL because I don’t know what they’re implementing. In its pure form it is too generic – it’s  a foundation to build a final structure on – not a final structure.

What ITIL is missing is the ‘cause and effect’ of scientific study – if you make the following action, the following actions will happen. But that cause and effect stage requires a lot of research and oddly enough for this “de-facto approach to service management” there’s been surprisingly little research done to actually demonstrate its effectiveness.

In America, we still have not replicated Toyota’s success and they’re buying up the buildings in Detroit that are left from GM and Ford’s failure. After all this time, we copy what they do but we don’t understand how they do it. And we cannot get the same level of success in the automobile industry.

At Los Angeles airport there is a departure gate that United was losing out to big time to South West. United decided to emulate South West – everything they saw them doing they copied to get those passengers. The result was that they went backwards. They lost more passengers. Because trait-based improvement is so limited and finite – yes there are gains to be had in any effort by making things more explicit, and training people, and bringing people together with how things should look but they’re very limited. Especially when you don’t have the ability to understand why and what you should put in place. Secondly, the continuous improvement piece in ITIL is very misunderstood and in IT in general, most people treat improvement like an event.
So if you understand some of the thinking behind how Toyota improves every process every day just a tiny little bit, you can see where IT learn from that – we’re very black and white – it’s all or nothing, and we have a hard time with incremental improvements. We like big bangs because we like shiny technological solutions to come riding in on a white horse and fire silver bullets. But the lesson Toyota has showed us over the last 60 years of continual profitability through all economical cycles is that incremental improvement is the way to kill your competition.

Now I spend most of my time implementing rapid improvement programs for IT organisations so that they are continuously learning, continuously improving and because they are constantly moving ahead every single day with amazing problem solving skills. We are examining all behaviour to really understanding the thinking behind it. People are so focused on creating standardised processes in the ITIL movement that people don’t understand as soon as they’re put in place the performance starts to entropy unless you’re doing continuous improvement. In ITILI I don’t find the guidance written about how to improve to be lucid otherwise people would be doing continuous improvement in a way that would be sustainable and observation shows that is not the case.

As I look across the IT landscape, it really is amazing to me that we are so functionally aligned in IT. We don’t understand the flow of work, we don’t understand in many cases why we’re there. So a lot of the work I do is coming in and making those system level design issues, saying okay here is what the business is giving us in terms of resources – they’re giving us these staff, they’re giving us these dollars, they’re giving us this infrastructure and equipment – and here’s the product they want out of it. Almost like an industrial engineer we’re building a process at some level inside of all of that system to manufacture the stuff that the business needs.

There is very little work and research into the way we work affecting the outcomes that we get. That’s what I think is tragically wrong with IT right now. We have built systems that appear complicated, there is a large group of people out there that believe you can’t successfully perform route cause analysis on these new systems because they’re so ‘complicated’. The truth of the matter is we actually need to start approaching this whole notion of complexity and managing IT more with a physicists point of view rather than a social scientists point of view.

Social scientists do believe in complexity but physicists don’t, they do believe that there are a few hypothesis that do explain the majority of the world. I see this lack of scientific approach in IT where, ironically, we all used to wear lab coats and be seen as scientists. Now we don’t understand cause and effect at any level, and there are many folk that believe cause and effect is an effective way to understand what’s going on in IT. I think we’ve travelled far in the wrong direction.

Lieberman Software: However, we are here, we are where we are. How do we move on?

We need to look more from the general to the particular. Instead of corporates fixating on their quarterly results what we need to be looking at is how they’re positioned from an infrastructure standpoint – how are they poised to capitalise on the next two to three to four quarters. Those kinds of numbers that are actually front facing leading indicators, versus trailing indicators, are much more important and lead to less knee jerk behaviour.

Box out
The Information Technology Infrastructure Library (ITIL) is a customizable framework of best practices that promote quality computing services in the information technology (IT) sector. ITIL addresses the organisational structure and skill requirements for an IT organisation by presenting a comprehensive set of management procedures with which an organisation can manage its IT operations. These procedures are supplier independent and apply to all aspects of IT infrastructure.

Classic reasons for ITIL Failure

1. Lack of Top Management Commitment
2. Inadequate Requirements Definition
3. Poor ERP Package Selection
4. Inadequate Resources
5. Resistance to Change/Lack of Buy-in
6. Miscalculation of Time and Effort
7. Misfit of Application Software with Business Processes
8. Unrealistic Expectation of Benefits and ROI
9. Inadequate Training and Education
10. Poor Project Design and Management
11. Poor Communications
12. Ill-advised Cost Cutting

websites for further information
•    www.whenitfails.org
•    ITIL wiki
•    ITIL definition site
•    ITIL Community Forum
•    ITIL Service Leadership