Within the last three years, nearly every vendor and consulting company has dropped competing IT  service management methodologies to jump onto the IT Infrastructure Library or ITIL bandwagon; as  a result, many companies are now requiring ITIL of vendors. It is not surprising then that today virtually  every RFP from government and enterprise requires an ITIL-based response.

ITIL describes the most accepted guidance for enterprise IT operations. It is not a standard or a  specification, but rather ties together many disparate concepts and frameworks to provide a roadmap that offers the opportunity to improve IT service quality, achieve business/IT alignment, increase IT efficiency, and reduce IT costs.

Marketers riding the ITIL bandwagon have a vested interest in promoting this “RFP checklist effect” for obvious reasons. However, while vendors have publicized a few notable companies that have realized amazing benefits from using the ITIL, much less publicized are the stories of those who struggle with trying to understand ITIL, and those who cannot make it work at all.

More and more companies are realizing that “doing ITIL” is not as simple as buying the latest software, hiring an ITIL consultant, running a training class, or reorganizing. Lost within all the marketing hype around the accelerating ITIL bandwagon are the simple facts that ITIL isn’t for everyone, everyone doesn’t need everything in the ITIL, you can’t use what ITIL says verbatim, and you cannot create an organization around ITIL.

Based on my personal experience with hundreds of IT personnel at all levels and company sizes, this article explains what ITIL really provides and offers. I hope that a clear “spin free” understanding of ITIL helps you to make an informed decision on how to proceed and what it takes to win with ITIL.

The Truth About ITIL

Paramount to success with ITIL is realizing that you cannot conform to, comply with, adopt or implement ITIL—because it is not a specification. The ITIL simply provides guidance for establishing processes.

To find out all about ITIL, you can purchase and read the books; it is, after all, the “IT Infrastructure Library.” The statements in Table 1 are taken directly from the ITIL itself.

Consider those statements, then ask yourself:
■ If ITIL doesn’t cast every action in stone, how can one comply with it?
■ If ITIL relies on existing methods and activities, then what is it?
■ How can vendors certify your compliance with something to which you cannot comply? If you cannot comply with ITIL, how can vendors claim their products are ITIL-compliant or ITL-conformant?
■ If there is no universal configuration, how can you purchase “ready-to-use” ITIL?
■ If ITIL does not describe organizational structure and ITIL is different from organization to organization, how does one organize for ITIL?

Rather than give you my opinion, I will simply quote from the ITIL itself: “ITIL provides a proven method for planning common processes, roles and activities with appropriate reference to each other and how the communication lines should exist between them.”

Regardless of what vendors claim, ITIL is guidance, and it does not provide detailed instructions on exactly how to do anything; one simply cannot conform to the ITIL. The reverse is also true, enterprises writing RFPs cannot (and should not) request “ITIL-compliant” products or services, since they do not exist.

In fact, the UK’s Office of Government Commerce, which publishes the ITIL, says, “Organizations claiming to be ‘ITIL compliant’ are quite common.” And this purported compliance “…is not endorsed or approved by OGC. OGC is the owner of ITIL, and does not at this time offer any test or certificate of ITIL compliance, conformance, alignment or compatibility.”

All ITIL provides is advice to those preparing to change how they operate in order to “concentrate on service quality and a more customer-oriented approach.”

ITIL also offers generic process templates. This is why you can’t use what ITIL says verbatim, nor can you create an organization around it. This also explains why you cannot use everything in the ITIL, and why everything in the ITIL does not require full process maturity.

ITIL simply describes the things you should take into account when you are designing processes. It does not claim to be (nor does it offer) stepby-step process flows or “how to” directions.

ITIL Reorganizes Work, Not Staff

While most business leaders understand that organizational structure and the flow of work affect IT’s ability to deliver required performance, they are often puzzled when the changes they make do not deliver the expected results. In this respect, ITIL is no different at a high level from other process methodologies; one of the most common areas of confusion regarding ITIL is how to use it.

Many vendors and consultants offer services in restructuring for ITIL, and many customers seek such guidance. However, ITIL does not promote an organizational structure, or require any particular management structure. Nor does the ITIL mandate any particular workflow design or process.

Quoting again from the ITIL: “For each of the processes described in this book, one or more roles are identified for carrying out the functions and activities required. It should be noted that organizations may allocate more than one role to an individual within the organization (although this book indicates where specific roles should not be merged), or may allocate more than one individual to a role. The purpose of the role is to locate responsibility rather than to create an organizational structure.”

To understand how the structure of an organization influences the success or failure of IT requires a deeper understanding of the difference between processes and performance. ITIL states that it is guidance for planning common processes. Processes describe the work performed by people, although leaders often think that a process describes an organizational structure.

Gartner predicts that through 2006, 45 percent of IT organizational realignments will fail due to confusing process and performance. This confusion can cause resistance within organizations. A study released in February 2006 by Evergreen Systems found that 72 percent of respondents to a survey claimed the biggest barrier to ITIL adoption in their business is organizational resistance—probably due to a failure to understand that ITIL cannot be used verbatim, nor does it describe a new organizational structure.

