ITIL is a powerful tool, but holds pitfalls in store for those who get obsessed with it.
By N. Dean Meyer
What’s beneath all the buzz about ITIL?
Like many hot topics, people have gotten so excited about ITIL (IT Infrastructure Library) that they think it’s the answer to everything. In some circles, enthusiasm is so great that ITIL has taken on the aura of religion!
For example, Frank, the CIO of a thousand-person IT department, saw ITIL as the key to improving his organization. ITIL charts were everywhere. ITIL became the basis for every discussion of procedures, methods, structure and even resource-governance. All change initiatives were rooted in ITIL, and his goal was to implement all ITIL processes.
For Frank, process became an end, not a means. His organization became so bogged down in the process of implementing new processes that it nearly collapsed. Frank soon “retired” with an agreement not to even talk to his former staff for a period of a year.
ITIL is a great source of best practices for some (not all) IT functions, but its scope is limited and there are pitfalls in implementing it that can actually degrade the performance of an organization.
Let’s get a perspective on what ITIL really offers, and what IT leaders should be doing about it.
ITIL is a registered trademark of the British Office of Government Commerce (OGC). It was developed in conjunction with the British Standards Institute (BSI), and is overseen by The IT Service Management Forum (itSMF), a not-for-profit organization.
ITIL defines a broad range of processes that are considered best practices, documented in a series of books. Processes include:
Continuity management (disaster recovery)
Help desk management
ITIL includes both high-level overviews of the recommended processes and detailed definitions of the steps in each process. Plenty of consultants would love to teach your staff the processes, and vendors offer software solutions to help implement these processes.
Pitfalls in Implementing ITIL
While ITIL is a useful tool to improve the performance of IT operational functions, common mistakes in its implementation have undermined not only the effectiveness of ITIL but, in some cases, of entire IT organizations. There are five pitfalls to be avoided in the implementation of ITIL.
Pitfall 1: Structuring around ITIL processes.
ITIL processes each involve a broad cross-section of the professions (specialties) within an IT organization. Conversely, multiple ITIL processes may draw on any given profession. Thus, if you design your organization chart around ITIL processes, a given profession (needed by many processes) will be fragmented throughout your structure.
This fragmentation of professions creates two significant performance problems:
Work will be replicated by multiple groups that are all studying the same skills, developing the same methods, and reinventing work products. Because work (and skills development) are replicated, costs rise. Due to reinvention of products and methods, consistency is lost. Synergies are lost when multiple processes no longer share common people, information, methods and reusable objects.
With any given competency scattered about, specialization is reduced. Instead of one consolidated group of experts comprising professionals who focus on sub-specialties, many different groups have to know the entire profession. By necessity, they become relative generalists. When specialization is reduced, performance naturally suffers.
Generalists cannot keep up with the literature as well as specialists because there is too much to cover, so the pace of innovation slows.
Generalists’ knowledge is wide rather than deep; and for lack of depth, quality suffers. Generalists take longer to complete projects, since they are continually at the beginning of their learning curve; therefore, response times are slowed. Furthermore, no one leader will be responsible for a given line of business (now fragmented).
For example, a given service (such as storage) will be managed by multiple process managers (availability, capacity, etc.). No single entrepreneur has the job of planning, budgeting, managing, delivering and growing that line of business. This results in a loss of accountability, entrepreneurship, and customer focus. Additionally, there’s no single owner of infrastructure. This leads to internal friction when multiple groups, each accountable for attributes of the infrastructure (its reliability, security, performance, etc.), compete to control those assets.
A healthy structure gathers everyone of a given specialty into a single group, and focuses them on running a line of business. Infrastructure is owned by these various entrepreneurships. For example, storage devices should be wholly owned by the storage-services entrepreneurship. This encourages accountability and entrepreneurship. Once structure sorts out the lines of business within IT, ITIL processes can draw on their products and services as work flows across organizational boundaries. In short, ITIL describes processes that need to get done. Structure defines who does what within those processes.
Pitfall 2: Appointing a process manager with the power to dictate how others work.
Some ITIL consultants have recommended appointing someone the “owner” of each process and giving them the authority to dictate the way others work. This violates one of the most fundamental principles of organizational design, the basic principle of empowerment: It separates authority and accountability.
In this misguided model, the process manager has authority, but others are accountable for results. Those with authority but without concomitant accountability lose touch with the real needs of the business, and often become tyrants. There’s no downside to them dictating “pure” processes that may not work in real life. Meanwhile, those with accountability but lacking the authority to control their businesses within the business become victims and scapegoats. Ethically, one cannot hold them accountable for their own results. The result is a lack of checks and balances. No one can really be held accountable for anything, and processes implemented for their own sake may do as much harm as good.
A better answer is to appoint an “Organizational Effectiveness Coordinator” who is your ITIL guru. His or her job is to help everyone improve processes without either taking away others’ authority or assuming others’ accountabilities.
Pitfall 3: Becoming a slave to definitions which may be dated.
The business-within-a-business paradigm drives product definitions that are clear and make business sense. Products (including services) are defined in terms of deliverables, not what providers have to do to make them.
For example, a solution “repair” is a distinct product from a solution “enhancement.” Though both may (or may not) be relatively small projects, the deliverables are quite different. A repair restores the intended functionality. It does not typically require new user documentation, training curricula, etc. Repairs that are necessary on production systems may be preauthorized, that is, not subject to normal project-approval (portfolio management) processes. An enhancement, on the other hand, delivers new (or upgraded) functionality. It requires all the same deliverables as an entirely new solution. And it competes for funding with other projects (including large projects) that are new investments.
ITIL combines these two different products under the banner of “maintenance.” While this confusion is traditional, it doesn’t represent clear thinking or best practices.
An IT organization can harvest ITIL without slipping backward into fuzzy definitions of products and services. The key is to let customers’ requirements and the business-within-a-business paradigm drive what you do, and let ITIL teach how to do it.
The internal economy describes the resource-governance processes that decide which projects/services get done. It includes processes such as budgeting, rate setting, portfolio management, project-approval processes and accounting. Recent research applies market economics to the design of these processes. Clients can control what they buy from internal service providers like IT without decentralization. And providers like IT can manage their businesses, including maintaining their skills and infrastructure, without begging clients’ permission.
ITIL includes bits and pieces of these resource-governance processes, but it does not benefit from the recent development of market-based approaches. The resource-governance processes should be separated from ITIL implementation, and left within the scope of the broader design of an internal economy that adjudicates all resources for all ITIL (and other) processes. Once clients decide what they’ll buy and IT decides what infrastructure investments it will make, ITIL processes describe how to get the work done.
Pitfall 5: Letting ITIL become religion.
Frank became so enamored with ITIL that he thought of it as all his organization needed—his only organizational improvement program. As the old adage says, “If you’ve only got a hammer, everything looks like a nail.”
ITIL is extremely useful in improving the delivery of ongoing services and the development of the infrastructure used to do so. But it doesn’t describe the complete range of IT processes needed to be world class. ITIL is limited in scope. It’s focused on “service management”—managing ongoing services.
Other processes are needed to excel in the design and development of new solutions (such as system-development life-cycle methods), and in the ongoing processes of evolving architectural standards, technology innovation, client relations, strategic opportunity finding, portfolio management, business planning, the development of IT human resources and many other critical IT functions.
ITIL is a good definition of operational functions, but not a comprehensive definition of everything IT organizations need to be good at. ITIL should be applied as a tool when and where appropriate, within the context of a broader organizational strategy.
Dean Meyer helps IT leadership teams design high-performance organizations. Author of six books, numerous monographs, columns and articles, he brings innovative systematic approaches to what others consider the “soft” side of leadership. Contact him at email@example.com or visit his website for information that can help you implement these ideas, or with suggestions for other buzzwords to analyze in future columns.