The Myth of Proactive Problem Management – Part 1

Aesop’s fable of the fox and the grapes is a familiar story. We work hard to get toward a goal, […]

Category: Article

Aesop’s fable of the fox and the grapes is a familiar story. We work hard to get toward a goal, but it always seems out of reach. In the end, we are frustrated and disillusioned – maybe the goal wasn’t that appealing, after all.

As we roll out new service delivery practices, sometimes the result is different from what we expected. We get results for our hard labor, but the outcome isn’t as appealing as we thought. My daughter ordered a milkshake (or frappe) at her favorite hamburger spot a few weeks ago, a milkshake that contained bits of cake (king cake to be exact, a cinnamon-flavored cake that is traditionally served during carnival season). It sounded so appealing to her, but ended up tasting awful (I can confirm it was disgusting!).

Problem management seems a bit like this milkshake to me. What drew me to problem management as an ITIL® practice was how it lifted my support organizations out of the trees of incident management and service request fulfillment. Problem management holds out a hope that the support organization can be proactive. We mine the incident management system (or CRM, depending on your language) for patterns that uncover known errors and close the loop by transforming the errors into solvable problems (by network engineering, development, systems administration, etc.).

But it isn’t proactive. There are two reasons why problem management on its own isn’t satisfying. The first is that it is always looking backwards. We can’t do problem management without incidents, so we are waiting for known errors to emerge (maybe daily or weekly, perhaps as infrequently as monthly). Even though the value of problem management is high – it addresses business needs of numerous customers/end-users, not just the one – the time to value is longer than it should be. The second reason is that the patterns that emerge are patterns of incidents. The level of specificity isn’t the customer/end-user or even the specific service. Problem management takes us up one level of abstraction, but not as high as we need to be proactive. We aren’t just seeing trees, we are seeing groups of them, but, at the same time, we haven’t seen the forest, yet.

There is hope for problem management, though, to be proactive. We can do it by marrying problem management with knowledge management/knowledge sharing practices. Over the next several weeks, my colleague Bill Stockton and I will be outlining how knowledge management/knowledge sharing can transform problem management.

In the next installment, we’ll cover using knowledge as the critical data source for problem management. We will talk about the limitations of the incident system as a way to uncover trends and how the knowledge repository can be set up to provide much more value, much more quickly.

Adam’s colleague Bill Stockton is co-author of this series.

Recent Posts

Quick Links

Refund Reason