Traditional IT organizational structure makes little distinction between process (e.g., tasks) and performance (e.g., carrying out the tasks). Traditional IT structure is silo-based, with technical expertise concentrated into self-contained organizational units.

This legacy silo structure groups technologies and their technologists into manageable units. There is nothing wrong with silos per se, and they exist in most organizations. Medicine, education, the military, and virtually every business all use silos to collect specialists into groups.

However, the role of IT has since expanded, and today’s IT services are complex communications and collaboration systems spanning the traditional silo-ed technologies, as well as the technology departments managing them. This expansion and interconnection of IT services makes it hard to staff a process-driven operation.

While some organizational change to support the reality of modern IT is inevitable, the real changes are not in where IT workers sit or to whom they report. The real change is in how they collaborate to accomplish an objective—this is what ITIL really espouses. ITIL absolutely requires that individual silos, including security, subjugate themselves to the idea of service quality, in which a service spans many silos and is viewed as an intrinsic whole.

Realities Of ITIL

To achieve this collaborative vision of service quality, ITIL provides a collection of process templates and suggested activities, tasks, roles and cross-silo responsibilities. ITIL describes workflowsthat span many traditional IT boundaries. The ITIL states: “[The] ITIL Process approach means that processes have to be managed over more than one department within traditional hierarchical company structures.”

In a recent study of organizations that thoroughly examined ITIL before ultimately deciding not to implement, the top reason cited was “Not enough of the organization would participate.” Successful ITIL adoption depends upon cross-silo  process interaction and shared responsibilities. The entire IT organization must work together as a service delivery chain.

This requires a somewhat altruistic working attitude between IT silos. In less mature companies, where managers vie for the top IT spot, this desire to work together is often missing. This is the number-one reason to skip grandiose plans for ITIL usage. Simply put, if you cannot gain cooperation of the many department silos that compose IT (hardware, software, support, mainframe, telecom, engineering, PC, Unix, Windows, etc.) then don’t bother with ITIL.

Another faulty assumption propagated from the ITIL bandwagon, and often reinforced by vendors, is the idea that ITIL will reduce costs. ITIL usage costs money, and in some cases, increases IT costs.

The reason is simple: ITIL forces IT to address business requirements. Sometimes IT is inefficient and wastes money; and ITIL will show this. Other times IT is underfunded and requires more money; and ITIL will show this as well.

The ITIL is not about cost, it is about delivering value to customers, and sometimes this means spending more on IT than is currently spent. In all cases, ITIL requires relinquishing control over scarce resources, adjusting to new priorities, and working as a team to put the users’ experience of service quality first.

Implementing ITIL

ITIL also is about establishing business-aligned IT processes and continuously improving the operational and tactical aspects of those processes to remain focused on service quality as perceived by customers and users.

ITIL is a continuous way of operating IT. Many mistakenly think ITIL is a project you do which, when complete, is over. This is a common fallacy and reason for ITIL failure.

Any process, including and especially those based on the ITIL, requires:
■ Roles (owner, manager, implementer, auditor)
■ Responsibilities (outputs, conformance to requirements, etc.)
■ Authorities (to direct/perform activities, etc.,)
■ Activities (to meet responsibilities, etc.)
■ Procedures (documentation of how to perform actions required, etc.,) for operating, planning, reporting, metrics, audits and maintenance.

If you cannot sustain the resource commitment, then don’t bother. You must:
■ Define roles and responsibilities clearly.
■ Select and empower a process owner with cross-silo management scope.
■ Select and empower a manager responsible for establishment, auditing and day-to-day operational oversight.
■ Define process workflow responsibilities in enough detail for workers to follow
■ Implement process reporting and auditing in order to continually improve the efficiency, effectiveness, economy and equity of the process

Key here is to establish a sound process framework without going overboard. You must not spend too much time trying to create perfect workflow diagrams and all-encompassing procedures. Adapt  elements of your existing workflow, process and procedures while molding new behaviors into existing workers. “Good enough” is actually perfect when it comes to ITIL.

Successful companies commonly use other best practices, standards, and management techniques when implementing ITIL. ITIL books describe Service Support and Service Delivery best practices, but the ITIL is clear that it does not stand alone, and in fact, can only succeed when used with other practices. The three main practices required to support ITIL usage are:
■ Project management and a Continuous Service Improvement Program (CSIP)
■ Appropriate goal setting through a Process Maturity Framework (PMF)
■ Rigorous auditing and reporting through a Quality Management System (QMS)

For each of these practices you have your choice of several options.

Since ITIL is business aligned, understanding what the business needs is key. The CSIP is a formal process of involving stakeholders, establishing goals, and managing the process of change required to move an IT organization. Basically, the CSIP is “doing ITIL.”

Thus, getting ITIL going requires a CSIP that ties back to key business drivers. Common business drivers include compliance with industry regulations like The Gramm-Leach-Bliley Act (GLBA), the Health Insurance Portability and Accountability Act (HIPAA) and others. All such business drivers require reporting and auditing. Since ITIL does not include any form of audit, the CSIP steers IT to common industry audit schemes like Statement on Auditing Standards (SAS) No. 70 for Service Organizations, Sarbanes-Oxley (SOX) Act of 2002 and others.

