Problem Management for Permanent Improvement
ESMi Knowledge Team
· 3 min read
In brief
Problem management delivers permanent improvement by reducing the likelihood and impact of incidents. It does this by identifying underlying causes, managing known errors and workarounds, and driving preventive change, with the persistence to look beyond the first plausible explanation.
- Select problems using impact and recurrence. Not every incident needs a problem record; opening a problem for every incident is a named pitfall. In the article's example, recurring login failures become a prioritised problem because their aggregate lost time exceeds the impact of several higher-profile incidents.
- Investigate causes systematically. Stopping at the first plausible cause is a common mistake. Make assumptions explicit and identify early warning signals.
- Document known errors and workarounds. Recording known errors and their workarounds is part of the practice, and known-error use is one of the measures worth tracking.
- Track corrective action to benefit. A problem should not be closed simply because a change has been raised. Measure repeat incident reduction and corrective action effectiveness to confirm the fix delivered real benefit. Begin by baselining repeat incident reduction and agreeing who can act if the result moves in the wrong direction, then review results with delivery teams and affected consumers.
Continue reading on the Exchange
Join or sign in to read the complete article and explore the full knowledge library.
Founder membership is free for life
More from ESMi Knowledge Team
Available to members.
Related articles
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.
Members
Identifying Single Points of Failure
Single-point-of-failure analysis reveals components, roles, information or suppliers whose loss can break a service without a viable alternative.
