Let’s clear up five common myths about ITIL certification:

The class is boring. In fact, the discussions, real life examples, and simulation exercise keep students awake and engaged.

The certification exam is tricky and unfair. The Foundation test consists of forty multiple choice questions, 65% of which must be answered correctly in order to pass. Thorough review of the material should guarantee a passing score.

A classroom experience is necessary to pass the exam. Self-paced online training is available. For approximately $300, it is possible to achieve ITIL certification in your spare time. The official ITIL website also provides a sample exam and other study resources.

It's not important to one's career. Although you may not miss out on a promotion for lacking it, ITIL certification is increasingly recognized by and important to management. It can only help to have a tangible record of your service management knowledge.

The old V2 certification is good enough. V3 is a replacement of the previous release, not an add-on. There are thirteen new ITIL processes and it's important to keep up with changes to the framework.

Recently there has been a hot debate, an ITIL forum thread of approximately 150 posts, over whether a Major Incident should automatically be classified as a Problem. It seemed that the voices advocating the creation of a Problem record for every Major Incident were more assertive and enthusiastic, to put it nicely. I’m sure my RightStar colleagues would often find me guilty of getting lost in the weeds of ITIL theory, but for this issue, I believe I’m more apt to consider what happens in real life for our organization and for our customers. I’ll share with you here some of my own thoughts and conclusions.

First we’ll look at textbook ITIL definitions. Many organizations and IT managers are still sorting out the difference between Incidents and Problems. The example I typically give is that of a user calling about a network printer issue. The user is unable to print to the network printer. What should the Service Desk analyst do? Well, since the Service Desk analyst is supposed to be responsible for Incident Management, by definition the analyst should be focused on restoring the service (in this case, printing) as quickly as possible. The analyst should follow standard troubleshooting procedures within predefined timelines. But if he or she is unable to resolve the Incident, the user’s system may need to be routed to an alternate printer. When the Service Desk analyst confirms that the user can print to the alternate printer successfully, the Incident record can be closed. An Incident is then simply defined as a disruption to normal service.

But of course the printer is still broken. This is where Problem Management steps in. The Service Desk analyst should create and link a Problem record for the printer issue to the Incident record and assign the Problem to the appropriate manager or group. The Problem Management process will be engaged to determine the root cause, develop or document workarounds (such as routing to an alternate printer) and ultimately provide a fix, whether it be to clear a printer jam or send the printer in for warranty repair. A Problem is defined as the cause of one or more Incidents, and the Problem Management process assumes that the cause of the Problem is not known when the Problem record is created.

Getting back to the debate and how that relates to real life for most of the organizations we’ve worked with—after reading some of the posts in the forum, I thought of an example of a Major Incident that doesn’t fit the criteria or definition of a Problem. What about a power outage? For smaller organizations especially, it’s not practical to have a fully redundant collocated data center for all of their services. And even if the data center is not impacted, there may be remote sites that need assistance with computer-related issues because the communication to headquarters or their own computing capabilities are compromised.

In this scenario, the power outage is the cause of one or more Incidents or disruptions to service. But we cannot assume that the cause of the Problem is not known. There was a storm, the lights are out and we should know why the computer won’t turn on. No root cause analysis is necessary. And the organization doesn’t have the influence to negotiate with the power company or with the weather if that was the cause of the outage. I would therefore argue that this situation would warrant the creation of a Major Incident, which is defined as an Incident that results in significant disruption to the organization. But it does not require the creation of a Problem record or the engagement of the Problem Management process. As long as alternate manual procedures are standardized and followed, the relevant information for handling the outage should reside within the Incident Management process.

It makes sense for the Major Incident record to be linked to the other Incident records so that IT can measure the impact of the outage. We would also like a mechanism that will allow us to share the information with the support staff and other customers as necessary. For users of BMC Service Desk Express, what should come to mind is the White Board notices module. This module, under the heading of “Crisis Management,” has many advantages. First of all, the sharing of information is facilitated by the scrolling White Board Ticker marquee. Individual records can be segmented to limit the display to a specific group or to include the display for the Self Service interface. Secondly, subsequent Incidents that are linked to a White Board notice can be automatically populated and updated with information from the White Board notice. Finally, when a White Board notice is closed, all related Incidents can automatically be closed with it, and a business rule will fire to send email notifications to affected users. I would even recommend renaming the “White Board” module the “Major Incident” module.

As always, ITIL is not a framework to be swallowed whole. It was developed to provide guidance for IT service management best practices and to be adapted to each organization’s needs. I expect that we’ll continue to debate the intentions of the ITIL authors. Ultimately, our goal is to provide better service and to deliver solutions that make sense.

