ITIL 4 Problem Mgmt key terms

A cause, or potential cause, of one or more incidents. It may be identified before any incident occurs or discovered by analysing incidents that have already happened.

The practice of reducing the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors.

An unplanned interruption to a service or reduction in the quality of a service. Incidents are the main input for reactive problem identification and the main measure of problem management success.

A problem that has been analysed but not yet resolved. It is documented with its root cause and a workaround so that support staff can handle related incidents consistently.

A temporary solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. It restores service without removing the underlying cause.

The underlying reason why a problem exists, identified through analysis. Removing the root cause prevents recurrence, unlike a workaround that only masks the symptoms.

Problem management activity triggered after incidents have occurred, typically by analysing incident records and trends to find causes of recurring or high-impact failures.

Problem management activity initiated before incidents occur, using trend analysis, testing, and risk review of services and components to identify and remove potential causes of failure.

The activity of detecting a cause or potential cause of incidents, using sources such as incident records, monitoring, supplier reports, and trend analysis, and deciding whether it warrants problem management effort.

The activity of recording a problem as a problem record, capturing description, affected services, symptoms, priority, and ownership so that work can be tracked and reported.

The documented entry holding all details of a problem throughout its lifecycle, including symptoms, affected configuration items, analysis findings, workaround, status, and history of actions taken.

Assigning a problem to defined categories and subcategories, usually aligned with the incident and configuration taxonomies, to support routing, reporting, and pattern detection.

Deciding the order in which problems are worked on, based on impact, urgency, risk, cost, and the number or severity of related incidents, so limited resources target the greatest value.

The measure of the effect of an incident or problem on business processes, services, or users. It is usually assessed by scope, number of people affected, and criticality of the affected service.

The measure of how quickly an incident or problem needs attention, reflecting business delay costs and contractual commitments. Impact and urgency together usually determine priority.

The activity of investigating a problem to establish its root cause, using techniques such as the five whys, Ishikawa diagrams, Kepner-Tregoe analysis, and comparison of failed and working components.

The activity of implementing a change that removes the root cause, verifying the fix, closing the problem record, and updating the known error record and related documentation.

The activity of managing known errors through their lifecycle, including recording, assessing, and periodically reviewing them, and deciding whether to fix, accept, or retire each one.

A documented entry for a known error, holding the root cause, symptoms, workaround, affected configuration items, and status, so support staff can resolve related incidents quickly.

A problem with significant business impact or urgency, often linked to a major incident, requiring senior management attention, dedicated resources, and structured communication to stakeholders.

An incident with significant business impact that requires an urgent response, often using a separate procedure. It is a common trigger for raising a problem record.

Formally ending problem management work on a record after resolution or acceptance, confirming the fix is verified, records are updated, and lessons and documentation changes are captured.

The role accountable for the problem management practice, including its process design, records quality, prioritization decisions, reporting, and coordination of analysis and resolution work across teams.

The person assigned accountability for a specific problem record, responsible for driving its analysis and resolution, coordinating contributors, and keeping the record and stakeholders updated.

A person or team with the specialist knowledge and decision rights needed to investigate and resolve a problem in a particular technology domain, often drawn from support or engineering groups.

A cross-functional team accountable for end-to-end service delivery and support. In ITIL 4 it typically owns problems affecting its services and integrates problem work with incident and change activities.

A series of steps an organization uses to create and deliver products and services to consumers. Problem management activities should be mapped into relevant value streams rather than run as an isolated process.

The ITIL 4 model of six connected activities, plan, improve, engage, design and transition, obtain or build, and deliver and support, through which value is created; problem work spans several of them.

A responsibility assignment model showing who is responsible, accountable, consulted, and informed for activities or decisions, used to clarify problem management roles across teams.

A simple causal analysis technique that repeatedly asks why a failure occurred, typically about five times, to move from symptoms to an underlying root cause.

A cause-and-effect diagram, also called a fishbone diagram, that groups possible causes of a problem into categories such as people, process, technology, and environment to structure brainstorming.

A structured technique that defines a problem by what, where, when, and how much, then compares it with similar situations that work, to narrow down and test likely causes.

Examining incident and monitoring data over time to detect recurring patterns, rising failure rates, or emerging risks that indicate a problem or potential problem worth investigating.

A group technique for generating a broad set of possible causes or solutions without early judgement, usually followed by prioritization or testing to select the most probable cause.

The practice of ensuring risks are assessed and changes are authorized and scheduled. Problem resolution usually requires a change, so the two practices must coordinate closely.

The practice of maintaining accurate information about configuration items and their relationships. This information helps problem analysis understand dependencies and assess the impact of fixes.

The practice of aligning practices and services with changing business needs through ongoing improvement. Problem management feeds it with recurring causes and lessons learned.

The practice of maintaining and sharing information and knowledge. Known error records and workarounds should be published here so support staff and users can reuse them.