SeverityCodes

From: jtaylor@bastyr.edu
Subject: Re: [rt-users] Severity codes
Date: March 11, 2004 9:02:01 PM EST
To: andy@petdance.com
Cc: rt-users@lists.fsck.com

Andy Lester wrote:

I'm thinking of adding some sort of severity code to my RT3 install. We're tracking programming defects. Something like "Pick one or more of these effects":

• User showstopper
• User gets error message as noise, but life goes on
• Throws crap in the error logs
• Corrupts data
• Makes sales reps call
• Is bad code, but still works

Anyone done something like this? What severities did you use? How did it work out for you? xoa Sure am. I went with:

Severity 1 - Chimera Severity 2 - Low Severity 3 - Average Severity 4 - High Severity 5 - Critical Severity 6 - Emergency

In addition to these severities I have an "estimated time to completion":

1 hour or less
more than 1 hour to 1 day
more than 1 day to 1 week
more than 1 week to 1 month
more than 1 month

I then use this matrix to assign the built-in RT priority:

Severity

   ETC			1	2	3	4	5	6
 ------------------------------------------------------------------
 ETC <= 1 hour		1	2	3	3	3	10
 1 hour < ETC <= 1 day	1	2	3	3	3	10
 1 day < ETC <= 1 week	1	2	3	4	5	10
 1 week < ETC <= 1 month	1	3	4	5	6	10
 1 month < ETC		1	4	5	6	7	10
 

So priority 3, for example, would get a starting priority of 20 and a final priority of 29.

--- Where do these 20 and 29 come from? Could this be explained? ---

Finally, I use this matrix as a guide to when/how often I work on projects of each priority. Of course, projects with a higher RT priority within my home-brew priority bands gets done first.

Pri	  	Hours per Day
        Monday	Tuesday	Wednsdy	Thrsday Friday
 ---------------------------------------------
  1	-	-	-	-	-
  2	2	-	-	-	-
  3	4	4	4	4	2
  4	2	-	2	-	-
  5	-	4	-	2	-
  6-9	-	-	-	2	6*
  10		   as required
 
 

If I'm all out of pri. 6-9 stuff to do on Fridays, I devote 2 hours to pri. 1 projects.

The goal of all this complication is to push as much work through the door in the shortest amount of time possible while still devoting time to highly important and/or long term projects and not completely ignoring the very low priority ones. One of the key components is strongly encouraging requesters to mark the severity as average. Fortunately, we're a small enough shop that I usually know if someone is crying wolf and I just adjust the severity down.

It did take some getting used to and I still haven't completely disciplined myself to follow the work schedule, but overall it works quite well. All projects get a fair shake.

---------= Comments =---------

I just wanted to add another line of thinking on using severity in a ServiceDesk scenario and relating the 0-99 priority numbers with serverities. I'll link to a couple of jpgs of the severity matrices I am using as a guideline:

File:Impact-Priority-def.jpg File:Priority-Resolve-def.jpg

So basically I slice priorities into High, Meduim and Low then use the Scope of the Incident as it relates to the organization as the second dimension. Then I distribute the severity codes within that matrix.

The Priority Resolve matrix shows the 'reasonable' response based on the Priority Code. With these two tables as a guide you can then customise to meet various SLA and Business Critical Support needs. The times in the resolve codes can also be used as trigger periods for cron based jobs that watch for high severity issues.

In my particular instance I just use a CF to define the severity codes.

Hope that's helpful to someone...

MichaelErana