Problem Management

Problem Management is the IT Service Management (ITSM) practice of identifying, analyzing, and managing the actual or potential causes of incidents so that organizations can reduce service disruptions, prevent recurrence, and limit business impact. It brings together incident evidence, technical investigation, risk-based prioritization, temporary workarounds, known-error information, and corrective action.

In ITIL terminology, a problem is a cause, or potential cause, of one or more incidents. This makes a problem different from the immediate interruption experienced by users. Incident Management seeks to restore acceptable service as quickly as practical; problem management seeks to understand and control underlying causes and the risk of future incidents. The two practices can work concurrently and share evidence, but their decisions and success criteria differ.

Problem management may be performed by a dedicated problem manager, service reliability team, technical specialists, or cross-functional service and engineering teams. It is relevant to internal IT services, managed services, enterprise applications, digital products, networks, infrastructure, and cloud platforms. The central management question is which underlying conditions deserve investigation or treatment, considering their probability, severity, cost, and the organization's ability to act.

Purpose and scope

The purpose of problem management is to reduce the likelihood and impact of incidents by addressing causes and managing the risks that remain. It also increases the usefulness of operational knowledge: when a permanent repair is delayed, a documented workaround can make recovery more reliable.

A mature practice addresses both individual high-consequence problems and patterns that emerge across many smaller incidents. It should not assume that every incident requires a separate in-depth investigation. Resources are better directed toward problems whose expected harm, recurrence, or business criticality justifies the effort.

Problem management commonly covers:

• Detection of recurring incidents, latent weaknesses, and potential failure conditions.
• Prioritization of problems according to risk and business exposure.
• Investigation of technical, procedural, organizational, and environmental contributors.
• Identification and validation of safe workarounds.
• Creation and maintenance of known-error records.
• Coordination of corrective changes and verification of their effect.
• Monitoring of unresolved problem risk and learning from outcomes.

Problem Management and Incident Management

Dimension	Incident Management	Problem Management
Primary objective	Restore disrupted service and reduce immediate impact	Reduce future incidents or their impact by understanding and controlling causes
Typical trigger	A service interruption or degradation	A major incident, recurring pattern, credible emerging risk, or unexplained failure
Immediate output	Restored service, communication, incident record	Investigative findings, known error, workaround, corrective-action decision
Time horizon	Immediate restoration and operational continuity	Near-term risk reduction and longer-term reliability
Closure basis	Agreed restoration or incident-resolution criteria	Problem risk treated or a documented decision to monitor, defer, or accept it

For example, restarting a failed application may restore service and close an incident. If the application repeatedly fails because of resource exhaustion, the problem remains until that condition is addressed or explicitly managed. Atlassian's ITSM guidance describes this relationship between restoring services and preventing recurrence.

Reactive and proactive Problem Management

Reactive problem management begins with incidents that have already occurred. A major outage, a repeated failure, or an unexplained service degradation prompts investigation. The incident record provides timelines, symptoms, affected systems, operational actions, and customer impact. The investigation looks beyond the immediate recovery action to contributing conditions.

Proactive problem management identifies risks before they produce a material incident. It may examine alert trends, error logs, capacity forecasts, near misses, component health, failed changes, security findings, and recurring support requests. The aim is to identify likely causes and intervene proportionately before they lead to disruption.

These approaches reinforce each other. Reactive investigation provides evidence that can sharpen preventive monitoring; proactive analysis can uncover the patterns behind incidents previously treated as unrelated.

Problem Management lifecycle

Organizations vary in their workflows and terminology. A practical lifecycle includes detection, assessment, investigation, risk treatment, verification, and knowledge maintenance.

Detection and registration

A problem may be identified through repeated incidents, a high-impact failure, a post-incident review, technical monitoring, or an engineering assessment. A problem record should identify the affected service, associated incidents, observed symptoms, provisional risk, responsible owner, and available evidence. At this stage the cause may still be unknown; an unverified hypothesis should not be recorded as an established root cause.

