While a primary objective of ITIL’s Problem Management process is to prevent problems and resulting incidents from happening, most organizations commonly start implementing Problem Management with a reactive approach.
This is commonly referred to as “reactive” Problem Management (PM) because, as its name implies, a service disruption has already occurred. On the other hand, “proactive” Problem Management (PPM) is an approach where problems and known errors are identified before incidents occur.
If PPM can identify problems and known errors prior to an incident, why do most organizations start with reactive Problem Management? The answer lies with the reality that it is easier to start a PM initiative by reacting to incidents. In some cases, it can require incremental costs to procure and deploy tools that proactively monitor events to predict possible future service, application or infrastructure failures.
This article presents one approach you can use to develop a PPM process by leveraging the existing tools you likely have in place. The approach is based on integrating your organization’s IT application development group’s defect management tool with a PM process.
What is defect management, you ask? Analyze the results of any software development effort and you are sure to find defects. No matter how hard you try or how much money you spend, it is impossible to eliminate all defects. IT application and software development teams generally implement some form of a defect management tool and process to help mitigate defects in the solutions they develop. Integrating this defect management capability with your organization’s ITIL-aligned PM process will help minimize the impact that software defects have on the business once the solution is deployed.
The 3 objectives of PM
According to ITIL, the PM is the process responsible for managing the lifecycle of all problems.
There are three primary objectives of PM:
- Prevent problems and resulting incidents from happening;
- Eliminate recurring incidents; and
- Minimize the impact of incidents that cannot be prevented.
As IT development teams create and test new functionalities, they commonly discover defects and log them in a centralized repository known as a defect management tool. Logged defects are then assigned to team members who categorize, verify and prioritize each logged defect. As development and operation teams prepare for transition from dev to ops, these teams collaboratively review all defects that were not resolved and determine whether the release should be made operational with the known defects.
It is at this time that PM becomes directly involved with problem managers or coordinators, recording these identified known defects as known errors within the known error database (KEDB). The KEDB should include details of common error messages, possible workarounds and resolution activities that will help assist the Incident Management and Service Desk teams.
Another factor to consider when integrating your organization’s defect management process with the PM process is establishing a common set of defect and problem naming conventions that both processes and toolsets can use. It is also worth considering whether toolset integration is possible to streamline activities such as entering or updating data.
This reduces “swivel chair” activity for database administrators and helps to ensure data accuracy and updates occur in simultaneously in both databases when defects are logged, worked on or fixed.