Reactive vs Proactive Problem Management

Problem management in IT is rarely discussed, but it is certainly practiced daily—in a variety of ways, some of which are successful. More often, problem management looks like a group of sys admins arguing about who’s to blame for the latest episode of company-wide slow-down.

When done well, however, problem management has the potential to catapult the IT unit from a fire-fighting position to one that offers a clinical focus on improvement and innovation—precisely the value and ROI that your company expects from IT. In fact, the way IT goes about identifying, managing, and eliminating problems plays a major role in how the unit is viewed by other business units and the company at large. Atlassian reported that high-performing IT teams are nearly 2.5 times more likely to practice problem management proactively, instead of waiting to put out fires.

In this article, we’ll take a look at problem management and compare reactive and proactive approaches.

What is problem management in IT?

We already know from ITIL that any problem is an underlying cause of one or more incidents. Problem management, then, refers to how you manage the lifecycle of problems. IT can approach problem management in two ways: reactively or proactively.

• Reactive problem management is concerned with solving problems in response to one or more incidents.
• Proactive problem management is concerned with identifying and solving problems and known errors before further incidents related to them can occur again.

Both approaches are key to ensuring a holistic and comprehensive tackling of the underlying issues that negatively impact IT services, but it is the reactive approach that is usually the first port of call for most support teams. Balancing the two approaches must be ingrained throughout your organization and should be one of the leadership’s imperatives.

Defining reactive problem management

Reactive problem management is triggered directly after an incident that is deemed worthy for a root cause investigation, such as one major incident or a series of incidents which are significant in totality. It complements incident management by focusing on the underlying cause of an incident to prevent its recurrence and identifying workarounds when necessary. Reactive problem management considers all contributory causes, including causes that contributed to the duration and impact of incidents, as well as those that led to the incidents happening.

The swarming technique is a strong approach in reactive problem management: different units come together to examine an incident, then brainstorm and identify the source and the potential root causes. Take, for example, an application that has crashed. Incident management would restart services that have stopped or reload a recent version, while reactive problem management would investigate the source of the crash by analyzing logs or getting information from a developer or vendor. The problem would be logged as a direct reference to the incident and workarounds, as identified by incident resolution, would be documented alongside it. If the fix requires a patch, then change management process would be used to permanently resolve the problem.

Other techniques for reactive problem management include chronological analysis, Kepner and Tregoe, 5-Whys, and fault isolation.

One of the main drawbacks of reactive problem management is its defensive nature, not unlike closing the gate after the horse has bolted. Secondly, technical teams are usually under pressure to find the incident’s root cause instead of focusing on restoring service as quickly as possible. However, the benefits of reactive problem management are clearly visible to stakeholders once it is proven that a fix, whether permanent or temporary, will prevent recurrence or reduce impact should the incident resurface.