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...