Academy / Chapter 01 / Foundations
Understand the work.Then investigate.
Problem management is not a longer incident ticket. Its job is to reduce the likelihood and impact of future disruption by understanding the causes and managing risk while resolution is still underway.
START WITH PRECISION_
Four terms that should not be confused.
Incident
An unplanned interruption or reduction in service quality. The immediate concern is safe restoration.
WHAT HAPPENEDProblem
A cause, or potential cause, of one or more incidents. The focus is understanding and reducing recurring risk—not necessarily repairing the current interruption.
WHY IT MAY RECURWorkaround
A way to reduce or eliminate impact before a full resolution exists. It may be valuable without correcting the underlying cause.
LESS HARM NOWKnown error
A problem that has been analysed but is not yet resolved. A documented workaround may accompany the record.
KNOWLEDGE TO REUSEA payment service fails every afternoon: the failed transactions are incidents. A competing report job exhausting connection capacity may be the problem. Scheduling the report later is a workaround; a verified capacity or concurrency correction may be the durable fix.
This is a simplified educational summary of commonly used IT service-management terminology; use the definitions and processes adopted in your organization. The PeopleCert practice description emphasizes preventing incidents and managing workarounds and known errors.
HOW AN INVESTIGATION MOVES_
A practical problem management lifecycle.
Cluster recurring incidents, high-impact failures, supplier signals or plausible future risks.
State expected versus observed behaviour, scope, impact and what is still unknown.
Choose a method; separate evidence, hypotheses and findings. Revisit contradictory data.
Document a safe workaround, its limitations, the owner and a trigger for reassessment.
Evaluate the chosen correction through the appropriate change, risk and release processes.
Compare results against a baseline, observe long enough, and retain reusable knowledge.
These six learning moves are our teaching structure, not an official six-step ITIL process. Many organizations group their work under problem identification, problem control and error control.
QUALITY OF THE RECORD_
A problem brief worth handing to another team.
| Field | Good content | Common failure |
|---|---|---|
| Observed deviation | Checkout errors rise from below 0.2% to 8% between 14:00 and 14:08 UTC. | “Checkout is unreliable.” |
| Scope | Production region A, weekdays, affected endpoint and time window. | “All customers seem affected.” |
| Evidence | Timestamped request logs, connection metrics, deployment changes and replay tests. | “The team thinks the database is slow.” |
| Hypotheses | Connection contention, application retry storm, network latency—each with a falsifiable test. | Only one favored explanation. |
| Workaround | Stagger report job; owner, risk and rollback trigger documented. | Temporary fix confused with root cause. |
| Verification | Error rate, peak concurrency and recurrence tracked for 14 comparable business days. | “Closed because it did not fail today.” |
EVIDENCE OVER CERTAINTY_
Three evidence labels to keep separate.
Observed fact
Something measured, logged or directly witnessed with context and provenance.
Example: 29 database sessions waited on a specific lock.
Inference
An interpretation supported by several facts; confidence should be proportional to the support.
Example: The scheduled report likely created the contention.
Unverified hypothesis
A plausible explanation awaiting a discriminating test, not a conclusion.
Example: A new query plan may have lengthened the lock.
What observation would make this explanation less likely? A method that only collects confirming examples is not a reliable investigation.
CONTROL IS NOT PROOF_
Design the verification before closing.
- Baseline: how often did the event recur and how severe was it before the change?
- Expected result: specify which observable measure should improve and the threshold that matters.
- Observation window: cover the normal recurrence cycle, including peak periods.
- Confounders: record seasonal load, traffic shifts and simultaneous changes that might also explain improvement.
- Ownership: name who reviews recurrence, workaround relevance and future signals.
- Reusable learning: capture symptoms, supporting evidence, tested explanations and any remaining risks.
What should teams measure?
Review recurrence rate, time from detection to an actionable hypothesis, time to a safe workaround, confirmed reduction in impact and effectiveness of implemented controls. Avoid rewarding “number of problems closed” without checking whether they stayed closed.
PRACTICE POINT_
Connect incident and problem work without confusing them.
During a live incident, restore safe service first. A problem investigation may begin in parallel when the risk justifies it, but should not delay urgent recovery. Afterwards, carry forward the incident chronology, impact, observed behavior, changed conditions and unresolved questions—not a preselected culprit.
Use the evidence and question type to select an appropriate method.
Reference
- PeopleCert — ITIL 4 Practitioner: Problem Management. This page is an independent interpretation, not an official syllabus.