Problem management

Incident management restores service; problem management asks why the incident happened and how to stop it happening again. In plain words, the purpose of problem management is to reduce the likelihood and impact of incidents by identifying their actual and potential causes, and by managing workarounds and known errors. An organization that only fights incidents stays busy forever. An organization that also manages problems gradually removes the causes of recurring pain and frees capacity for more valuable work.

Key terms

ITIL uses three related terms that are often confused. A problem is a cause, or potential cause, of one or more incidents. A known error is a problem that has been analysed but not yet resolved; its cause is understood, or at least a workaround is documented. A workaround is a solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. Workarounds can be applied by users, the service desk or technical teams, and good ones are recorded in the known error database so everyone can find them.

The distinction between incidents and problems is essential. An incident is the event users experience: the service is down. A problem is the underlying cause: a memory leak, a misconfigured load balancer, a supplier defect. One problem can cause many incidents, and one incident may reveal several problems. Incident records describe impact and restoration; problem records describe causes and their removal.

Three phases of problem management

ITIL 4 describes problem management in three phases. Problem identification finds problems. Problem control analyses them and documents workarounds and known errors. Error control manages known errors through to resolution, including deciding whether a permanent fix is worth its cost. The phases overlap, and a problem may move back and forth between them as understanding grows.

Problem identification

Problems are identified in two main ways. Reactive identification follows incidents: a major incident almost always triggers a problem record, and trend analysis of incident data reveals recurring issues that individually seemed minor. Proactive identification looks for problems before they cause incidents: reviewing information from suppliers and developers about known defects, analysing monitoring data for early signs of trouble, examining near misses, and learning from incidents at other organizations that use similar technology.

Trend analysis is one of the most valuable and most neglected activities. It depends on good incident data, which is why lesson 3 stressed logging and categorization. A simple and powerful technique is Pareto analysis, which sorts incident categories from most to least frequent and shows how much of the total the top few account for. Often a small number of categories accounts for a large share of incidents, and attacking those gives the biggest return.

# Pareto analysis of a quarter's incidents by closure category (synthetic data)
counts = {
    "password and lockout": 640, "VPN connection drops": 410, "printer queue stuck": 285,
    "email sync on mobile": 190, "report timeouts": 150, "laptop docking": 95,
    "shared drive permissions": 80, "browser plugin errors": 60, "other": 90,
}
total = sum(counts.values())
running = 0
print(f"{'category':26}{'count':>7}{'share':>8}{'cumulative':>12}")
for cat, n in sorted(counts.items(), key=lambda kv: kv[1], reverse=True):
    running += n
    flag = "  <- top group" if running - n < 0.8 * total else ""
    print(f"{cat:26}{n:>7}{n/total:>8.1%}{running/total:>12.1%}{flag}")
print(f"total incidents: {total}")

category                    count   share  cumulative
password and lockout          640   32.0%       32.0%  <- top group
VPN connection drops          410   20.5%       52.5%  <- top group
printer queue stuck           285   14.2%       66.8%  <- top group
email sync on mobile          190    9.5%       76.2%  <- top group
report timeouts               150    7.5%       83.8%  <- top group
laptop docking                 95    4.8%       88.5%
other                          90    4.5%       93.0%
shared drive permissions       80    4.0%       97.0%
browser plugin errors          60    3.0%      100.0%
total incidents: 2000

In this synthetic quarter, the first four categories account for roughly three-quarters of all incidents, and the first five for over 80 %. A problem manager would open problems for the top categories first. Note the caution, though: frequency is not the only measure. One rare category may have very high impact per incident. Weighting each category by its business impact or by the total hours lost often changes the ranking.

Problem control

Problem control analyses problems to find their causes and, where possible, documents workarounds. Problems are prioritized in the same spirit as incidents, based on the risk they pose: how many incidents they cause or could cause, how severe those incidents are, and how likely recurrence is. Not every problem deserves deep analysis. A problem that caused one minor incident three years ago and never recurred may be recorded and left alone.

Analysis uses structured techniques. ITIL does not mandate any, but several are widely used. The five whys asks why repeatedly until a cause is reached that, if removed, would prevent recurrence. Ishikawa (fishbone) diagrams group possible causes under headings such as people, process, technology and suppliers. Kepner–Tregoe problem analysis defines the problem precisely by contrasting what is affected with what is not, then tests candidate causes against those distinctions. Fault tree analysis works backward from an undesired event through logical combinations of causes. Timeline analysis reconstructs what changed and when.

The five whys is quick but has limits: it tends to produce a single chain when real failures usually have several contributing factors, and the answer depends on who asks the questions. Combining it with a fishbone diagram or a timeline helps uncover parallel causes.

Workarounds and the known error database

When a workaround is found, it should be documented, tested and published so the service desk and users can apply it without rediscovering it. Workarounds are stored with the known error, often in a known error database or within the knowledge base. A good workaround record describes the symptoms that identify the problem, the steps to apply the workaround, any side effects and when it was last verified. The service desk links new incidents to the known error, which both speeds resolution and counts how often the problem recurs.

Workarounds are valuable, but they have costs. Each application takes time, and a workaround that users find annoying hurts their experience. Some workarounds become permanent by default because nobody revisits them. Error control should periodically review workarounds and ask whether the accumulated cost now justifies a permanent fix.

Error control

Error control manages known errors. It assesses whether and how to remove the cause permanently, raises change requests for fixes, tracks those changes, and reviews workarounds. The decision to fix is economic and risk-based. A permanent fix has a cost: development effort, testing, a change with its own risk, perhaps a supplier upgrade. Not fixing also has a cost: continuing incidents, workaround effort and user frustration. Error control compares the two and recommends an action, which the service owner or a governance body decides.

Known errors in third-party products are managed through suppliers. Problem management raises the issue with the vendor, tracks the vendor's response, and maintains the workaround until a fix is released. Contracts and supplier management (covered in ITIL-141) determine how much leverage the organization has.

People, culture and ownership

Problem management fails most often for organizational reasons. Teams are busy with incidents and projects, so problems are recorded but never investigated. Nobody owns cross-team problems. Analysis is treated as a search for blame, so people are reluctant to share information. Fixes compete with feature work and lose. Successful organizations give problem management protected time, assign clear problem owners, review open problems regularly with service owners, track the age and impact of the problem backlog, and celebrate removed causes as visibly as heroic incident fixes.

Some organizations have dedicated problem managers who coordinate analysis and track the backlog; others distribute the work across technical teams with a coordinator. Both can work. The essential ingredients are that someone looks at the trends, someone decides which problems to tackle, and the people who can fix the causes are given time to do so.

Connections to other practices

Problem management draws on incident data from incident management and the service desk, monitoring data from monitoring and event management, configuration data from service configuration management and change history from change enablement. It sends workarounds to knowledge management and the service desk, and permanent fixes to change enablement, which assesses and authorizes them like any other change. It contributes to risk management, because known errors are risks, and to continual improvement, because removing causes is improvement. In DevOps teams, problem management often happens inside the same team that builds and runs the service, which shortens the loop from cause to fix.