How Do You Manage Requests in Your Organization?

StormShadw asks: "How do you manage IT requests in your organization? There seems to be a lack of software solutions specifically designed to track requests. Most that I've been able to find are either problem tracking systems or bug tracking systems, neither of which completely fit the 'request management' model. I work for a large bank and my department supports all of the internet web presence and online banking applications for the company. We receive hundreds of requests a week (my department has 51 people in it), typically through a variety of mediums (phone, email, hallway conversations). It's impossible to manage all these efficiently when there is no centralized system. What's the solution? What do you all use?"

"There is a 'workflow' aspect to many of these requests: we do our thing, then pass it off to the UNIX admins, firewall folks, or DBAs to process another portion of the request. Ideally, I'd like to have a web based system where our customers (internal lines of business) can submit their requests, get status, etc. We would also manage a queue of work through a web interface, assigning requests internally or to other teams we work with. Email notifications could be generated when requests are completed."

bugzilla

[rizzo]

I just tell anyone who needs any work done from me to file it in our intranet bugzilla site. Tracks status, assignment, etc.

Give Double Choco Latte a look....

[bigtoy]

...at http://dcl.sourceforge.net/ [sourceforge.net]

A couple of years back I had need of an issue tracking system. Double Choco Latte was one of the systems I used. The source code is well laid out and easy to modify if you have special needs.

There are a lot of features, not sure if it will cover all of your requirements. It actually had more features than I needed at the time I was using it.

Track-It

[Anonymous Coward]

We used a program called Track-It (http://www.blueocean.com/product.asp). It was accessible by any of us from any of the Windows XP machines attached to the network, and served as both the inventory system (for the audio-visual room) as well as a checkout counter (for the library), computer auditing system (occasional updates allow us to log any changes in hardware or software installed on a machine), call logging system (for technical issues reported by phone or e-mail) and even as a knowledge base for issues with common solutions. It was practically invaluable for the entire summer I used it :>

Re:bugzilla

[rutledjw]

We're looking at the same.

Right now, we're stuck in bed with a big fat obnoxious broad named "Clear Quest". It's part of Rational and an absolute POS. It's heavy weight, doesn't integrate well with it's own products (web interface and Clear Case UML). Further, I was told they (our CM team) could get a CQ database for us set up in a day. That was in AUGUST.

Developer use and support of it is spotty, in general it's hated but has been named as a standard. Our *nix and system support group is a bunch of *nix and OSS snobs anyway, so bugzilla seems a no-brainer. Almost the entire team has implemented Bugzilla elsewhere (in previous lives) already.

I'm thinking we'll do that and I'll beg forgiveness later (if anyone really cares). But I would recommend against ClearQuest

Sticky Notes! :)

[dbretton]

Does the job for me.
Little, yellow, different, better.

Re:HelpSTAR

[itwerx]

No way!! I just finished an evaluation of HelpSTAR and it sucks hard!!!!!!!!
We didn't even finish the evaluation period because we got so much negative feedback from users.
It's mostly stupid UI crap, like you can't send a request with "Fwd" or "Re" in the subject line (wtf?) - they say it's to prevent loops.
Attachment handling is awkward - have to click about three levels deep if you want to save it as a file rather than execute it.
There's no way to see all currently open tickets (well, there supposedly is but it doesn't work right).
You can forget about searching for anything like a closed ticket as the search function is terminally useless.
Argh!
That's just scratching the surface, I could go on for hours...
To be fair though, if all you have is a call-center you might be able to make it work acceptably. Most of our issues revolved around email and file attachments.

footprints

[Anonymous Coward]

Personally, I think that once your IT environment grows to double digits, you pretty much need to establish an interface between yourselves and the rest of the organization.. who can remember hallway conversations anyway? Even in a small department, perpetuating these sort of things as official operational requests will almost definitely become unworkable (not to mention stressful!)

You will also need a trouble ticket system, or at least some project management software that everyone can agree to use (they are sometimes interchangeable, but they are NOT the same product; you should look at both in making your choice..)

