ITIL 4 Problem Mgmt cheat sheet

Problem management is the practice of reducing the likelihood and impact of incidents by identifying actual and potential causes of incidents and managing workarounds and known errors.

A problem is a cause, or potential cause, of one or more incidents; an incident is an unplanned interruption or reduction in quality of a service.

A known error is a problem that has been analysed but not resolved; it always has a documented root cause or a documented workaround.

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.

ITIL 4 places problem management in the service value chain activities 'improve' and 'engage', with most activity in 'design and transition' and 'deliver and support'.

Reactive problem management is triggered by incidents already occurring; proactive problem management identifies potential causes before incidents occur, often from trend analysis.

Problem management differs from incident management in objective: incident management restores service quickly, problem management removes the underlying cause to prevent recurrence.

The three-phase problem-solving approach in ITIL 4 is: problem identification, problem control, and error control.

Problem management contributes to the 'optimize' and 'ensure' value chain activities by reducing cost of repeated incidents and improving availability.

Problem identification sources include incident records, major incident reviews, monitoring and event data, capacity and availability trends, supplier and third-party reports, and customer feedback.

Problem control activities: problem analysis, documenting workarounds, and raising known errors when root cause is found but a permanent fix is not yet available.

Error control activities: managing known errors, assessing and prioritising the need for a permanent fix, and re-evaluating known errors when circumstances change.

Problem prioritisation typically considers impact (business and user), urgency, frequency of recurrence, and the severity of associated incidents.

Root cause analysis techniques include 5 Whys, Ishikawa (fishbone) diagrams, Kepner-Tregoe problem analysis, fault tree analysis, and Pareto analysis.

A problem record lifecycle commonly moves through identification, logging, categorisation, prioritisation, investigation and diagnosis, workaround, known error, resolution, and closure.

Closure requires confirming the permanent fix is implemented and effective, updating the known error record, and checking that related incidents have stopped recurring.

Major problem reviews examine what happened, why, how the response performed, and what actions will prevent recurrence; outputs feed continual improvement.

Problem management interfaces with change enablement (permanent fixes as changes), knowledge management (workarounds and known errors), and supplier management (third-party causes).

A problem management practice owner is accountable for the practice's effectiveness and for its continual improvement across the organisation.

Problem managers coordinate the practice, own the problem records process, and ensure problems are prioritised and progressed; they may not perform all analysis themselves.

Technical and specialist teams (subject matter experts) perform root cause analysis and develop workarounds and fixes, often in a matrix or product-team structure.

Incident managers and major incident managers interface with problem management by escalating recurring or unresolved incidents and by requesting workarounds.

Service owners are accountable for the services affected and approve prioritisation and resourcing decisions for permanent fixes.

Change enablement roles authorise the changes that implement permanent fixes; problem management does not approve its own fixes.

Knowledge management roles ensure workarounds and known errors are captured, validated, and made available to service desk and support staff.

In ITIL 4's product-and-service-team model, problem management activities are distributed across teams rather than centralised in a single function, coordinated by the practice owner.

Suppliers and partners may hold problem management responsibilities defined in contracts and service level agreements; shared accountability must be explicit.

The 5 Whys technique repeatedly asks 'why' to drill from symptom to root cause; it is simple but can miss multiple contributing causes if used alone.

Ishikawa (fishbone) diagrams group possible causes into categories such as people, process, technology, data, and environment to structure brainstorming.

Kepner-Tregoe problem analysis distinguishes 'musts' from 'wants' and uses is/is-not comparison to narrow the fault domain.

Fault tree analysis works top-down from an undesired event using AND/OR logic gates to identify combinations of causes.

Pareto analysis applies the 80/20 principle to incident and problem data to focus effort on the few causes producing most impact.

Trend analysis on incident and monitoring data supports proactive problem management by detecting recurring patterns before formal incidents escalate.

Problem management tools typically include a known error database (KEDB), CMDB and asset data, monitoring and event tools, and knowledge management systems.

Automation and AIOps can correlate events and incidents to suggest candidate problems and known errors, but human validation of root cause remains required.

Metrics for problem management include number of problems resolved, percentage of incidents linked to problems, known error database coverage, and reduction in repeat incidents.