Bridging the Gap: The Vital Role of Problem Management in Incident and Change Processes

In any organisation, several critical processes play key roles.  Yet, there is often one equally important process that tends to be underutilised or not given the attention it deserves to mature the process.  In my experience, this process is Problem Management!  

While Incident Management focuses on swiftly restoring services, and Change Management is about controlling changes within environments, what often remains unaddressed is what happens after an incident occurs or when a change goes awry.  So, how and where does the follow-up take place?  

This is where the Problem Management process becomes your best friend!  According to a recent AXELOS survey, Problem Management emerges as a crucial ally.  Among the three core IT Service Management (ITSM) processes—Incident, Problem, and Change—Problem Management boasts an impressive 80% adoption rate.  However, there is still room for improvement, as only 31% of respondents reported that it is working well, while 69% acknowledged the need for further enhancements.  (Source HERE)  

 So, what is Problem Management, and why should we invest time in it?  

According to ITIL 4, “The purpose of the Problem Management practice is to reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents and managing known errors and workarounds.”  

By leveraging the power of the Problem Management process, you can proactively detect and record Known Errors in the Known Error Database.  This enables agents to quickly identify and apply the recorded workarounds or, in a reactive approach, identify the underlying cause of one or more incidents and strive for a permanent resolution.  As a result, you can achieve a remarkable 10-fold reduction in incidents, allowing the service desk to focus on handling clearly prioritised incidents based on their impact and urgency (source: ServiceNow).  

One common misconception is that problem records should use the same priority matrix as incidents.  Instead, problem records should have their own priority matrix, driven by the risk, which assesses the potential impact and probability of the issue reoccurring.  For instance, consider a server that experiences memory shortages weekly, prompting the monitoring system to pick up the memory utilisation and trigger a P4 (no impact) incident.  Although this may seem less critical, its high frequency poses a greater risk to the organisation compared to a database bug that may occur once a year and cause a P1 incident (high impact).  

While both matters warrant investigation within the problem management process to determine their root cause, giving higher priority to the server memory issue is essential due to the high frequency and potential risk it poses to the organisation, unlike the database bug.  

Problem Management can improve the Change Management process if a change has been implemented but has failed for some reason.  Following the Problem Management process, which includes reviewing the Change Implementation plan, allows time for an investigation into what went wrong, why it went wrong, and what caused the incidents.  This feedback can lead to further improvements in the Change process and drive a higher change success rate.  

In conclusion, Problem Management extends beyond merely reviewing major incidents and their root causes.  Its potential impact within the wider organisation reaches far beyond what we give it credit for, offering substantial benefits to the key ITSM processes.  

For more information on the art of the possible within the Problem Management Process or to speak to one of our Service Management consultants about how we can help deliver your ITIL journey and improve the customer experience, get in touch today!