ITIL calls for a PMF to identify organizational and process maturity and capability—the “where” to implement and the “when” to begin implementing processes based on the ITIL, as well as the definition of the goal or “desired end-state” as defined in the CSIP.

For example, imagine a CSIP goal to improve internal IT controls in support of SOX. Evaluation of process maturity reveals weak change management, suggesting that a logical starting point for ITIL is to control changes and produce an audit trail. Thus, based on measured maturity and in alignment with business, IT might start with ITIL by establishing and improving the processes of Change, Configuration and Release Management.

There are several well-known PMF options, including Capability Maturity Model Integration (CMMI, previously CMM), COBIT Governance Business Maturity Model (GMM) and the ITIL PMF. For ITIL to succeed, you must choose one of these and use it consistently.

Project Management, formal or otherwise, underlies all successful changes within IT (and most other functional areas). It may seem paradoxical, but while ITIL itself is not a project, to get ITIL-based processes running does require a project, and successful adopters treat ITIL implementation as an IT project.

The best practice for Project Management is the Project Management Institute (PMI) Project Management Book of Knowledge (PMBOK). PRojects IN Controlled Environments (PRINCE) is another project management system closely aligned to the ITIL. If you do not have project management expertise at hand, the chances of success with ITIL are considerably reduced.

Once a course of action is agreed, and a project undertaken to implement appropriate processes, ITIL calls for a QMS as the “how” to manage quality improvement. In other words, the output of the new or improved process must be examined regularly to ensure it is accomplishing the desired function with the required degree of conformity. There are numerous QMS options including Deming/PDCA (plan, do, check, act), Six Sigma/DMAIC (define, measure, analyze, improve, control) and others.

The QMS ensures step-by-step analysis and improvement. Continuing the previous example, if a CSIP goal was to control changes and produce an audit trail for SOX, then mathematical evaluations of change success and audit conformance using tools such as PDCA or DMAIC aid in maintaining output quality. For ITIL to succeed, you must choose and use a QMS consistently.

In The End, ITIL Is Change

The benefits of ITIL come from adapting and then following ITIL guidance, with its focus on determining and then doing the right things in the right order, aligned with and for the business. The “determining” may have been done by management, staff, vendors, customers and users upfront in the CSIP portion of the project, but the “doing” depends on the day-to-day line staff within IT. Successful ITIL practitioners attribute their success not just to the commitment of management, but also to the commitment of the line staff that perform ITIL duties day in and day out.

Remember that ITIL describes how to establish process, and process requires people do things in a certain manner, and most people—IT staff are no exception—tend to do things the way they want to, or the way they were taught, so new ways to do the same things are often ignored. In fact, IT staff, despite working in what is arguably the most dynamic, fast-paced and rapidly changing of fields, can be extremely resistant when it comes to change. The ability to gain their active support, commitment and enthusiasm is a key requirement.

The only proven method of gaining staff commitment is to involve them in the entire process, from the initial decision to implement, through the CSIP, process design and into process establishment. IT staff members at all levels are key stakeholders in all phases of ITIL-based implementations. They manage the projects and perform the processes. Staff capability is the definition of maturity, and only through their improving maturity can IT service quality increase.

Most successful ITIL implementers mention that their success came not from software, workflow, consultants or training, but rather from their staff. For ITIL to succeed you will need to use sound interpersonal management and leadership skills to involve and empower staff at all levels.

Conclusion

It is very common for training vendors, software suppliers and consultants to create the impression that ITIL adoption will not succeed without training, software or consultants (or whatever else they sell!). However, this is only true to a small degree—you can do it all yourself, if you know (or learn) what you have to accomplish. In fact, you cannot succeed with ITIL by “outsourcing” many of the things described in this article.

Successful ITIL adopters learn how to do things themselves, and then make these changes the “new normal” in their organizations and themselves. For ITIL to succeed, you and your staff must learn new skills and then use them.

No matter what the pundits, marketers, trainers, consultants and vendors claim, you cannot comply with, conform to, adopt, implement or practice the ITIL directly; it is simply not possible.

You can, however, do all the following:
■ You can decide to conform to the guidance ITIL advocates by agreeing in principle to the underlying ideas expressed by the ITIL—that of customer focused, process-driven operations aligned with business.
■ You can choose to comply with the guidance for those parts of the ITIL that you require.
■ You can adopt and adapt the guidance described in the ITIL to fit your specific situation.
■ You can only implement ITIL after you conform to its principles and comply with its guidance on those principles.

Practicing ITIL means leading a continuous process of review, audit, analysis and modification of the processes you and your team have implemented formally using a QMS such as Deming or Six Sigma. Perhaps this is why so many find ITIL confusing.

However, all one has to do is actually read the ITIL—simply read the words it contains—and one can clearly see that ITIL is suggested guidance, nothing less and nothing more. All ITIL provides is advice to those preparing to change how they operate in order to “concentrate on service quality and a more customer-oriented approach.”