The Beetil Blog
Blog » Effective Problem Management
I went along to February’s monthly itSMFnz seminar here in Wellington a week or two ago. There was a really good presentation on problem management by Mark Faircloth from HP. It was a perspective from the presenter’s practical experience. The key things he focused on were:
- If you can’t identify the cause of an Incident, then it should be logged as a Problem record (or associated with an existing Problem)
- The important thing about problem management is finding a workaround to enable restoration of service – not root cause analysis to get to the bottom of the Problem (and subsequently raise a Change to get it fixed)
- Work on the most important Problems first – i.e. where the business services are most impacted
There were about 60 people at the seminar, and after a quick show of hands it was a bit of a worry that only perhaps 1 in 5 had problem management processes documented in their organisation, let-alone the likely much lower percentage of those who would actually have been implementing problem management.
In a brief Q&A session it was commented that the service desk often has trouble finding workarounds (if they physically go to the effort of doing that), or that problem management information was somewhere else, such as in someone’s spreadsheet, or in a different tool altogether. What sort of tools are people using out there? Why are people making it so hard to find and use the information that’s already been gathered?
How about automatically searching for related information during entry of an Incident, and placing those relevant search results handy for the user? Or if the user does perform a separate search, firstly, searching is easy to do, and secondly, related and relevant information is returned. Funnily enough, Beetil does that. Beetil’s purpose is to help the user and make it easy to get at the information that you’ve already got.
Beetil makes it pretty easy to generate a Problem for an Incident, or link an Incident to an existing Problem. And of course you can raise a Change to fix the root cause (if it was important to the business to find and fix it), and link it all through to a Release. The Problem Dashboard highlights Problems without workarounds, and sorts them by their own priority (which should be according to the current impact on the business and effectiveness of the workaround). We’re not finished with problem management in Beetil yet though, there are plenty of areas where no doubt we can make it even better.
Tags: itil, itSMFnz, Problem Management, restoration of service, workaround
March 12th, 2009
To whom it may concern,
to find a workaround to enable restoration of service: is this the responsibility of the problem management? I all always thought it is the responsibility of the incident management so the problem management can focus on root cause analysis and finding a solution. Since we are just in the beginning of defining a IT QM-System that is based on ITIL(R) and works for a small organization, we seek for clarity in the naming of things. So if you can clear up my mind, it would be of great help.
With best regards,
Jochen
March 17th, 2009
In reality it will be both the incident and problem management teams who work together to get workarounds in place, but at different times, each with a different focus. Incident management will be more REactive (i.e. fix it now if it’s a high priority), whereas problem management will be more PROactive.
Incident management’s prime focus will be to get the service up and running again (particularly for P1 or P2 incidents). This will likely involve some sort of workaround if the cause of the fault can’t be determined, or it can’t be permanently fixed straightaway. In the real world, incidents with lower priority (e.g. P3, P4 or P5) will likely sit around for awhile (or forever) before being dealt with.
Problem management will take a broader look at common and related incidents, and look to get a workaround or a better workaround to reduce impact on the business. In reality, P1 and P2 incidents will already have some sort of workaround. It may not be a great workaround, and business may still be severely impacted by the fix. Those incidents will be associated with a problem, and the problem management team will look for a better solution to reduce the impact to the business. They will also look for workarounds for collections of business-impacting P3, P4, or even P5 incidents.
That’s how we find it works in the real world anyway. It will vary from one organisation to another and there’s not necessarily a right or wrong way of implementing it either!