Disservice of ITIL Training

As we struggle in the transition to ITIL V3, our industry is still dealing with a pervasive and, yes, unfortunately, very destructive influence left over from previous versions. If not corrected, this will only serve to slow acceptance of V3, but will undermine acceptance and integration of IT Service Management in general. Our clients look to us as experts. If we are hired as consultants, either internal or external, the expectation is we understand the ITIL framework. Further, if we are providing certification training, our customers should expect that we are preparing them to understand the conceptual essence of the framework. Unfortunately, this does not seem to be the objective of some training programs. The focus is on "training-to-the-exam" to maintain the high pass-rate advertised in the training sales literature. For those of you trainers out there, how many have been asked, "What's your pass rate?" as if that is the ONLY metric that matters?

When working with Foundations graduates, I am repeatedly amazed at the shallowness of knowledge exhibited by a percentage of individuals. They know the terminology. But they lack understanding. Each and every process is underpinned by a key objective and purpose. Yet this is not emphasized in training. We are distributing pins with a hope and a prayer that book smarts will translate to understanding.

Even at the Practitioner and Manager levels, many successful candidates have failed to integrate the concepts. It is not uncommon to hear, "ITIL says this..." or "ITIL allows for that...". And those trusting us, accept such announcements as gospel and, too often, as justification for ignoring risk that is being designed in to the process. Indeed ITIL may "say this" or "allow for that." But just because the framework makes such allowances, doesn't mean that going that direction is right for the organization - at that point in their maturity and capability! These are the tough questions that are overlooked - or perhaps avoided for the sake of expediency.

I would very much like to understand the cause of this all-too-evident phenomenon. One could conjecture that it is due to:

• The commoditization of ITIL training;
• The limited experience of newly minted trainers;
• The single-minded focus on one metric: pass rate;
• The inability or resistance of trainers to challenge the understanding of their students;
• The tendency of trainers, consultants, and certified professionals to take the easy course and avoid the tough issues.
  

Experienced trainers know that students will internalize new concepts within a mental framework with which they are familiar. They instinctively relate to something with which they are familiar. It is difficult for a student to divorce a new concept from previous experience. A trainer must recognize this and challenge assumptions to ensure the underlying objective and purpose crystallizes understanding.

Based on what we are seeing in the industry today, however, this does not appear to be happening. Many trainers are not challenging their students. Some consultants and "certified" internal personnel are not asking the tough questions. And for those who DO ask the tough questions, they face the daunting task of overcoming flawed beliefs reinforced by faulty, or at least, incomplete training. The credibility of the whole industry suffers as a result.

How Does a Process Consultant Bridge the Gap?

It is not at all uncommon for a process consultant, steeped in the virtues of his or her best practice expertise, to lose sight of the importance of selling their ideas. At times we do live an illusion. Why wouldn't everyone recognize the value of what we bring to the table? It just makes sense, right? Well, there are those with whom we work that are, at best, suspicious and at worst highly skeptical and resistant.

One particular project to which I contributed repeatedly helps me bridge the gulf between the domains of the highly technical and management. Under the guidance of a technical architect, this project required a careful integration of a technical solution couched within several key processes of IT Service Management. This was a unique opportunity for me to use my process design, improvement, and management guidance skills as part of a rather complex technical project. I have since used the solution we designed as an example of the critical importance of adopting a best practices process framework for my clients. When engaged with highly technical client personnel, I am now able to reference the process elements that underpinned the solution. Not only has this helped gain credibility for my services, but it has enhanced the acceptance of IT Service Management principles within my clients.

Simply put, to bridge the gap:

• Gain real-world, practical experience to which you can relate and gain credibility
• Work the organization from the top-down and bottom up
• Learn to speak the language of the target audience at both ends of the hierarchy
  
• Understand the challenges of all stakeholders
• Be prepared, at a moment's notice, to diagram and talk to your solution highlighting the value all along the way in a language or context that means something to your audience
• And finally, if you are speaking with network people, perfect the art of diagramming your solution on a wet cocktail napkin with a dull golf pencil.
  

Let's Have a Meeting

Isn't that always the solution? Hey, we're not communicating so, ah, gee, let's have a meeting. I'm here to tell you that rarely, if ever, is a communication problem so easily addressed. Making the assumption that a meeting will fix a communication problem is like assuming that training your staff in ITIL is sufficient to ensure implementation.

The first step in any effort to solve a problem is to first, identify the problem and then follow a process to identify root cause. Then, and only then can you even begin to think about solutions. I submit that having a meeting to solve a communication problem not only is probably NOT the solution, but it may do more damage than good. It takes away from other, possibly more productive, activities and it may, depending upon the underlying issue, drive the problem deeper.

Communications is hard work. Making communications work is hard work. Understanding the problems we have with communications takes more than jumping to conclusions. There's no short cut. But there is a clear path than can be followed by those who really desire a solution. If not, then give lip service to caring about communications and stand by your claim that "the meeting was suppose to fix it."

Are you Holistic?

One of the most popular terms that has emerged from the ITIL community is "holistic." Wikipedia says it is derived from the Greek word meaning "all," "entire," and "total." It's a term consultants like to throw around a lot. But let's face it, how many consultants actually believe it? Or the converse, how many companies listen to those consultants who do recommend a holistic, strategic, and program approach to IT Service Management? Consultants tend to live from gig to gig and rarely are they positioning themselves to provide holistic guidance for an ITSM implementation. Even more rarely, despite the barrage of holistic and enterprise-wide strategic planning pleas in the trade press, few companies look beyond the immediate process design project.

One might ask if one of the reasons for the initial slow adoption rates of ITIL in the United States is because of a short-term, project-by-project view of ITIL. Would the success rates be higher if the process projects were evaluated from a holistic, program perspective? Could we better quantify our success if the metrics used to evaluate our efforts were linked to the strategic goals of the organization? Would we better engage our IT folks if they understood how sitting through hours and hours of process design workshops actually supported how they, as IT people, add value to the organization as a whole?