When this reached a breaking point in my department, I found a distinct lack of "production quality" open/free ticket systems. I looked at several, and many of them would have been enough for me, but there were too many unimplemented features/implemented bugs/horrible UI mistakes to actually ADD productivity (as the inhouse programmer, I wasn't planning on manning the newly created support line myself; our first-line support person would need something intuitive and powerful while screening calls, delegating, etc.)

We eventually settled on Footprints [unipress.com], a cross-platform web-based trouble ticket/project management tool. It's written in Perl, works with Apache on Linux, and has several choices for backend databases (GDBM, Oracle, MySQL, MSSQL). It has alot of features, many of which we don't even use (yet :), but some of the important ones to consider:

• The system processes (via a cron job) incoming emails on either remote or local mailboxes (I use IMAP to our regular mailserver). It can take cold submissions and process them according to various rules, and experienced agents can edit tickets via email as well. In addition, it can send email (SMS too, I think) alerts when tickets are submitted, assigned, escalated, edited, closed....
• Sophisticated reporting features. This has helped us in alot of ways: in terms of support, it lets us know what the common user problems are, who the problem users are, what we could improve across-the-board, and quantifies that in a report you can pass out at those (non-IT) management meetings. It also can tell the "others" what your turnaround time is, who your most productive staff members are, and how many requests the department fields.
• Easy and *efficient* to use. If you waste alot of time interacting with it, thats time that you aren't actually addressing any of those tickets.

Just by way of comparison, Remedy [remedy.com] is another example of such a commercial product; it did not have a web interface when I was comparing, but I think they claim to now (as the only user in the department with several non-Windows desktops, it was at least important when I made MY recommendation :)

Re:RT

[ags]

Disclaimer: I am the author/maintainer of WebCollab.

A possible alternative to RT is WebCollab [sourceforge.net].

At least one of my users is familiar with both projects and prefers WebCollab.

Apart from that it's Open Source and the code is reasonably easy to follow. Tailor matching to your organisation shouldn't be too hard. Judging by the patches and comments I get, some of users are doing just that

.

Smart IT Department

[BadluckShleprock]

First of all, our IT requests are on old fashioned paper. The "explain reason for request" areas are way too small to actually explain, and they even have a "date needed" box. Why would you ask for anything other than "ASAP"?

Secondly, my IT department is soooooo smart . . . how smart is it?. . .it's so smart that when I put in a supervisor approved request for an OS upgrade or development enviornment, THEY determine that I don't actually need it. I made the mistake of asking how they determine what I really need and don't need. After the flurry of "who do you think you are?" and "don't question me" type statements, it came down to the fact that they didn't want to buy "non-standard software" like Borland JBuilder, and even Windows XP when it was new.

My frustrations were compunded by the fact that the purchases would not have come out of their budget and that they would not be responsible for supporting it. Our software engineering department has special budgeting seperate from the rest of the company and they figure that we are smart enough to know how to put a CD-ROM in the drive and install a piece of software.

Why were they being so difficult? It turns out that an off-the-cuff remark I made to the company's President over a bunch of beers in a bar in Hannover, Germany, eventually rolled downhill and got one or two people in IT in a little trouble. That happened years earlier, but I am still feeling the wrath of IT.

Lessons learned: (1) If you get someone from IT in trouble, make sure they aren't around long enough to get revenge. (2) If your supervisor/manager approves your request but IT rejects it, buy the software yourself and expense it. Just make sure the dollar amount doesn't require approval by the board of directors.

Re:Remedy

[yocuma]

We use it. If done right, I can see it working ok. Too bad the 'do it right' guys are busy doing other applications. In our current implementation, I can say this... At least once a day, I go to a co-workers desk and say: "Hey, come here and look what Remedy just did." If nothing else it is a good laugh at least once a day. Yesterday, this guy came to me and said he opened a ticket to just to view it's status, and that triggered an e-mail to the user stating he had started the change request. Then, he tried to change the status to say he was not working on it. It e-mailed the user again saying he was working on the ticket again.

Re:Remedy

[uspsguy]

My nick gives you a clue that I work for a pretty big company. We have been using Remedy for a couple of years now. It seems to work well for us. Scalability doesn't seem to be an issue. We have hundreds, maybe thousands of staff, multiple thousands of sites and, I think, workstation numbered in 6 digits.I don't have a clue how practical it would be for a small operation but it is enterprise ready.

Re:Remedy

[CmdrGravy]

Reading some of the other posts here it seems a lot of people have problems with Remedy. I must admit I think it's an excellent product, powerful and flexible enough to meet any need you may have. Where I think people have come across problems with it is in situations where it is not properly supported or implemented ( it does take a dedicated developer / support team to keep it working efficiently and evolving to meet the changes to your structure ). I have used it in a 1st Line Support scenario and now in a 2nd, 3rd Line Support scenario and provided you are willing to work with it it's an excellent system. However it's amazing the number of luddites you come across, even in IT companies, who instantly hate Remedy the moment they set eyes on it: "This just takes too long, with my post it notes and memory I always know what I'm doing" "Why should I have to bother typing stuff into this pile of junk once I fixed someone's problem?" But really these people miss the point, the power of Remedy ( for us at least ) is that the 1st line helpdesk can see in seconds any open requests and give an up to date appraisal of what is happening with the request to the user or any other interested party. Any further info from the user or whatever can be instantly transmitted across to whoever is dealing with the problem. In short I like it but I imagine it's very expensive both initially and to support it thereafter.