« Organizing execution; Executing organization | Main | The Architecture of a System »

November 10, 2005

Is ITIL "strategic"?

As the shared literature on ITIL seemingly moves into the billions of pages, organizations wonder simultaneously how to get a grip on it and what the real prospects are of getting more out of it than must be put in.

What's not in debate is ITIL's importance as a scientifically attractive set of practice guides, ones which can launch IT organizations up the stream of a business's progressively increasing ability to derive value through enhanced quality:

- Practices -> Standards -> Resources -> Investments

This way of describing ITIL's impact also shows that there is a significant distance to traverse between practice and strategy.

All strategies hypothesize a relationship between operational choices and the effectiveness of outcomes. In fact, while we tend to think of a strategy in terms of "cause-and-effect", it is more realistic and accurate to think in terms of choices-and-effectiveness.

Naturally this puts emphasis on being able to define the type of effectiveness that is targeted -- after which we make relevant enabling choices. On one level, business seeks to make itself more valuable through its operations. On another level, business seeks to make its operations more valuable through the use of IT. Since its investments in IT are fashioned after that intent, the quality of its IT investments is what the business wants to strategically enhance. ITIL offers abundant guidance to "the business strategy for IT."

ITIL's management points and goals can be summarized in a now-classic itemized fashion. But more importantly, they can be stated and grouped to reflect where key business intentions about enablement through IT are addressed to extract, drive or protect value.

Utilization
-Incidents: Restore normal service operations
-Availability: maximize effectiveness of real-time business function access to the IT infrastructure
-Continuity: control risks to availability

Control
-Problems: Manage infrastructure errors
-Changes: Maximize efficiency and minimize risk of infrastructure changes
-Capacity: cultivate and evolve the infrastructure to cost-effectively meet expected business needs

Environment
-Configuration: control and report the versions of all infrastructure components
-Release: plan and manage deployment of infrastructure components
-Service Levels: manage operational compliance to IT user agreements

Operations
Service Desk: maintain a single point of contact with business consumers of IT services
Financials: manage the economy of targeted service delivery and support
Business Advocacy: bilaterally manage the formal relationship between IT provider organizations and business IT customers

Since all of those management points and goals are desirable, the main adoption issue is to distinguish them by both importance and urgency. That will drive a prioritization of the many initiatives that would support adoption of ITIL guidance in the form of operational procedures.

Identifying importance and urgency in terms of "business needs" is where links between ITIL and strategy can get forged. In general, "important" means that something is a success factor towards the need, and "urgent" means that leveraging it must be pursued in an immediate window of opportunity if its benefit is to be assured.

Satisfying the need invokes activities that IT can or should support. The quality of that enablement is generated and fortified by the IT management practices, and improving the practices draws on ITIL. But the practices must focus on how to organizationally support the established urgency and importance. So, for example, this might translate into pressure for agility, scale, economy, or other qualities -- to be met and maintained by moves reflected in the framework below:

In this framework, IT's alignment with the needs of the business is seen from an ongoing performance perspective instead of just as an individual event. The business looks at alignment by assessing how key objectives representing "successful" IT responsiveness are handled in four significant areas of business requirements. Each area of requirements is a distinctive one that represents limits and expectations on business activity. ITIL offers guidance for improving capability in each of these objectives and areas. The business, however, must determine which objectives and areas are the ones most relevant to the current and imminent need.

Combining an objective with a requirements area is a way to describe the nature of the problem to be solved, and a capability is a key solution approach. While capabilities can combine for greater effect, as is shown in great detail in the ITIL guidebooks, their value should still remain visible in terms of success addressing discrete business problems.

Managers who are thinking in terms of scorecards should consider that any capability should be measured in three ways:
- the level of capability in terms of benchmarked comprehensiveness (as inherited or trained)
- the effect of the "as-is" capability level on the problem to which it is applied (as prescribed or designed)
- the capability's impact over time across the variety of circumstances presented by the operational lifecycles and evolutions of the business (as implemented or contracted)

Appreciating the noted capability status and history, managers should look into what requirements area of the framework most prominently features relevance to the business problem at hand, and gauge the match or mismatch of capabilities within the area. This will establish evidence that certain capabilities are logical starting points for systemically improving IT execution.

Posted by Malcolm Ryder at November 10, 2005 9:00 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/158

Comments

Post a comment