Our Problem Management Team met today to start cracking on our first case (as mentioned in this post). The process we’re following is this:
The Problem was already Detected and Logged, so we ticked those off quickly. Categorization and Prioritization were the first tasks we needed to get done.
We decided on this standard:
Category : Is inherited from the initiating request. If it’s Service Requests behind the Problem Candidate – then the Problem is also categorized as Service Request. That way we keep in focus what the target we’re looking to solve is.
Prority : The Priority for a Problem is defined differently compared to Incidents for instance. This is important to keep in mind. A Priority 2 Incident doesn’t necessarily become a Priority 2 Problem. When setting the priority for a Problem we decided on the following factors:
- Frequency : How often does this problem cause a request/incident?
- Request/Incident priority : What is the priority of the request caused by this problem?
To illustrate this, here is the Priority matrix we use for Incidents:
And this is the matrix used to set the Priority of a Problem:
Of course other factors could be considered when it comes to category and priority:
Is there already a known workaround for this Problem?
Is there a SLA for the affected CI and/or Service?
How many users are affected when the Problem causes and Incident?
…and you could probably find several even more relevant parameters. Also – would you consider changing the priority as you learn more of the root cause or the required solution? I don’t know yet.
Our main goal was a simple method that looked similar to what our co-workers already know from the Incident process.
Feel free to let me know what you think of this way of handling the Category anf Priority of Problems.