Incident management restores service. Problem management removes the reason it failed, and in many IT teams it exists on the org chart but not in the working week. This free problem management checklist follows the three phases of the ITIL 4 practice: problem identification, problem control and error control. It is for service desk managers, problem managers, infrastructure leads and managed service providers who need problem records to reach “fixed and verified”. Each run produces a problem statement backed by linked incidents, a root cause with the evidence and method attached, a known error record and workaround where one exists, a change request for the permanent fix, and a closure check that proves the incidents stopped. A separate monthly run handles trend analysis and the review of every open known error.
ITIL 4 defines a problem as a cause, or potential cause, of one or more incidents. The purpose of the practice is to reduce both the likelihood and the impact of incidents by finding those causes and by managing workarounds and known errors. A known error is a problem that has been analysed but not yet resolved. A workaround is anything that reduces or removes the impact of an incident or problem while a full resolution is not yet available. Keeping them separate matters: the service desk needs the workaround today, the change authority needs the root cause evidence next week, and the problem owner needs to see which known errors have waited longest.
The practice also works at a different scale from a single incident review. An incident postmortem looks back at one outage in depth and produces actions for that event. Problem management looks across many incidents, including small ones nobody would write a postmortem for, and asks what they share. A postmortem often opens a problem record, and the investigation carries on there after the meeting ends.
Starts from: a single SEV-1 or SEV-2, or any event that meets the review criteria.
Question: what happened, and what should we change after this outage?
Timescale: days, while memories and logs are fresh.
Output: a written review and a list of owned actions.
Starts from: trend analysis, a recurring ticket pattern, a major incident with no confirmed cause, or a supplier notice.
Question: why does this keep happening, and what would stop it for good?
Timescale: weeks, sometimes longer if the fix needs a release or a hardware change.
Output: a root cause, a known error and workaround, and a change that removes the cause.
Six phases take each problem from identification to verified closure. Answers on the record decide which workaround and fix tasks appear. A seventh phase runs on its own as the monthly problem review.
ITIL 4 problem identification is both reactive and proactive. Record the source: a trend needs different evidence from a major incident.
Tasks 2–4 appear only when the record answers Yes to “Is a workaround available?”. Task 5 appears only when it answers No.
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”.
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.
A repeatable fault on one component rarely needs more than a timeline and 5 Whys. An intermittent fault that affects some servers and not others is where a structured comparison earns its time. Phase 3 asks the investigator to record which method was used, so the monthly review can see which approaches actually produce confirmed causes.
| Technique | Best for | Watch out for | Attach to the record |
|---|---|---|---|
| Timeline and change correlation | Any problem; always the first step | Changes made outside the change process never appear in the log | Timeline with incident and change references |
| 5 Whys | Single-path faults with a clear chain of events | Stopping at “human error”, or following one chain when several causes combined | The question chain, with evidence for each answer |
| Ishikawa (fishbone) diagram | Group sessions where many causes are plausible | A long list of possibilities with nothing tested | The diagram, with each cause marked tested or ruled out |
| Kepner-Tregoe problem analysis | Intermittent faults that affect some systems, times or users and not others | Thin IS NOT data, which leaves no distinctions to work from | The IS / IS NOT specification, distinctions, changes and the cause tested against both columns |
Trend analysis is the first thing dropped in a busy month. A recurring schedule starts the monthly review on the first working day and assigns it to the problem manager, so a skipped month shows as an overdue checklist.
Answer whether a workaround exists and how the fix will be delivered, and conditional logic shows only the tasks that apply. Linked incident counts, root cause method and target dates are captured as form fields, and the fishbone diagram and log extracts are attached as evidence.
A dynamic due date sets the reassessment date when a known error is accepted, and the monthly review brings every open one back in front of an owner. The activity trail shows who accepted each risk, who approved each fix and when the problem was verified closed.
Most permanent fixes reach production as a change. CheckFlow’s change management checklist software shows how the request, approval and implementation run with the same evidence trail, and the IT Change Management Checklist is the template to raise from Phase 5.
Problem management starts where live response stops. The Incident Management Checklist restores service and checks the known error database before anyone starts diagnosing, which is where this template’s workarounds pay off.
It is the ITIL 4 practice that reduces the likelihood and impact of incidents by finding their actual and potential causes and managing workarounds and known errors. It has three phases. Problem identification finds and logs problems, from incident trends, major incidents, recurring tickets and supplier information. Problem control analyses the problem and documents workarounds and known errors. Error control manages known errors through to a permanent fix, usually by raising a change.
A problem is the cause, or potential cause, of one or more incidents, and it may not be understood when it is first logged. A known error is a problem that has been analysed but not yet resolved. The record usually gains a documented workaround at that point, and stays a known error until the permanent fix is verified or the organisation formally accepts it.
Incident management restores normal service as quickly as possible, and a restart or a workaround is a perfectly good incident resolution. Problem management asks why the incident happened and removes the cause so it does not happen again. The two are linked: incidents feed problem records, and the known errors and workarounds that problem management publishes help the service desk resolve future incidents faster.
Open one when the same symptom or configuration item keeps generating incidents, when a major incident was resolved without a confirmed cause, when trend analysis shows a cluster above your agreed threshold, or when a supplier publishes a defect in something you run. Set the threshold in advance, for example three incidents on one component in 30 days, so nobody has to notice the pattern by chance.
Reactive problem management starts from incidents that have already happened. Proactive problem management looks for causes before they produce one: trend analysis of incident records, monitoring data, and known defects reported by suppliers, developers and test teams. In this template that work lives in the scheduled monthly review.
The most common are 5 Whys, Ishikawa (fishbone) diagrams and Kepner-Tregoe problem analysis, which compares what the problem IS with what it IS NOT to isolate the cause. Most investigations also start from a timeline of incidents and changes. The test at the end is the same for all of them: a confirmed root cause explains every occurrence, and removing it stops the incidents.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
