Will ITIL Work for This Client?

Not likely. Just look through the "findings". All seven have one primary element in common: they lack a process centric discipline. Management would obviously prefer to throw money and personnel and resources (and who knows what else) at the problem when, if the word "plan" was in their vocabulary, they could gain control over the infrastructure, eliminate waste and begin to reverse the perception that internal customers were dumping more and more money in a black hole without realizing any benefits.

ITIL success is dependent upon a number of key factors:

• A compelling reason to change and improve
• Top-down commitment (involvement)
• Top-down support (budget)
• Bottom-up buy-in
• A vision for IT
• Strong program/project management with a holistic, systems focus and awareness of the interedependencies of IT Service Management processes
• An attitude of accountability and a commitment to measurement

Do you think ITIL will work for your client?

Do you think ITIL will work for a client like this?
>While on the client site you open a closet to find three shelves of Information Technology Service Management (ITSM) software sitting there in the original shrink wrap...
>The client has a major web site go down for over three days, costs the organization in excess of $4 million and there's no effort to problem solve a root cause...
>The client's promotional materials boast about the size and complexity of their data center (yet you know it's large only because it's not managed!)...
>The client refuses to make time to train their key personnel in basic ITIL process management...
>You overhear a technical support person state that he 'thinks' the upcoming release will require upgrading some boxes but no one can reach the person who has rights to those boxes...
>The afternoon of a major release one of the managers says he'll wait around, stay an hour later, "just in case someone calls in with a problem with the release...".
>The client claims they want "best practices" but service levels fluctuate quarterly, sometimes monthly, depending on which business unit has yelled the loudest to the CIO.

Answer next week...

Fire Drill

Yesterday it was a fire drill to problem solve one of the web pages. The site was obviously down and an SA and supervisor were negotiating the level of problem solving necessary to get the system back up. As this chaos carried on a customer of the IT support group called a technician for support. One individual stated, rather bluntly, "It's not my job to fix your html code." The person on the other end said something and the support person responded, "I don't know who does that for you. You'll have to deal with that in your department."

The next day, it got even more interesting. One SA was on the phone describing a system that was apparently undergoing an upgrade. He stated that, although he's not familiar with the system and doesn't know what it does, he's seen "parts of it" around for a long time. He alerted the party on the other end of the phone that if an upgrade is done to one box, based on what he's found, the same upgrade must be done on another box. But he doesn't have access to the "other" box to
do the upgrade and has no idea who does have access. In the course of the conversation, this SA described what the upgrade is "apparently" intended to do. There were also conversations about who owned the box, in the context of, "So and so's name is all over this...is he the one to contact?..."

Shortly after this exchange, the supervisor of this same SA asked what was done yesterday to fix (yet) another problem they dealt with previously. Apparently the fix was not documented and was just "top-of-mind" in the SA's memory. Now, let's think about this for a moment. What would have happened if that SA had been off work? Can you spell, "r-e-w-o-r-k"?

Later that same day a group of support folks gathered around to discuss the above upgrade(s). One technician stated that he would stay around after the upgrade was implemented to see if there were any problems...something to the effect, "...In case anyone squeals..." Five or six folks were dscussing the change and not one of them seemed to have a definitive understanding of what might happen once the change was implemented.

In the four paragraphs above we've touched on:

• Configuration Management
  
• Change Management
  
• Incident Management
  
• Problem Management (and Structured Problem Solving)
  
• Release Management
  
• Service Level Management
  
• Service Desk, escalation, communication and basic customer service

Such a scenario is all too common in IT today but it goes to process capability of the people-process-technology evaluation. An assessment would certainly prove the process component is "ad-hoc" at best.

The purpose of an assessment is to:
1.) Establish a baseline and
2.) Provide the data required to build an implementation based on the positive aspects of the current processes.

But, given the sub-optimization in evidence here, any baseline would vary significantly
depending upon the group engaged in the assessment exercise. Thus the need to target a higher level sponsor to realize the benefits of an implementation.