Prioritization

Problems are prioritized according to business impact, likelihood of recurrence, number and importance of affected users, security and compliance exposure, available workarounds, and cost or feasibility of investigation. A severe but rare failure can merit attention alongside a frequent lower-severity problem.

Priority should be revisited if new evidence reveals wider exposure, the affected service becomes more critical, or an existing workaround fails.

Investigation and diagnosis

Investigators reconstruct what happened, examine changes and dependencies, compare incidents, and test plausible causes. Evidence may include logs, monitoring data, configuration history, software defects, operator actions, capacity information, vendor notices, and service architecture.

Useful analytical techniques include causal timelines, the Five Whys, cause-and-effect diagrams, fault-tree analysis, and technical experiments. These tools organize reasoning; they do not guarantee a single definitive cause. Complex incidents may involve several interacting technical and organizational contributors. Investigations should distinguish observed facts, plausible mechanisms, confirmed causes, and remaining uncertainty.

Workaround and known-error management

A workaround reduces or avoids the impact of a problem or incident without necessarily removing its underlying cause. A verified configuration procedure, temporary routing change, or recovery sequence may be useful while permanent treatment is pending.

A known error is a problem that has been analyzed but remains unresolved. Known-error records commonly describe symptoms, affected services or versions, diagnostic evidence, available workarounds, operational risk, and the status of corrective action. They support faster incident resolution and prevent teams from repeating investigations. The ITIL Problem Management practice explicitly includes managing workarounds and known errors.

Workarounds require their own controls. A temporary step that weakens security, creates data integrity risk, or consumes excessive operating effort may be unacceptable even if it restores service quickly.

Corrective action and change coordination

Permanent remedies might involve repairing code, replacing a component, updating architecture, correcting configuration, modifying a procedure, expanding capacity, or changing a supplier arrangement. Technical teams should assess feasibility, dependencies, risks, and expected benefits before implementation.

When a proposed fix changes a controlled service, it is routed through Change Enablement or the organization's equivalent approval process. Problem management explains why treatment is warranted and follows its outcome; change governance authorizes and manages the implementation risk. Not all problems justify immediate permanent repair, especially where the intervention is more dangerous or costly than the controlled residual risk.

Verification, monitoring, and closure

After a correction is implemented, teams verify that the identified failure condition has been addressed and observe whether related incidents recur. Verification may include tests, telemetry, user outcomes, and a defined monitoring period.

Closure should document the evidence, action, outcome, remaining uncertainties, and treatment of any residual risk. Where a permanent fix is deferred, a problem may remain open or be closed under an explicit acceptance policy with a named risk owner; it should not disappear merely because the most recent incident is resolved.

Records and outputs

Record or output	Purpose
Problem record	Preserves ownership, scope, impact, related incidents, investigation, and status
Causal analysis	Documents facts, tested hypotheses, contributing factors, and uncertainty
Workaround instructions	Provides a safe, repeatable response while a problem remains
Known-error record	Makes analyzed but unresolved problems and relevant workarounds available to support teams
Corrective-action or change request	Connects proposed remediation to delivery ownership and change controls
Risk acceptance or deferral decision	Records why unresolved exposure is being tolerated and when it must be reviewed
Verification and learning record	Establishes the observed effect of treatment and lessons for future prevention

These records should link to relevant service components and incidents where reliable relationships can be established. The objective is traceability and usable knowledge, not a large inventory of loosely defined problem tickets.

Roles and governance

The problem manager coordinates prioritization, investigation, ownership, and communication. Service owners assess business impact and decide on service risk within their authority. Technical specialists and engineering teams test causes and design remedies. Incident managers and service desk staff contribute operational evidence and use workarounds during restoration. Change authorities evaluate changes under applicable controls. Risk and security leaders participate when exposures exceed ordinary operational authority.

