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) ser...

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...

In speaking with colleagues and practitioners, I have found that one of the greatest difficulties for companies to overcome in a Service Management implementation is the desire to be more complex and unbalanced than is absolutely necessary. One of the most basic and underlying elements of good Service Management is the achievement of balance in how we approach the delivery of value to the customers and users through services. Balance helps us to find an equitable point that brings value to the customers and users without throwing out the efforts and actions needed to keep IT going. When I speak of balance, I am referring to finding the middle ground between extremes. These include balances like the amount of time and effort spent between Incident Management and Problem Management; or perhaps the balance between flexibility and stability; or even the challenges of being proactive versus reactive; customer/service-centric versus technology-centric. There are a multitude of these types ...

I often hear from organizations that they are not reaping the expected benefits from their Incident Management Systems or integrated Service Management suites. One of the biggest reasons is that they are struggling to determine how to categorize incidents, problems, service requests, changes, and so forth. Coming up with the right categories for your organization is easier said than done. If you’ve had to do it multiple times, you’re not alone. Having said that, it is important to persist. Categories drive many process activities such as: Incident matching Second- and third-level escalations Workflow management Self-service decision tree logic Priority definition Knowledge base searches Trend and root cause analysis Metrics production SLA reporting Miscategorized records cause inefficiencies, ineffective reporting and can even damage the relationships between lines of support. For example, are your second-line support teams regularly asking “why was this record assigned to me?” If so, ...