NDMA Home Page
Index of topics on this NDMA website
Search this NDMA website on Google
© 2024 N. Dean Meyer and Associates Inc.
Excerpt from www.NDMA.COM, © 2024 N. Dean Meyer and Associates Inc.

Executive Summary: ITIL Implementation

how to avoid the pitfalls in implementing best practices in service management

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.

Definitions

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:

  • Incident management

  • Change management

  • Problem management

  • Service-level management

  • Continuity management (disaster recovery)

  • Configuration management

  • Release management

  • Capacity management

  • Financial management

  • Availability management

  • Security management

  • 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:

1. 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.

2. 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). Thus, no one can be entrepreneurial and manage that line of business, or be held accountable for results.

For example, a given service (such as storage) will be managed by multiple process managers (availability, capacity, etc.).

No one 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.

Like skills are gathered together under one manager. This encourages professional synergies and further specialization.

Infrastructure is owned by these various entrepreneurships. For example, storage devices should be wholly owned by the storage-services entrepreneurship. Servers should be owned by the computer-services line of business. 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.

ITIL's high-level process overviews can be mapped onto the organizational structure by doing a "walk-through." For a specific product or service, a walk-through determines who is the prime contractor, what sub-contractors are needed (other groups needed on the team), and perhaps subs to those sub-contractors. A walk-through clearly defines accountabilities for each step in a high-level ITIL process.

Next, the detailed ITIL processes are used within each group -- within the prime for its work, and within each subcontractor for its share of the walk-through.

In short, ITIL describes processes that need to get done. Structure (eg, walk throughs) defines who does what within those processes.

With this approach, an IT organization gets the best of both worlds. Structure defines well-focused lines of business that maximize synergies, efficiency, and effectiveness. Walk-throughs define clear accountabilities and cross-boundary teamwork. And through ITIL, the organization accomplishes a variety of critical processes, each drawing on these shared resources, and each executed with world-class methods.

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.

In this model, everyone is accountable for their own performance. "Prime contractors" are accountable for the total delivery of products and services to clients, and their internal sub-contractors are accountable for delivery of their products and services to the prime. Yet all benefit from the knowledge in ITIL and the implementation facilitation services "sold" to them by the OE Coordinator.

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.

Pitfall 4: Letting ITIL drive resource-governance processes.

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 adjucates 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, "Give a child a hammer and 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, demand management, business planning, the development of IT human resources, and many other critical IT functions.

ITIL is not the answer to everything. It's a good definition of operational functions, but not a comprehensive definition of everything IT organizations need to be good at.

ITIL should be considered one subset of a broader Organizational Effectiveness (OE) Coordinator function. It should be applied as a tool when and where appropriate, within the context of a broader organizational strategy.

Abstracts

Free library

Books

Speech abstracts

NDMA coaching/consulting services

UP....

NEXT PAGE....