Prioritisation from the Business angle

[Katherine]

In our Problem Log Db we have Priority, Impact and Urgency fields however we don't (as yet) have a matrix which will calculate the Priority based on Impact and Urgency. At the moment we have the Priority options of Critial, High, Medium and Low.

Now the issue is that the customer wants direct control over setting the priority of problems and that they can't do that until they see and understand all the problems. I've argued that the business priority is a part of the overall priority but there is more to a problem priority than just the business impact.

We have over 500 registered problems at the moment for a system, many of those pre-date ITIL and me as Problem Manager so there are probably at least 300 that were logged and then ignored. Going forward I produce a monthly report of new problems which the customer comments on and I alter the priority accordingly.

Now my question is when setting the priority of a problem, should you be looking at a problem in isolation or comparing the problem against all other problems?

My argument is that each problem should be assessed by itself and the priority set depending on how it impacts the users, servers, urgency etc etc.

The client is arguing that they need to be able to see and understand all problems before setting a priority.

Any help on this would be gratefully received.

[BorisBear]

Katherine - I absolutely hear what you're saying but I think you should at least be considering a subset of your problems and prioritising them against each other from a business perspective. There may be some that are low hanging fruit from a technology perspective......keep some resource back to work on those and don't necessarily share them with the business.
However where is the harm in prioritising the rest of the problems against each other - you only have finite resources so the key is to manage the expectations of your business so that they know that if everything is consider urgent then nothing is really urgent.

[Katherine]

I've tried splitting up the problems into ones identified by developers and testers, and problems identified in the live production environment and have been reporting on the live production environment problems to the client for some time.

However, the client has adamantly refused to help priorities any problem logs until we give full details for all 559 problems.

I have also been offering for sometime to provide a full report of all open Known Errors but until yesterday they haven't wanted to know.

Anyway, a spreadsheet of all 559 problems has been sent to the customer and also a full report for all Known Errors has also been sent so it should be interesting to see what happens next.

I'm planning on trying to produce a simple matrix to calculate the Priority based on Urgency and Impact, hopefully that should help set the Priority without swaying it entirely to focus on the business priority.

[Diarmid]

Katherine,

there is no part of prioritizing problems that is not based on business impact. Cost/benefit, risk and timing are everything.

If you have over 500 known problems then the business is right to be alarmed and to want to know more.

Your issue is not whether the business is involved in the process but how.

At the moment you are heading for conflict. This will do the business no good, will not achieve good problem management and will eventually make the business consider the nature of its IT service provision.

Now, the determination of cost/benefit can be difficult. IT often does not fully understand the business parameters involved and the business can have difficulty realizing what the consequences of a "technical" problem will be.

You need to realign your problem management efforts to business requirements. You need to get to the position that, through communication and understanding, the business has confidence in the efficacy of your function.

With over 500 problems on the books, there is a need to assess exactly what you are calling a problem and probably categorizing them in some way that the business can understand. You need to develop algorithms that can easily (almost automatically) prioritize and manage whole categories of problems in a way that is acceptable to the business with minimal scrutiny.

With so many problems you probably have resource issues. The business can help with that, but will only do so if they are on-side.

To achieve any of this takes dialogue with good will on both sides. Once discussions have established the common grounds and common goals (policies and objectives) you can present your thoughts on rules for prioritization for discussion and refinement. This way the business will help you align to their perspective and you can move forward.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[Marcel]

In essence you need two things:
1) A set of definitions for the levels of Impact and Urgency and how they translate to Priority. For instance, Impact 1 (highest impact) = when an IT service critical to a core business process is unavailable or otherwise significantly disrupted. Urgency 1 = Immediate impact and no workaround available. Something like that.
2) A set of assessment questions that will help determine the Impact and Urgency (and as a result Priority) of any given problem. For instance: "Does the problem impact an IT service that is critical to our core business?" (you may want to specify what that core business is) This is one of the questions to help assess Impact. Another one: "Does this problem occur more than 10 times a month?" (or whatever the right number is). This could be one of the questions to help assess Urgency. Having such a set of questions provides you with a repeatable prioritization process and can help reduce subjectivity. Keep the number of questions limited.

Make sure to get your business partners' buy-in with the definitions and the assessment tool.

I would also recommend to make sure your entire organization adheres to the same definitions and assessment method. That will give you a much better understanding of where your pain is and where you need to put your resources. If each group has their own way of prioritizing then you would end up comparing apples to pears.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL Certified