Organizations do not necessarily require a separate problem management department. A smaller service team may combine roles, while a complex enterprise may create dedicated governance for critical infrastructure and recurring incidents. Atlassian notes that problem-management responsibilities may be assigned flexibly across problem managers, process owners, service owners, technical leads, and stakeholders.

A defined governance model should answer who can assign investigation effort, approve workaround use, authorize permanent changes, accept residual risk, and decide that a problem has been adequately treated.

Performance measurement

Problem management effectiveness is best assessed through risk reduction and service outcomes, supported by process measures rather than ticket volumes alone.

Measure	Interpretation	Caution
Recurring incident frequency	Whether incidents linked to a known cause become less frequent	Requires reliable incident-to-problem linkage and stable reporting scope
Business impact of recurrence	Downtime, users affected, transactions interrupted, or other service consequences	Changes in service demand can distort comparisons
Time to verified diagnosis	Time needed to establish actionable causal findings	Speed is not proof that the diagnosis is correct
Workaround effectiveness	Reliability and risk of temporary recovery measures	A workaround may shift risk elsewhere
Corrective-action completion	Progress of approved remedies	Completion does not prove that recurrence has been prevented
Known-error reuse	Whether support teams find and apply relevant knowledge	Reuse counts alone do not demonstrate quality
Residual problem risk	Severity and likelihood of significant unresolved conditions	Requires explicit review of assumptions and accepted risk

A shrinking problem backlog is not automatically evidence of improved reliability. Cases might have been closed without verification, merged incorrectly, or deferred. Similarly, a rising backlog may reflect better detection of previously invisible risks. Performance review should focus on material consequences and well-supported treatment outcomes.

Relationship to related ITSM practices

Incident Management focuses on service restoration. Knowledge Management ensures that diagnostic findings, workarounds, and known errors can be reused. Change Enablement controls the risk of implementing fixes. Monitoring and Event Management can reveal patterns and failure indicators. Configuration Management (CM) and service mapping help identify affected components and dependencies. Continual Improvement incorporates evidence from problems into broader service and process changes.

Problem management is also related to IT Risk Management, Site Reliability Engineering, and post-incident learning. These disciplines can share techniques and data, but their scopes and ownership rules are not identical.

Common challenges

Investigating every incident equally. An undifferentiated backlog can absorb resources while significant recurring risks remain untreated.

Confusing restoration with prevention. A closed incident or a successful restart may conceal the original failure condition.

Premature root-cause declarations. A plausible technical explanation may be treated as proven before counter-evidence, interactions, or process weaknesses are considered.

Workarounds becoming permanent by default. Temporary controls can remain in place without review, increasing complexity and operational risk.

Weak cross-team ownership. Problems spanning application, network, cloud, vendor, and business teams can stall when no one coordinates the full investigation.

Fixes introduced without change controls. A technically reasonable remedy may cause wider disruption if it bypasses testing, approvals, and deployment safeguards.

Measuring activity rather than outcomes. More problem records, investigations, or completed changes do not necessarily mean fewer serious incidents.

Illustrative example

Consider a hypothetical online order-processing service that experiences several brief outages during peak traffic. Incident responders restore service each time by restarting a processing component. A problem review groups the incidents, examines utilization and deployment records, and identifies a resource leak that worsens under sustained load.

The service team publishes an approved workaround and a known-error record, allowing faster recovery while engineers test a software correction. The fix is deployed through change controls, and the organization monitors error rates and service interruptions during comparable demand periods. The problem is considered treated when verification supports the conclusion that the underlying condition has been addressed, with any remaining risk documented.

The example shows the difference between ending the current outage and reducing the risk of the next one.

See also

• Incident Management
• IT Service Management (ITSM)
• Change Enablement
• Knowledge Management
• Continual Improvement
• IT Risk Management
• Site Reliability Engineering
• Monitoring and Event Management