Problem Management Checklist Template

What the Problem Management Checklist Covers

1. 1
   Phase 1

   Phase 1: Identify & Log the Problem

   5 tasks

   ITIL 4 problem identification is both reactive and proactive. Record the source: a trend needs different evidence from a major incident.

   • Record how the problem was found — trend analysis, a major incident, a pattern the service desk spotted, or a notice from a supplier or developer
   • Link every related incident record — search the last 90 days for the same configuration item, symptom or error text; the count is your evidence for priority
   • Check the known error database first — if the cause is already recorded, link the new incidents to that record instead of opening a duplicate
   • Write a problem statement that describes the fault, not a guess at the cause — “payroll export fails between 01:00 and 02:00 on the first working day”, not “database issue”
   • Name the affected services and configuration items — from the CMDB or service catalogue, so the investigation starts from the right components
2. 2
   Phase 2

   Phase 2: Prioritise & Assign

   5 tasks

   • Set priority from impact and likelihood of recurrence — ten minor incidents a week on a payment service can outrank one noisy outage on an internal wiki
   • Assign a problem owner and investigators — one owner accountable for the record, with engineers from each team that runs an affected component
   • Set a target date for a confirmed root cause — driven by priority, with a review date if the target is missed rather than a silent slip
   • Decide whether the service desk needs an interim workaround now — if incidents are still arriving, first line needs something to apply before the cause is known
   • Tell the service desk the problem is open — new incidents with the same signature get linked to the record instead of being worked from scratch
3. 3
   Phase 3

   Phase 3: Investigate & Find the Root Cause

   6 tasks

   • Build a timeline of occurrences and changes — every linked incident alongside deployments, patches, configuration changes and capacity events in the same window
   • Specify the problem as IS and IS NOT — which servers, times, users and transactions are affected, and which comparable ones are not; the differences point at the cause
   • Map candidate causes on an Ishikawa diagram — group them under people, process, technology, suppliers and environment so no category is skipped
   • Drill each plausible cause with 5 Whys — stop at a condition the organisation can change, never at a person
   • Test the most likely cause against the evidence — a true cause explains every IS and every IS NOT; reproduce it in a test environment where you can
   • Record the root cause, the evidence and the method used — attach the diagram, log extracts and test results to the task
4. 4
   Phase 4

   Phase 4: Known Error & Workaround

   5 tasks

   Tasks 2–4 appear only when the record answers Yes to “Is a workaround available?”. Task 5 appears only when it answers No.

   • Record the problem as a known error — the cause is analysed and the fix is not yet in place, so the record changes status and stays open
   • Document the workaround step by step — written so a first-line analyst can apply it without escalating to the team that found it
   • Publish the workaround to the service desk knowledge base — linked to the known error, so incidents can cite it and be resolved faster
   • Measure how well the workaround works — time to apply, and whether incidents that use it still escalate to second line
   • Record the business impact of having no workaround — it raises the priority of the permanent fix in Phase 5
5. 5
   Phase 5

   Phase 5: Error Control & the Permanent Fix

   6 tasks

   The “Permanent fix route” answer controls this phase. Tasks 2–4 appear for “Change required”, task 5 for “No change needed” and task 6 for “Accept the known error”.

   • Compare the options for a permanent fix — cost, risk and time to deliver, set against the cost of living with the workaround
   • Raise a request for change for the fix — the problem record is the justification, and the change follows your normal approval route
   • Attach the root cause evidence to the change — so the change authority can weigh the risk of fixing against the risk of waiting
   • Track the change through to implementation — the problem stays open until the change is deployed, not when it is approved
   • Apply and document a fix that needs no change — such as a corrected knowledge article or a revised operating procedure
   • Record the decision to accept the known error — who accepted the risk, why, and the date it will be reassessed
6. 6
   Phase 6

   Phase 6: Verify & Close

   5 tasks

   • Watch for recurrence over an agreed period — for example 30 days, or through the next month-end run for a cyclical fault
   • Confirm the fix with the service owner — the people who raised the incidents agree the symptom has gone
   • Close the known error and retire its workaround article — a stale workaround sends future analysts down the wrong path
   • Record what made the cause hard to find — missing logs, weak monitoring or unclear ownership become improvement actions
   • Close the problem record with owner sign-off — the linked incidents, root cause and change stay attached as the audit trail
7. 7
   Phase 7 — Monthly Review Only

   Phase 7: Monthly Problem Review

   6 tasks

   Shown only when the checklist is started as the monthly review. Phases 1–6 are hidden for that run, and a recurring schedule starts it on the first working day of the month.

   • Run trend analysis on last month’s incidents — group by configuration item, category and error text; any cluster above your threshold becomes a candidate problem
   • Check every major incident from the month — each one whose review left the cause unconfirmed should have a problem record
   • Reassess every open known error — current impact, the cost of a permanent fix and how well the workaround is holding up
   • Chase problems past their root cause target date — agree a new date with the owner or escalate to the service owner
   • Review supplier notices and published defects — known bugs in products you run are problems you can log before they cause an incident
   • Report the problem KPIs — open problems by age, incidents linked to known errors, and problems closed with a verified fix