Problem Management Isn’t Just for Incidents

Problem Management

What is a “problem”? If your IT service management (ITSM) mindset is influenced by ITIL, the quick response to that will either be “A cause of one or more incidents” (ITIL v3) or “A cause, or potential cause, of one or more incidents” (ITIL 4). But for me, such definitions have always fallen rather short of the mark… and the inherent potential of problem management.

What is a 'problem'? If your mindset is influenced by ITIL, you might be missing out on the inherent potential of problem management, says Michael Keeling #ITSM #ITIL Share on X

Defining a problem

I maintain that a problem is, by any other name, a problem. Defect, vulnerability, risk, flaw, back door – term it however you like, it represents something that introduces a potential or exploitable weakness that could result in negative effect if not mitigated. Although most might not consider applying problem management outside of a direct link to incident management, I’ve always maintained that the only necessity is the fact that someone has recognized the need to investigate something they suspect is “a bad thing”…and a willingness to identify and mitigate it before it actually causes negative effect.

Having the right problem management mindset

If you really want your organization to get the most value out of problem management, the mindset I’d like you to consider is that problem management should be practiced no matter where or when negative potential can be introduced. Getting people to understand that problem management principles apply for the ‘end-to-end’ of virtually anything will be a challenge in many if not most, organizations. But whether you’re part of a workflow, business process, concept-to-product cycle, design workshop, manufacturing operation, or whatever, I submit that everyone at every stage of every activity should have a mindset that includes keeping an eye out for any potential problems, and investigating any they believe have an opportunity of being present. Most organizations don’t do this – which is a large factor in why you end up hearing or reading about them in the news when problems that could (should) have been noticed and mitigated at a far earlier point cause something to go boom.

If you really want your org to get the most value out of problem mgmt, the mindset I’d like you to consider is that problem management should be practiced no matter where or when negative potential can be introduced – Michael Keeling… Share on X

Problem management and “end-to-end”

When I say end-to-end (in terms of problem management), I literally mean that. For example: One day at lunch someone draws a quick outline for a new widget on a napkin, and it shows ‘use part 345a here’. They hand the drawing to the engineer they’re having lunch with, who looks at it and says, “If you use part 345a the widget will catastrophically fail when you turn it on. You need to use part 789b instead. Are you gonna eat those fries?”

What happened? Well, the engineer performed proactive problem management is what happened…and he did it at the “napkin” stage before anything was really anything. By doing so, he assessed and mitigated a potential cause of negative effect that might otherwise not have presented itself until the widget was developed and marketed to a customer who then flipped the “ON” switch and caused an “incident” – long after many opportunities to identify the problem that was introduced at the very birth of the idea.

Note that while my very basic problem management example named an engineer as the “discoverer”, in another scenario they could easily have been a developer…or an accountant, or a nurse, or a mechanic, a line worker, a guy on the shipping dock, or Joe the Janitor. Who they are or what they do shouldn’t matter; all that should matter is whether they notice something that might hold latent potential to cause something negative – and they’re empowered to act on what they notice.

Testing alone is not enough

By this point I’m sure a few of you are proudly declaring, “Well my organization does plenty of testing all the time to discover problems before they cause incidents!” To which I’d reply, “That’s great! You should do that! But…”. The ‘but’ would be that formal testing still misses things – recalls, patches, etc. provide plenty of proof for that. Even providers like Toyota, Microsoft, etc. that are famous for testing methods and capabilities still miss things. Testing alone is never enough; if it was, you wouldn’t hear about recalls for products, or vulnerabilities in software being exploited, or stories of financial losses, or of people being injured or worse when something happened that could have been prevented. By actively encouraging everyone in your business to apply the concepts of problem management throughout all that your business does, keeping an eye out for trouble before it becomes trouble, you greatly increase the value of the practice, and the number of problems that can be discovered and addressed before they ever cause an issue.

Don’t let the traditional definition you might have been taught a ‘problem’ is constrain you or your business. Don’t think that problem management is only useful in certain areas. This blog by Michael Keeling explains why. #ITSM #ITIL Share on X

Widening the remit for problem management

What I’m proposing here for problem management isn’t something anyone should find odd; in fact, I submit it’s odd that all organizations don’t do this, because people do it all the time. It’s a basic instinct to want to avoid trouble (though for most of us it’s quite less honed than it once was). Consider your day for a moment, and you’ll likely recognize you executed problem analysis and mitigation without even realizing it.

While driving somewhere did you notice kids playing ball up ahead, or perhaps see a ball roll into the road, so you slow down or stop? Or even before you got in the car, a flash of color behind it caught your attention, which turned out to be a bicycle? Were you baking, and noticed a bit of shell from the eggs had gotten into the mixing bowl, or just had a feeling you missed an ingredient? Maybe you were working around the house, and realized your child was a bit too quiet, so you quickly checked on them? Even something as simple as proofreading an email before you click ‘send’? These scenarios are just a few everyday examples of how people regularly apply problem management, and if you give it a little thought, I will bet many, many others will come to mind.

So, my advice is don’t fight your instincts. Don’t let the traditional definition you might have been taught a ‘problem’ is constrain you or your business. Don’t think that problem management is only useful in certain areas. Don’t wait for an incident to show you that there’s a problem. We all know problems get introduced in spite of precautions. Be truly proactive, be aware, actively think about where problems could be in anything you are doing and seek to find and eliminate them…before one tries to do the same to you.

Michael Keeling
Michael Keeling
Service Management Lead at DXC Technology

Michael has been providing consulting and guidance related to IT Operations and Service Management to enterprise level organizations in many industries for more than 25 years. He began his IT career in Operations and has extensive background in a wide range of IT practices and concepts.  He promotes a reality and evidence based approach to Service Management, tempered with a degree of humor and relatable analogy that he believes helps others better understand what otherwise tend to be very dry topics.

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? This way you won't miss any of the latest ITSM tips and tricks.

nl subscribe strip imgage

More Topics to Explore

One Response

  1. Refreshing to hear that it’s not just me on this topic. It’s about continual improvement, increasing value, not about a specific, technical definition they ultimately no one cares about.

Leave a Reply

Your email address will not be published. Required fields are marked *