In the area of process consulting for RightStar customers, we focus on ITIL as the industry standard best practice framework for IT service management. This framework is central to our work because it is the standard by which BMC’s products are measured and the guideline that most of our customers trust when developing processes for IT support. There are, of course, a number of other guiding frameworks for IT to consider. Most complement or otherwise support our focus on ITIL and include:

ISO 20000 has been of interest to me lately because it most closely reflects the ITIL framework, but goes beyond guidance and provides specific requirements for a standard of organizational certification.

All of these other considerations and practice areas were set aside, however, when a recent project opportunity required Help Desk Institute certification. Their certification standards cover HDI Support Center Analysts just starting out in the field all the way up to HDI Support Center Director level and HDI Support Center certifications for the entire organization.

For RightStar’s new project, I was tasked to pursue the HDI Support Center Manager certification and therefore to attend a recent certification class in Arlington, Virginia. Although many of the course topics were a review of familiar material, there were still opportunities for me to apply the lessons learned in performing my own role at RightStar.

Many of the units covered related to general management theory and good practices including the definition of a leader, effective communication practices, building a team, and managing stress, time, and organizational change. We also studied team strategy including vision and mission statements and workforce management, which are all applicable to my role at RightStar.

There were many worksheets and methodology concepts that will be useful guides in refining RightStar’s own assessment toolset. Many of these resources are standard and familiar, but it was helpful to review them and to confirm their continued usefulness in directing a course of action for the support center.

It was also interesting for me to analyze and discuss many of these topics from essentially our customers’ position. We reviewed IT service management system selection and, sometimes, frustration from the buyer’s perspective. My classmates often had questions, which the instructor would sometimes direct to me, about how to apply the ITIL process concepts taught in the course to their real life situations.

This story has a happy ending, of course. I passed my HDI Support Center Manager certification, which means I can sign this…

…Nikki Haase, HDI SCM

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.

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.