Problem management that prevents incidents
· 1 min read
In brief
Problem management prevents incidents by reducing their number and impact through two complementary halves: reactive work, which investigates incidents that have already occurred, and proactive work, which hunts for risks before they cause disruption. According to John Sansbury, the difference between good problem management and good intentions is disciplined follow-through.
- Reactive problem management is well understood. When an incident recurs, a problem record is raised, the root cause is found, and a known error with a workaround is documented while a permanent fix is scheduled.
- Proactive problem management is where value compounds, and it is where most teams fall short. It means mining incident data for patterns, so that risks are found before they bite.
- Proactive work also means reviewing changes for fragility and treating near-misses as free lessons, learning from events that did not cause an incident.
- Follow-through separates good problem management from good intentions. A known error database only pays off if it is consulted, maintained and trusted by the people on the front line, so the database must be kept current and credible for those who rely on it.
Continue reading on the Exchange
Join or sign in to read the complete article, explore the full knowledge library and record your CPD.
Founder membership is free for life
More from John Sansbury
Available to members.
Related articles
Members
Problem Management for Permanent Improvement
Problem management reduces the likelihood and impact of incidents by identifying causes, managing known errors and driving preventive change.
Members
When an Incident Should Become a Problem Record
A problem record is justified when deeper investigation or coordinated prevention is needed beyond restoring one incident.
Members
Managing Known Errors and Workarounds
A known error record converts learning into faster restoration and controlled risk until a permanent resolution is delivered.
Members
Using Five Whys Without Oversimplifying Causes
Five Whys is a prompt for deeper causal inquiry, not proof that a complex failure has one linear root cause.
Members
Using Pareto Analysis to Focus Improvement
Pareto analysis helps teams concentrate on the categories that contribute most to impact, while preserving awareness of rare high-risk events.
Members
Building an Ishikawa Diagram for Complex Problems
A fishbone diagram broadens investigation across people, process, technology, information, environment and suppliers before hypotheses are tested.