In my ITIL v3 Foundation classes, students new to the terminology of formal IT service management often struggle to wrap their arms around the concept of the Service Catalog. Most IT staff can understand a category tree or a category-type-item schema. They look at the services they support from an IT point of view. But when IT needs to communicate to their customers, it’s important that the Service Catalog also have a business face. And IT should understand which external facing services are impacted by the business services they support.

For example, I buy books from Amazon.com. Books and the shipping that sends those books to my door are the services I buy from the business. The business in turn depends on order fulfillment and tracking systems, among others, to ensure accurate and timely delivery for me. In this example, “books” and “delivery” are the external services, which link to “fulfillment” and “tracking” systems in the Business Service Catalog. Those systems in turn link to “database”, “server” and “network infrastructure” in the IT Service Catalog.

It’s important that items in the Service Catalog be defined in simple terms with accompanying detailed descriptions so that the service definitions are widely understood. According to ITIL, the Service Catalog should define:

Of note here is the reference to supported services. Most services or systems, for example, will require network infrastructure. One challenging aspect of defining the service catalog is defining and recording the dependencies and relationships among services and components or configuration items (CIs). This is also, however, an exercise that offers great returns and benefits to the IT organization. If IT can identify relationships among services and CIs, then they can make more informed decisions when planning service outages and changes to the infrastructure.

What is your ITIL maturity level? At almost every RightStar monthly webinar, we poll the audience on whether they use ITIL as an organizational framework for service management. We’ve found that an ever increasing majority insist that ITIL is their de facto service management standard.

When we arrive on-site for implementation or upgrade services, however, we discover that there is rarely any thought given to the ITIL framework as it applies to the technology tool set, i.e., BMC Service Desk Express or BMC Remedy ITSM. This shows me that ITIL exists in theory more than in practice for most organizations.

It’s understandable that putting ITIL into practice doesn’t always make the “short list” given the demands IT organizations face. However, if an ITIL rollout can be done without a large outlay of time and money, it will quickly enable the organization to better deliver what the business wants and expects. Here are three steps to help jump start ITIL in your organization:

Invest in ITIL training, but don’t go overboard. We have often seen ITIL Foundation training being promulgated from the top to everyone in the IT organization. While the certification is valuable, that on its own does not guarantee service management success. Certification may be an indication that the holder can use the ITIL terminology and understand the processes, but it doesn’t provide the exact steps necessary for process rollout. A better use of your organization’s training dollars might be to begin with a small subset of ITIL champions, and then roll out training to all as an exact ITIL blueprint is defined.

Begin with Incident Management and build from there. Change and Configuration Management should follow, with Problem Management not far behind. Service Level Management is also essential.

Look at “ITIL in a box” solutions such as the Alignability Process Model (APM) for Service Desk Express and BMC Service Management Process Model (SMPM) for Remedy ITSM. These product toolsets allow organizations to quickly roll out an ITIL-based software solution. The process model is based upon a set of field-proven process flows and procedures that have been successfully deployed within numerous organizations.

Many organizations I work with have one or two ITIL enthusiasts who promote its adoption throughout IT. These champions often face indifference, ignorance, or outright resistance. To help them overcome these internal challenges, I encourage the ITIL promoters to start small and focus on ITIL’s tangible benefits.

Industry trends prove that ITIL works and is now the worldwide standard for how IT does business. As a result, unenlightened IT workers and departments ignore ITIL at considerable career and organizational risk.

At a minimum, IT staff at every level should pursue ITIL Foundation certification. This can be achieved with a three-day class. If the time or budget for this isn’t available, however, there is certainly no shortage of ITIL information on the internet. RightStar and BMC Software offer many ITIL-related articles and materials for educational reference. In fact, with all the information out there, the ITIL body of knowledge can quickly become overwhelming.

To make ITIL seem more manageable, I encourage IT departments to start with Roles and Responsibilities. This applies to IT departments of all sizes and helps groups within IT to narrow their focus. Most companies already have many of the ITIL process owner roles formally defined, such as Service Desk (a.k.a. Help Desk) Manager. Most also already know who would be responsible for many of the other roles (Problem Manager, Change Manager, Configuration Manager, Release and Deployment Manager, etc.) even if those people don’t have the actual ITIL titles.

It's also important to note that there are typically distinct and separate roles for process managers and process owners or sponsors. Many managers, especially within small- to medium-sized organizations, will take on more than one role.

Breaking the ITIL framework down into the individual processes and related roles will help IT departments identify their easiest starting points. Focus on the quick wins, and that will pave the way towards eventually adopting the full ITIL lifecycle.