The problems of High Priority

I used to work in a team which took all of it’s work from tickets raised in a queuing system. It was a simple way for people around the world to raise requests to us and for the team to manage their work load.

Each ticket has an area of work (so the right people could pick it up), a description, and a priority rating. Exactly as you would expect. People were really good as being vague in the description (“server down”, oh really? which of the 47 server are you talking about kid?), and the area of work (UNIX Systems Administrators are not Oracle DataBase Admins) but these sort of problems were easily dealt with, and gave me a daily chance to tell some poor tetsing newbie they were an idiot.

Priority rating was a problem that we never cracked however. The original software had three priority ratings, which were pickable from a drop-down menu, Low, Medium and High. Of course, everybody considers their problem to be the most important thing in the world and they pick High. With a huge queue of jobs all labelled as High it gets difficult for people to spot the genuinely high priority job (“The entire test suite is unaccessable”) from the very-important-to-one-person problem (“my password has expired”).

After a while things got so bad that a real “Us and Them” mentality had developed, with people raisng tickets automatically picking High (because it turned out that their management staff were compiling graphs showing how bad our teams response times were) and the technical teams working in a strickly “first come first served” method (“Well they’re all labelled High so we’ve no way to tell them apart”). Something had to be done.

I had 2 possible solutions, adding a new priority rating and splitting the priority ratings into 2 parts.

Firstly – adding a new rating. I suggested we have a “Zero” priority rating. Many of the things raised were routine, and thus did not demand an immediate responce. For example a request to ” Please backup the Environment One database from cold next Tuesday” raised a week in advance could have a zero rating. The backup team will take 5 minutes to slot it into the schedule, and they have a week to do it. Sadly this solution was not adopted.

Secondly – splitting the Priority. Having a single variable of “priority” doesn’t distinguish how damaging this situation is. I suggested we break it into two options: Urgency and Impact. The Urgency gives a level of immediate, so by example, “Environment One is unaccessible” is of High level of Urgency. “My backup needs doing next week” would have a low level of Urgency.

Impact ratings give a view of how damaging this issue is. The backup example has a high level of Impact, as does the inaccessible environment (if people are actively using it). A user who has locked their password out has a high level of Urgency, but a low level of Impact.

Of course, all of these ratings systems need simple guidelines to help people judge how to rate their problems, and people will always pick one rating higher than they really should, but maybe methodologies like this can help.

As for my old team and the escalating wars between Us and Them, well, a solution was found in the end. A new Priority was added, “Critical”, and everybody started using it instead. Words were exchanged, tempers raised, blood pressure raised, and I engineered my way out of the team and off to a different job. When the frantic levels of work dropped off aparently the system works again, but I can’t help thinking that it still has a fatal flaw.

Possibly Related Posts:

• Hot and sour manly popcorn
• 10 minutes of INC causes revelation
• Insomnia + UNIX tools = txtr?
• Server move
• Announcing the world changing, life altering, Benny Hill Diet!