This process has 3 key phases, which make up the Rapid Problem Resolution Problem Management process:
- Gather and analyse existing information
- Choose a specific symptom
- Create an action plan to capture definitive diagnostic data
- Identify the cause
- Identify and implement a fix
This Problem Management Process can have additional stages added or removed to fit in with its requirement.
Rapid Problem Resolution Conclusion:
Although I have studied this process I have not seen it adopted successfully in many instances. Or to be more specific I think this fits into the Problem Management Process as an add-on to an existing process rather than an absolute process. The main reason is that this Rapid Problem Resolution process requires a recurrence. This goes against the grain for me, ideally I want to identify the cause and fix it prior to a recurrence. There are times when a recurrence is required and additional diagnostics tools are deployed but this would be part of a root cause investigation not the only route. The other major flaw with this process is it requires you to select one symptom. This can be helpful in some scenarios; however it can also mean disregarding useful information, which can slow down root cause investigations. For example if customers are unable to access an application, that is very useful to a problem investigation, it highlights components that could be a potential cause. If further information is added such as ‘customers are unable to access all applications’ then this narrows down the components that could cause the impact, leading to a speedy Problem Management investigation and fix.
In short a good addition to a Problem Management process, however not one that should be used in isolation.
More Interesting Articles:
- How to use Fishbone Diagrams in Problem Management
- The best Problem Management KPI revealed
- How to use Comparative Advantage in Problem Management