How do we implement an effective Problem Management process that isn't just "Incident Management 2.0"?

All answers to this question.

The key is to separate the "Urgency" of Incident Management from the "Investigation" of Problem Management. You need a trigger—for example, any incident that happens three times in a month automatically creates a Problem record. Don't assign this to the person on the front lines; assign it to a "Problem Analyst" or a senior engineer who has the time to perform a "5 Whys" or a Fishbone analysis. The goal isn't a quick fix; it's a "Known Error" record or a change request that permanently removes the issue. By spending time on the root cause now, you are actually "buying back" hundreds of hours of future service desk capacity.

   Answered 2025-07-10 by Kimberly Adams

Kimberly, how do you convince management to let a senior engineer spend four hours "investigating" a problem when there's a queue of 50 active incidents waiting to be solved?

   Answered 2025-07-15 by Brian Collins

• Brian, you show them the math of "Trend Analysis." If that one problem causes 10 incidents a week, and each incident takes 30 minutes to "fix" superficially, you are losing 5 hours a week, every week, forever. Spending 4 hours once to kill the root cause gives you a 100% ROI in less than a month. When management sees the long-term labor savings and the reduction in user frustration, they usually become the biggest advocates for dedicated Problem Management time.

     Commented 2025-07-20 by Matthew Perry

Use the "Pareto Principle." 80% of your service desk's pain usually comes from 20% of the underlying problems. If you can just fix the top 3 problems, your ticket volume will plummet.

   Answered 2025-07-25 by Sarah Miller

• The 80/20 rule is so true in ITSM. Focusing your limited resources on the "vital few" problems is the only way to get ahead of the constant fire-fighting.

     Commented 2025-07-30 by Ryan Reynolds