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

Use what's there

[polyphemus-blinder]

I think that feature requests are similar enough to problem fixing requests so that you can just make that one of the choices when filling out a helpdesk ticket. Then they'd be easy to sort, and all in one place and searchable and all that good stuff.

When in doubt, use what you've got.

Re:bugzilla

[mcguyver]

We originally used bugzilla to track software bugs. It's now used for a dozen different processes. Everything from IT requests where someone's desktop breaks, emergency hardware failures, business analyst questions, etc. We're an ASP that needs to be up 24x7 - when an emergency issue is created then the right people get pages. I would definetly recommend bugzill for a company that's 50-250 people.

Re:Trusted "non-IT" staff

[stu-pendous]

I dunno about this... especailly when you want some sort of desktop standardization so that you can insure that your sms delivery of the latest security hole/virus fix goes to everyone properly.

Although this trusted guy may know a lot about technical issues, he may not be in the loop with the direction that IT in the firm may be going.

Plus it's not his job... shouldn't he be marketing to somebody somewhere? Not to mention, it might be asked "If Ed can fix it, why do we pay those IT guys?"

Fixing an issue is only a small part of managing multiple systems. The anal retentive lock down insures against entropy and chaos.

Re:RT

[SuperBanana]

We use request tracker. http://www.gnu.org/directory/rtracker.html

So do I, across three companies now that I've worked for. It's eccentric, to say the least.

• "Killed" tickets aren't "killed", they're only -marked- killed. Ie- no way to delete tickets. No magic button for the admins to click to delete 'killed' tickets- you've got to delete them by hand in SQL, something management is uneasy about doing on a production system.
• No way for anonymous users to check on the status of their ticket- you've got to grant them rights, or give guest rights to -everyone- to see -everyone's- tickets(and that leads to why-is-my-request/why-is-their-request crap)
• Horrible support- on several occasions I've asked in-depth questions and not recieved so much as a peep from anyone; sometimes I've posted 2-3x. The authors are clearly busy consulting- not supporting.
• Users can bring down the entire system to a halt if you're using MySQL, the default/best supported DB. Because tickets never get removed, and the default search parameters are -all- tickets and -all- queues, a single search can take MINUTES to complete on a SMALL db(20-30,000 tickets).
• Clunky/confusing interface. Things that should require one click require several. Functions have non-intuitive names. Etc.

It's not nearly as bad as Big Brother, but it's close, at least in terms of eccentricity. If I had to recommend a system, after almost a half decade of using RT, I'd flat out tell them to try something else first, and leave RT to last to evaluate. Bugzilla certainly does sound interesting, though I have no experience with it.

Re:Our solution - Broken but it works.... Kinda

[copterdoc]

Hire an intern. Tell him to sit by the phone all day and to fix computers when somebody calls. Have an online trouble database for those troubles more delicate than "My computer doesn't work". If you think that is not enough work give hime the asdditional tasks of managing the printer maintenance and supplies. The intern gets something to put on his resume. You get a good portion of your workload lightened. Everybody wins.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Demand the requests be sent via email

[AppyPappy]

A small segment of the working white collar world is not comfortable putting things in writing. They don't want documentation of their cluelessness. They will tell you things via voice but you should always a demand an email. If they complain their request has been ignored, remind them of the email requirement. Eventually, they will find someone else to annoy.

Another segment hates email. Face it, they hate ANY technology. I call these the 12 O Clock crowd because that is what is blinking on their VCR and microwave all the time. These are the people who call Tech Support to change their background once a month when their son sends them a new baby picture. They would never dream of simply doing what they were instructed last time they called. And if you send them written instructions, you are wasting your time. When you mention that an email is required, they will get the Stunned Bunny look and simply decide their request is foolish anyway.

Also, make sure the requestor signs off on test results. That shakes a WHOLE lot of people. You will eventually be reduced to working on truly important matters rather than time fillers.