Prioritization of requests in a small IT department

Question

I'm looking to implement ITSM in a two-man IT department. We have a web-based workflow system where five request types have been defined that end up in our department. The rationale behind the division of the request types is basically for categorization, but the users often don't understand which request type to pick.

I'm planning to simplify the system by making only one request type visible to the users and then we will change the type if necessary. But instead of separating by technical area (the current request types are Computer Support, Web Support, ERP Support, CRM Support, and Analyst Support), I think it would be better to separate into Incident, Problem, Change Request, and Service Request. The old way of categorization will be replaced by linking each request to a project which represents the associated service, and this will be done by us instead of the users.

Now, our workflow system displays all the requests assigned to you in one giant list. It is possible to customize the fields which are displayed so that you could see which are incidents vs. change requests. I have been considering writing my own front end to list each request type in a separate grouping on the screen. This made me wonder about prioritization of requests. Each request is assigned a priority between 1 and 5, so a Priority 1 Change Request is more important than a Priority 3 Change Request. But is a Priority 2 Incident more important than the Priority 1 Change Request because it's an incident? Because there are only two of us in the department, I don't think we can be working on change requests while an incident is happening. I've always been of the opinion that you should fix things that are broken before building anything new. Or am I out to lunch on this? Should we be ignoring the request type and working based off the priority level alone?

If I am heading down the right path with prioritizing all Incidents ahead of everything else, how should I prioritize the other request types? My initial inclination is to do Service Requests next because I expect them to be fairly quick, followed by Change Requests and finally Problems. However, I'm slightly concerned that by putting Problems last, they will never be investigated. Maybe the order should be Incident, Service Requests, Problems, Change Requests?

Answer 1

I was going to just leave this in comments, but actually I'm going to post an answer because while I think you have good intentions, I think you're going about it in a more complicated manner than you need to.

It is good that you are planning some sort of ticketing system, and I am of the opinion that for anything more than about 20 computers it is a good idea to help keep track of things. What you need to bear in mind is that helpdesk systems come in many shapes and sizes ranging from a glorified list of tickets to very complicated systems with many categories, priorities, assignees, escalations, SLA's and dozens of other bells and whistles. The larger and more segregated your IT department is, the more benefit these more complicated systems have, but for smaller departments they can be more of a hindrance than anything else.

For the sake of comparison I also work in a 2 man IT department, and as such do a bit of everything, so too many different options on the helpdesk would just get in my way. We have a relatively simple home-grown helpdesk which has a user facing side and a technician facing side.

The user facing side has a minimal number of fields so as not to scare them off with information overload (title, category, priority, affected asset tag, problem description). Any and all IT issues are logged here, we don't have different systems for change requests, service requests etc. Our categories are also intentionally broad, again so as not to confuse matters (Computer hardware, Printer problem, Outlook, Internet, General/Other).

The technician side has a few more fields, but is still not very complicated (assignee, status, follow-up date). It allows us enough flexibility to categorise tickets (mainly for reporting purposes) but doesn't get in the way of actually fixing the problem. We are able to leave comments on the ticket showing what we have done, and if one of us needs to work on the others tickets, we know what has already been done.

The main goal of our helpdesk is to keep track of the problems our assets are having (and who is creating the tickets) so we can see what assets are being most troublesome or what people may potentially have training requirements. We don't have anything complicated like categorisation of incidents, problems, service requests, change requests etc. - that would be unnecessary for us, everything comes in as a ticket and we deal with it as appropriate.

If you want a comparison of priorities, ours are generally as follows. The user has the option to set a priority when they create the ticket, but we also have the ability to re-align it with reality (we all know one user who creates priority 1 tickets for absolutely everything :P).

1. Anyone who is unable to work
2. Anyone who has a problem but is still able to work
3. General day to day stuff and random things thrown our way
4. Project work

In short, yes you probably should implement some sort of helpdesk system, but maybe not something as complicated as you're describing in your question. Ultimately, you need to interact with this system every day so it needs to be as streamlined and easy to use as is practical for you. Make the process work for you, don't try and work with some process designed for IT departments of dozens. If you're unhappy with any part of the process then change it a bit and see how that goes and keep refining it until you are happy that it is working efficiently for you.