What is a “problem”? If your 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.
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 man,y 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.
Problem management and “end-to-end”
When I say end-to-end, 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?”
Read More: ITIL 4 Foundation
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 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.
Widening the remit for problem management
What I’m proposing here 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.
Source: itsm.tools
0 comments:
Post a Comment