Major Incident? To Fix Or Not To Fix, That Is The Question?

Major Incident? To Fix Or Not To Fix, That Is The Question?

For anyone who has been on the ITIL Foundation course, there is one simple answer to this question, the focus of the Major Incident should be about restoring service to the business as quickly as possible, and a subsequent Problem ticket should be raised to identify the root cause and fix the issue. Unfortunately nothing is ever as simple as that. 

The focus of the technical teams is almost always on understanding the issue and then focusing on fixing it rather than trying to get the business back up and running. Often there is the requirement for a bit of ‘out of the box’ thinking to get service restored, and this is something that needs to be encouraged rather than coming naturally. 

Equally, senior management don’t really understand the distinction between an Incident and a Problem.  If they are told that the Major Incident is being closed because the business is back up and running, although the incident is yet to be fixed, they typically become apoplectic and insist that the Major Incident continues to run, despite a problem being raised to understand root cause. 

This is where having strong resources, that are dedicated to running Major Incidents and Problems, and a documented, and signed off, Major Incident and Problem Management process, becomes so important. 

A lot of the confusion arises because both Major Incidents and Problems are not standard issues that are covered as part of any knowledge management.  Both are exceptional events for which, often, the same people and techniques overlap. 

What needs to be clear is that the focus for a Major Incident is very much immediate and customer-centric, aimed at the restoration of service. Conversely, a Problem is the investment in resources to identify the root cause of the issue, removing the error(s) and ensuring that the issue cannot recur. 

There is a lot of discussion within the ITIL community whether a Major Incident should be managed as a Problem, whether a Problem should be raised in parallel, and whether every Major Incident should raise a Problem. ITIL is unclear on this subject, although it is very clear on the difference between an Incident and a Problem.  

There is no correct answer to this discussion, while people have their own views, it very much depends on the size of the organisation, the tools that are used, the processes that are in place, and ultimately what works for the specific business.  

My personal view is that there will have been something exceptional that will have happened to trigger the Major Incident, and this will require a Problem record to be raised.  The post-Major Incident Review may identify multiple Problems, whether technical or process related, each of which will require a Problem record to be raised and tracked. Tracking them as a single Problem or, heaven forbid, on a separate tracker, can lead to all sorts of confusion and delays in resolving the actual root cause. 

It is essential, that whatever your approach to Major Incidents and Problems, you keep in focus the objectives of the two and have clearly defined processes that detail how each should work for a particular organisation, along with the hand offs that are required between the two. Never forget that the ultimate objective of any Service Management team, is the provision of service to the business, and any supporting processes need to be continually reviewed to ensure that they are still relevant.

If you would like to find out more about how iCore can help you with your Incident Management process, then contact us on 0207 868 2405 or email info@icore-ltd.com