« Why Strategists Must Think "IT" Through | Main | Compliance versus Compatibility in ITIL implementations »

January 12, 2006

Why You Can't Comply With ITIL

ITIL provides a framework of practice guidelines that offer a business-like model of managing IT operations.

To use ITIL effectively, comparisons need to be made between the resources and other commitments suggested by those models, versus resources and commitments that, for the given timespan under consideration, are certifiably available to and from the organization that wants to follow ITIL guidelines.

That comparison reveals the options and risks that:
(a.) get translated into decisions about what priorities and tolerances will be attached to actual resources and commitments, and
(b.) are controlled thereafter by management.

The translation, in other words, produces a set of requirements that are logically compatible with ITIL. These requirements can be intensively site-specific as well as idiosyncratic of the particular business.

The next step is to execute management processes such that the organization will comply with its peculiar ITIL-compatible requirements. The result of the compliance to those requirements means that the organization will become to some degree compatible with ITIL , even while potentially differing substantially and significantly from another ITIL-compatible organization.

The actual degree of compatibility is recognized as a level of "ITIL" maturity. But almost irrelevant to ITIL itself is the set of things about the organization that are not yet compatible -- irrelevant except to the extent that those incompatibilites are actually inhibiting or preventing further ITIL-maturation.

Meanwhile, at every point and level of ITIL-maturation, the impact of compliance to the ITIL-compatible requirements offers some amount of practical and measurable impact on the business, and that impact (whatever it is) will be examined in terms of "business value". The level of business value is not guaranteed by ITIL -- rather, ITIL helps to design greater opportunity to generate more value.

The actual business value of the impact will be strictly dependent on the strategic objectives and competitive positions of the business operations -- a set of issues for which the validity and scale lies entirely outside of the models of ITIL guidelines. But the business operations are logical "clients" of ITIL-guided improvements in IT operational competency.

Executives and Managers need to understand the difference between ITIL-Capability, IT's Competency, and IT Capability.

IT's Competency seeks to exploit improvements in IT capability as modeled by ITIL. But IT's Competency is essentially defined in the relationship with the client of IT: "competency" is a consistently appropriate responsiveness to the real-time demand of IT users.

ITIL-guided improvements achieved in IT capability can contribute to that competency through the benefits of good management. Management takes the responsibility for generating value from whatever level of IT capability currently exists, for whatever reason it exists.

But additionally, managers want to see that actual capabilities, if they are being modeled after ITIL, are getting stronger. This is a separate and important problem because of the burden that adopting ITIL places on organizations, when other paths to capability improvement (outsourcing, hiring, etc.) might be feasible from the perspective of the business.

Thus, organizations need to understand what level of "ITIL-capability" is necessary for the business at the different levels and segments of the organization, and not attempt to over-shoot the demonstrable business feasibility.

But management should primarily aim in all occasions to achieve ITIL-compatibility as a way to improve IT's Competency.

In light of all of the above, the notion of ITIL "compliance" is at best an abbreviation that helps to market ITIL's importance along with general commitments to standards. This might be an acceptable and even productive metaphorical take on ITIL. But at worst, if taken literally, the notion of ITIL "compliance" sends the organization and its management off on an expensive and furious path to solving a non-existent problem.

Non-existent? Case in point: organizations that are not really very mature in their ITIL-compatibility may still be entirely capable of generating high business value from IT operations; it just depends on what kind of demand the business is placing on them. This is at least historically verified, although it may not be true of most businesses past or present.

That said, for even successful yet immature organizations, the issue is one of whether their economies of scale and "economies of quality" allow them to be agile enough to keep up with evolving business demand. That is, will their capability offer enough to be competent? Here, the key point is this: synchronizing actual responsiveness with actual and foreseeable demand is "good enough", while pursuit of a hypothetical perfect match to some other model is arguably irresponsible unless it somehow magically places no unacceptable burden on being immediately good enough.

IT Capability improvement is thus a parallel consideration to IT's competency improvement. In particular, if the business determines that it is not being demanding enough to achieve a reasonable level of the potential represented in the business model and business plan, IT's capability might become a decisive new factor, with greater capability offering the business new kinds of opportunity that can be exploited for greater business value, and lesser capability being an all-around inhibitor.. This is not , however, a business decision that is essentially dependent on ITIL-maturity -- and certainly not dependent on a false concept of "ITIL-compliance."

By analogy: you're not likely to win a playoff game if all you have is your third-string rookie quarterback -- a not very mature quarterback. But in such a case, winning now instead of losing now will require having the right (probably other) persons call the plays, having the right additional roles execute well, and having everyone use the same system of coordination so as to maximize efficient pursuit of the only advantageous paths to the goal. Your longer-range intent will always still be to bring a great quarterback into your game. On the flip side, adding a great (very mature) player to an average team can obviously improve the team by adding new dimensions to its options and execution. But the rest of the team must be capable of taking advantage of the quarterback's ability, and it may need to be reorganized in order to gain that capability.

So, if your organization has an ITIL Initiative and you are frustrated with a perceived lack of "progress", it is entirely approprate to first review whether expectations are driven by a definition of the right problem to solve, and likewise whether the requirements that performance assessment is based on have been derived primarily to represent competency instead of merely capability.

Finally, if your primary perspective and responsibility is "compliance", then you are engaged in an initiative whose fundamental justification is risk management, not competency. In this case, there is no built-in conflict from using ITIL as a frame-of-reference, but the performance assessment should be based on measured changes in risk factors that are demonstrably linked to capability levels, not based on competency-driven business value factors.

Posted by Malcolm Ryder at January 12, 2006 10:12 AM

Trackback Pings

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

Comments

Post a comment