To make it managable you will probably have to make some assumptions and adopt a set of financial parameters that you use consistently. The last aspect is what sets the impact determination for problems apart from the one for incidents: for problems we are interested in the cumulative impact of all occurrences.Ģ) Urgency is determined based on the expected start of the impact (right now? could happen in 6 months?), the expected time to restore service when it happens, the expected effort to restore service (can our support organization handle this?) and the availability of an acceptable workaround that prevents or minimizes impact.Ī matrix then maps impact and urgency to priority.Īlthough I agree with many of Diarmids considerations, it is my opinion that many organizations are not capable to look at problems in such a refined way when prioritizing them. In our organization we consider impact and urgency, which together translate into priority:ġ) Impact is determined based on the affected service/system, the potential level of degradation/damage, and the potential frequency of occurrence. It looks like building politics and favoritism into the system. This introduces the risk of "double dipping" or building a bias into your system. It seems to me factors 1, 2, 3, and 4 are very closely related. Handlingit wrote:Every Problem will be rated in each of these categories as “High (3),” “Medium (2),” “Low (1)” or “None (0).” These ratings are then weighted to arrive at an overall score which is compared to all other Problems. This is work in progress and any input would be appreciated. Hierarchy (weighting of 2) - The position of the user within the organisation. Sensitivity (weighting of 2) - The sensitivity or profile of the individual, department or branch\site.Ħ. Number of staff affected (weighting of 4) - The number of staff impacted by the problem.ĥ. Number of calls (weighting of 5) - The number of tickets being logged with the Service Desk for this problem.Ĥ. I suppose there is an argument that this could be the same as no.1)ģ. Productivity loss (weighting of 7) - Productivity loss in terms of time when this problem occurs. The seven areas being:ġ.Ĝost to business (weighting of 9) - The cost to the business when this problem occurs.Ģ. I have knocked up something simple that I will push out to the Problem Management Board members for their thoughts.Įvery Problem will be rated in each of these categories as “High (3),” “Medium (2),” “Low (1)” or “None (0).” These ratings are then weighted to arrive at an overall score which is compared to all other Problems. I was trying to gage whether a matrix of this kind is often used by Problem Managers and to compare my ideas against established systems. My intention was not to get others to do my job.
PS to my regular readers and protagonists: remind me not to be quite so strong on the irony when responding to the "occasionals" or "irregulars". Sometimes the potential for loss can be held in check by a workaround and that should reduce the urgency for resolution.
To return to the original question, a weighting matrix (or formula, or whatever) might also want to take into account the quality, cost and durability of any workaround identified for a particular problem.
Don't you think there is a need to consider risk, impact and urgency all at the same time - or to recognize that a decent risk analysis will take into account impact and urgency as well as likelihood? Putting "ITIL compliant" in quotation marks does not get away from the fact that there is no such thing as ITIL compliance, and so I will take you to mean "most ITSM support tools" (Are there many out their that do not tip their hat to ITIL?).
ITIL PRIORITY MATRIX FULL
It soon gets very complex and you might find you need someone full time drawing up probability assessments. If you want to play about with impact from problems, then you have got to look at how likely a future (often not fully predictable) incident is to occur at, for example, the worst time for it to happen. There is no need for an incident to occur in order to determine that a problem exists. If I want to be really pedantic, incidents are caused by the intersection of problems and events and/or actions.Īnd this isn't: the impact of a future incident cannot be predicted unless you are also predicting when it will occur, how long it will take to detect and what work affected users are doing at the time it occurs, among other things.Īnd this isn't: Problems are the underlying features of a system that have the potential to cause incidents or deterioration of service provision. But this is: resolving (not solving!) problems removes the potential for incidents.
0 kommentar(er)
