Examples of Major Incident Criteria

The Professor was recently asked for real life examples or best practices for the criteria that organizations have used to define major incidents.
ITIL defines a major incident as an incident that results in significant disruption to the business and so real world examples are going to vary from one business to the next. For a financial services company, for example, a major incident could be an incident affecting live money transactions. For a retail company, a major incident could be an incident affecting its point of sale service. For a manufacturing company, a major incident could be an incident that affects the production line. Simply put… real dollars are being lost.

A major incident could also be a service outage that affects are large number of users. Those users could be your company’s external customers, or it could be your internal employees. So for many organizations, outages affecting the company’s web site, or its email or customer relationship management (CRM) services are viewed as major incidents.

A incident does not have to affect a large number of users, however, to be viewed as a major incident. One company had a small team of people who were responsible for reporting the company’s dealings to the Security Exchange Commission (SEC). If those reports were not filed in a timely manner, the company would face significant fines. Any time these people reported an incident affecting the service used to produce these reports, it was viewed as a major incident. So a major incident could be tied in some way to regulatory controls.

The bottom line is to look at your company. Determine those services that are revenue generating or that really underpin the way your company does business. If you have Availability and IT Service Continuity Management processes in place, look to those for guidance. Any services deemed “vital business functions” and that you would want to restore quickly in the event of a disaster, or that you have taken great pains to ensure high availability, are likely services that would you treat as a major incident in the event that they failed.

ITIL suggests having a separate procedure for handling major incidents and establishing a major incident team under the leadership of a major incident manager. Because this is a great commitment of resource, great care should be taken to ensure that not everything is viewed as a major incident. Remember that something can be viewed as a high priority incident, and still not cross that threshold to being viewed as a major incident.

By working with your customers via the Service Level Management process you can determine what is really critical to your business.

Dealing with Major Incidents

A close friend of mine has a saying that I always remember “All roads lead through incident management”. We know that the primary goal of the incident management process is to restore normal service operations as quickly as possible and to minimize any adverse impact on business operations. This will insure the highest levels of service quality and availability are delivered to the user community, guaranteeing that the business is receiving value and facilitating the outcomes it wants to achieve.

The value this process produces for the business is in the ability to:

• detect and resolve incidents quickly, resulting in higher availability of IT services.
• align IT activities to real time business priorities and dynamically allocate resources as necessary.
• identify potential improvements to services, through the analysis of incident trends.

So it sounds like we have everything covered as long as we handle all incidents in the same consistent and proceduralized manner. Well not so fast. What happens when we have an incident that affects a major business process and in turn creates a major impact to the business?

For these types of situations we need to have a separate procedure, with shorter escalation time scales and greater urgency in responding to “Major Incidents”. First we must agree on a definition of just what constitutes a major incident and how it will be integrated into the overall incident prioritization system.

Note: Many organizations that I have corresponded with confuse this separate process with problem management. A major incident may increase in impact to the business thus increasing in the priority it needs to be addressed by the ITSM processes but it still remains an incident and never becomes a problem.

Where necessary , the major incident procedure should include the formation of a separate and dynamic major incident team (under the leadership of the incident manager) to concentrate their efforts on the particular incident alone and insure that adequate resources are engaged and solely focused on providing a swift resolution to the impact at hand. Problem management can be involved if the underlying cause needs to be discovered at the same time, but the incident manager must ensure that restoration of services and root cause analysis are kept separate and that impact reduction is the priority.

Cost per Incident

A reader, upon downloading our ITIL ROI calculator, recently asked the following great question, “how do you determine cost per incident?”

Cost per incident is a variation of cost per call or cost per contact, all of which are excellent ways to understand the impact of incidents, calls, or contacts on the business.

The calculation is fairly straightforward. Cost per incident is the total cost of operating your support organization divided by the total number of incidents for a given period (typically a month).

Cost per incident = total costs/total incidents

To accurately calculate cost per incident you must:

• Log all incidents. You may also find it beneficial to distinguish between incidents (unplanned events) and service requests (planned events). Such a distinction will enable you to more accurately reflect business impact
• Identify stakeholders. Determine all of the support people involved in the incident management process (e.g., service desk and level two/three technical and application management teams). 
• Identify associated costs. Create a list of every cost associated with your stakeholders including salaries, benefits, facilities, and equipment. Many of these costs will be included in your annual budget or can be obtained from financial management.

