One of key reasons that ITIL does not proscribe an ‘approved’ priority list for process implementation is that such a list cannot take into account the relative maturity of an organization’s existing staff, skills, and operational proficiencies. Only a focused assessment can do that. |
||||||||||||
By Mike Drapeau As organizations begin to better understand the ITIL (IT Infrastructure Library) framework, send their employees to training to obtain ITIL certifications, and sometimes engage consultants to assist in diagnosing how ITIL can help them achieve operational efficiencies, they begin to appreciate that, for all its advantages, ITIL has some missing elements.
One key omission is that of prioritization – which ITIL process or processes should an organization tackle first and why. By design, ITIL is descriptive, not prescriptive. That is, ITIL describes what has to get done, not how to get it done.
Determining any implementation order is subjective and will change from company to company based on the unique situation of that company. Thus, ITIL says little about the relative importance of one process or another, leaving such distinctions to the organization to determine.
Even if one limits the scope to just the ten (10) IT Service Management (ITSM) processes, no formal priority emerges, at least none formally advocated by the UK’s OGC (Office of Government Commerce) – the organization which promulgates ITIL. For the purpose of simplicity, the remainder of this article will cover just the ten ITSM processes.
Although ITIL is ‘missing’ this key piece, one should not be led to believe that this omission is fatal to an ITIL implementation; it is not. Nevertheless, each organization contemplating an ITIL project should understand what gaps need to be plugged and plan accordingly.
Following I describe the idea of ITIL Triage: how to determine in which order the ITIL processes should be implemented and why. Getting There from Here (or End State vs. Current State)If the ITIL framework doesn’t explain how to implement a process, what does it do?
The answer to this question is important to understanding the difference between a best practice and an operating manual. Simply put, the ITSM framework describes how a set of interdependent processes (five for Service Delivery and five for Service Support) ‘looks’ when it is fully implemented. In operational terms, this is known as end state. Thus, by reading the ITIL publication for each process, a manager can better understand how their operation might function in the future.
This realization that a veritable gulf exists between current state and future ITIL-based operational nirvana prompts many to conduct a ‘gap analysis’ or ‘maturity assessment’. The fruit of this analytical exercise is to identify what processes are deficient, in what magnitudes, and the impact of these discrepant conditions.
One of key reasons that ITIL does not proscribe an ‘approved’ priority list for process implementation is that such a list cannot take into account the relative maturity of an organization’s existing staff, skills, and operational proficiencies. Only a focused assessment can do that.
Furthermore, OGC and ITIL do not provide an indication of the ‘best’ method for closing the gap in terms of which processes, once implemented, bring the greatest payback. They can be forgiven for this omission, as the color-by-numbers approach for ITIL implementations does not leave sufficient room for organizational uniqueness. Interim StatesDetermining how to move from current state to the greatly desired future state is more than simply cherry-picking your high priority processes and relegating the rest to some future phase. The greatest challenge, in fact, lies in the work in between the present and the glorious future. How to tackle this challenge, however, is not addressed within the ITIL framework itself.
An ITIL process rollout, properly managed, consists of a series of ‘interim states’ that mark the transition from a pre- to a post-ITIL environment. These interim states are specific and measurable maturity markers placed along the implementation path to signal to users, supporters, and even detractors that the project is on track.
This requires the full range of project management disciplines and the artifacts of this methodology -- tasks tracked, milestones achieved and publicized, cultural barriers overcome, adoption rates measured, executive support garnered, and so on. The need for this iterative approach is unarguable.
Without it, an organization attempting to implement ITIL will be unable to map the path from present to future and will be left without the string of small victories necessary to achieve operational transformation. Planning and JustifyingWe have spent some time identifying various aspects of the current ITIL framework with regard to process priority and implementation methodology. It deserves noting, however, that ITIL does offer a key book entitled ‘Planning to Implement Service Management’.
Many organizations when contemplating or even initiating ITSM implementations move briskly into the Service Delivery and Service Support books which contain the details on each of the 10 ITSM processes. What they forget to do is first spend the time reviewing and incorporating the guidance contained in Planning to Implement Service Management.
This can be a fatal mistake because this publication does address process prioritization. Section 1.10.2, for instance, directly recognizes that implementation demands a process ‘stack rank’ and offers the possibility of choosing Change before Configuration Management or Incident before Problem Management or even Service Level Management before IT Financial Management.
This either-or approach, though, merely identifies some strong process dependencies; it does not, though, provide a structure for prioritization all 10 ITSM processes.
Planning to Implement Service Management does help with the following challenges while in the earliest phase of an ITIL rollout”:
Though it may not provide definitive guidance on process prioritization, this book is a must read for any organization even considering moving into an ITSM framework. One Approach to PrioritySome propose beginning with Change Management, as it is one process which can 'stabilize' the patient. One popular third-party approach suggests deploying elements of Change Management, then a slimmed down form of Configuration Management, followed by elements of Release Management such as the Definitive Software Library (DSL). With these building blocks in place, they suggest embedding continuous improvement disciplines and positioning the organization to branch out into the remaining ITIL Service Management processes. This approach presupposes that effective Change Management is lacking, which is not always true, and also presupposes that a DSL can improve service quality, again, not always true. However, the significance of this approach is that it takes a position on which processes are ‘more important’ than others, provides practice guidance on which aspects within a process to embrace first and how an organization can gradually lift itself out of an operational morass.
Others propose 'stabilizing' via the Service Desk/Incident/Problem approach, and then 'optimizing' via the Change/Configuration and Release processes. Of course, this approach presupposes that the highest level of organization pain is coming from Service Desk/Incident and Problem (which again, may or may not be true.)
Many approaches, including the two presented here use medical terminology in describing ITIL implementation, and this is no accident – improving IT efficiencies has a lot of similarities to the challenge of an emergency room doctor -- namely that they face a lot of ill patients with sicknesses, both visible and undetected, and they need to analyze which cases to take first what to do with them and how to manage the remainder. This process, known as triage, captures quite accurately the methodology organizations should use to move to operational good health.
As before, there is no cookbook for ITIL implementation. Deciding which processes to implement, and which order to implement are best decided by examining stakeholders and making a situational decision. Then using ITIL as a guidebook to establish expected behaviors. Practicing ITIL means diagnosing the patient, in this case an IT organization. Based on the symptoms seen, a diagnosis occurs, and the practitioner can examine how to treat the patient. The SolutionNo ITIL article is worth its salt unless it leaves you with some firm and sensible guidance so, it is important to note that there is a way out of the challenge of process priority. The solution is to practice ITIL triage. The dictionary defines triage as follows:
“A process for sorting injured people into groups based on their need for or likely benefit from immediate medical treatment. Triage is used on the battlefield, at disaster sites, and in hospital emergency rooms when limited medical resources must be allocated.”
Refashioning this a bit, we can derive the following definition for ITIL triage:
“A process for sorting inefficient operations into ITIL processes based on the client’s need for or likely business benefit from immediate improvement. ITIL Triage is used in the data center, at disaster recovery sites, and in boardrooms when limited financial resources must be allocated.”
Simply put, the discipline of ITIL triage helps organizations determine which processes to implement, in what order, and with what expectations. Earlier last year, Beverly Head of CIO Australia wrote an intriguing article for IT World entitled “IT triage: stop, revive or survive” which scoped out a similar approach for CIOs contemplating a better form of governance.
So, how can a Do It Yourself (DITY) organization implement ITIL triage?
For that, we will have to wait for a follow-on article. But suffice to say that ITIL triage requires a vigorous and frankly self-critical assessment of financial limitations, organization, internal centers of excellence, culture, staffing, documentation, practices, human resources, existing tools and software, and executive commitment.
At the end of the ITIL triage, some patients (i.e. processes) are wheeled into the ER for immediate repair and others are considered beyond saving. Such distinctions are difficult to the make in the business world, but no more difficult than in the life and death triage that faces doctors in times of crises. -- Where to go from here:
|
||||||||||||
|
Entire Contents © 2006 itSM Solutions LLC. All Rights Reserved. |
