Is the ITIL Fad Fading?

It seems to be in vogue to tell everyone that “We’re doing ITIL” or “These are our ITIL processes” or “This is our 'ITIL compliant' software.” The problem is that senior management is now so disappointed with the four letter “ITIL” word that they are either putting programs on hold or cancelling them all together.

You may wonder why this is happening given the potential benefits of ITIL. The reason is that these executives aren’t seeing the promised benefits. There are many potential causes for this and we need to reset expectations about how to leverage ITIL.

Understanding Goals

To put it simply, ITIL in isolation doesn’t solve any business problems. ITIL is a collection of five books that should be used for reference in designing organization-specific processes. It is these processes that must be designed and implemented appropriately to help achieve and safeguard objectives relative to an organization’s goals. The concept of goal enablement is an important one to bear in mind―everything done must support the organization’s goals.

If we start at the beginning, an organization is a collection of business units and functional areas assembled to accomplish something. In the case of businesses, as Dr. Goldratt http://en.wikipedia.org/wiki/Eliyahu_M._Goldratt taught us, they are assembled to make money or maximize return on shareholder equity. With that in mind, any functional area must do one of two things: create value or protect value. In this case, “value” is movement towards the goal.

To support the goal, both in terms of productivity and protection, the objectives of each functional area need to clearly relate to doing one or the other. For example, if the goal is to maximize profit, then the objectives of sales, finance and accounting need to reflect how each area will contribute.

IT then designs, transitions, operates and seeks to continually improve services that help those business units achieve their objectives. These IT services must have effective and efficient processes that support those services in order to deliver appropriate levels of availability, capacity, security and continuity.

The point: You must understand what the business needs to achieve and position IT accordingly to help improve productivity and safeguard the goal.

Processes

To accomplish the above, processes must be crafted to the organization’s needs. It is mandatory that the processes be crafted accordingly. One reason that ITIL fails is that people do not understand the need to develop their own processes. ITIL is nothing more than a collection of practices to refer to and pragmatically borrow from. It doesn’t contain a magic silver bullet that solves all of IT’s problems.

The processes that an organization enacts and follows must be relevant to the objectives and goals at hand. While ITIL is an extremely valuable reference and the service management approach it espouses can be very powerful, it still requires that practitioners carefully decide what processes are needed, how the processes should be designed, the order of implementation, and so on.

The point: processes must be tailored to meet the needs of the business. One does not “do” ITIL. They design and execute their own processes that leverage ITIL where appropriate.

Technology

Another reason ITIL isn’t delivering value is the promise by vendors that they will fix everything provided you buy their product and then, of course, pay an ongoing support fee. (In fairness to vendors, they market that way because it works.) Rather than realize that processes must be identified and then technology implemented to support those processes, rather naïve IT groups are buying tools and then hoping they make IT and the business better! Of course, this is like shooting in the dark: sometimes you hit the target but most of the time you miss.

In some cases, the tools are purchased and then a half-hearted attempt is made to follow their workflow. In others, the tool winds up requiring substantial customization to meet the needs of the various IT groups. In yet another scenario, the money spent is wasted because the tool is such a gross mismatch that it is shelved and never used. None of these bode well for IT and the individuals that sponsor the purchase.

The point: Technology must enable processes. If you do not own tools yet, understand requirements first. If you already own tools, still define processes but have vendor participation, or other subject matter expert support, to identify how to accomplish what is needed given the tools.

People

Another cause of ITIL failures is a lack of planning regarding the people that will actually need to use the processes. Not only must they be considered during the design of processes but also during their implementation. Every process change requires organizational change and this means people must be factored in. Designing a process, rolling it out and hoping people follow it is prone to failure.

Roles and responsibilities need to be clearly defined and then supported by clear performance measures and compensation plans. Moreover, people need training about their new roles and technology that supports their efforts. Human error and the deviation from approved processes increases with tedium and complexity.

The point: Human factors must be considered from the very start. Training, compensation, performance measures and so on must be taken into account.

There isn’t any one single culprit limiting ITIL benefits and causing it to appear to be a fad. IT groups need to think through the people, process and technology (PPT) issues associated with what must be done to pursue functional area objectives and organizational goals. ITIL isn’t perfect but if people look at it as a means to compare and learn, with the full understanding that they are responsible for deciding what must be done and how, it will add value.

George Spafford is an experienced consultant, a prolific author and speaker, and has consulted and conducted training on strategy, IT management, information security and overall process improvement globally. He can be reached at gspaff@hotmail.com.