As illustrated in the ROI calculator, tremendous cost savings can be realized by reducing the number of incidents. This can be accomplished by using trend and root cause analysis techniques via the problem management process, as well as through integration with processes such as change management, service asset and configuration management, and release and deployment management.

Savings can also be realized by reducing the number of incidents escalated from the service desk to other lines of support, or by increasing the number of incidents handled via self-help services such as a web-based knowledge management system. Some organizations report on cost per incident per channel (e.g., per call, e-mail, chat, walkup) to better understand these savings.

Demystifying Cobit and ITIL

Our senior IT executives are being held accountable to better manage the quality and reliability of IT in business and respond to a growing number of regulatory and contractual requirements. Every enterprise needs to tailor the use of standards and practices to suit its individual requirements. Control Objectives for Information and Related Technology (COBIT) and the IT Infrastructure Library (ITIL) can both play a useful role in IT governance.

Very simply COBIT helps our senior management teams to define what should be done and ITIL provides the framework for how to manage our services.

When we think about COBIT and IT governance at the most fundamental level, there are four questions that every leader asks him or herself when it comes to IT initiatives:

• Is my IT organization doing the right things?
• Are we doing them the right way?
• Are we getting them done well?
• Are we getting value from our IT department?

COBIT helps answer these questions by defining IT activities in a generic process model within four domains along with a set of information criteria. The four domains are: Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate. The COBIT framework provides a reference process model and common language for everyone in an enterprise to view and manage IT activities. 

 

ITIL speaks more to an operational level of service management and the framework answers these questions:

• What are my IT services? 
• What are best practices for managing my services?
• Are we following best practices for our processes?
• How do we monitor and measure our services?

These questions are answered by following the guidance given by the ITIL framework. The ITIL framework has 5 lifecycle stages, Strategy, Design, Transition, Operations and Continual Service Improvement.

 

By an organization knowing what it should be doing and combining that with best practice on how to accomplish these tasks, top management, business management, auditors, compliance officers and IT managers can work together to make sure IT best practices lead to regulatory compliance with cost-effective and well-controlled IT delivery.

 

 

Roles vs. Jobs

During one of my recent classes a discussion came up about the difference between roles and jobs. ITIL v3 speaks to the importance of roles in performing the steps or activities of a process or procedure.

A role is a set of responsibilities, Activities and authorities granted to a person or team. A Role is defined in a Process. One person or team may have multiple Roles, for example the Roles of Configuration Manager and Change Manager may be carried out by a single person.               --Service Strategy Glossary

This appears to be a fairly clear definition of “role”. So why do some people have difficulty identifying the proper roles to play during the execution of a process? As the recent discussion showed, it may be because of our long focus on jobs as opposed to roles.

Most learners recognize a difference between the two. When asked how many “job titles” they have, the answer is inevitably that they have one job title. When asked how many roles they perform, they inevitably respond that they play many roles! But the traditional focus on a hierarchy of control tends to have people focus on their job titles and to whom they report, rather than on the duties, steps, activities or instructions they carry out. Unfortunately the majority of people with the title “Analyst” do little or no analysis! Also jobs often get performed one task at a time, rather than according to process or procedure.

To make a process or procedure work most effectively we must begin to shift our focus towards roles, rather than only job titles. How can we make this shift? Here are some easy steps to follow (yes, a process!):

1. Each day when you come to work identify which services you will be supporting that day (it may vary or it may not depending on your own organization)

2. Identify the possible processes you will need to use during the day to strategize, design, transition, operate or improve those services

3. Identify your assigned role within the processes

4. Locate or gather the procedural and work instruction documents for those roles and place them in a convenient location for reference.--If needed, create “cheat sheets” or “quick reference documents”

5. As need arises, perform the steps of the process, procedures, or work instructions, constantly referring to the documentation when in doubt about the next step(s).

6. Make note of how long it took you to perform the process steps as a whole. That way you can compare your daily performance and work towards improvement!

7. Eventually you will be able to perform the process, procedures or work instructions without constant reference to documentation. But keep them handy! Sometimes we may not perform a process daily and so need a refresher (even Professors!!)

Too often we have convinced ourselves that we “know” our jobs or roles because we do them so much. But it never hurts to make sure you really do perform the roles properly (according to process). When we focus on process rather than just assigned tasks, we can begin to maximize the value we bring to the customers and users of the services we provide.