Incident Management - Common Problem

[Harvey]

I think this is probably a problem common to many businesses and wanted to hear some opinions on how to approach it.


Users submit requests for changes in a particular system, mainframe, or terminals that are in brach offices in a wide geographical area. Some requests are to improve ease of use, some are new features, some are to have errors fixed. Most of these requests spark a short term development project, completed by various vendors in the business.

These users do not understand IT, or the work required to fufil their requests. Most of the requests are sent as urgent. Because to them, they are.

Requests are written by users, approved by their bosses, sent to a type of change board in IT, then forwarded to IT. This type of change board understands the business, and understands IT.

Many ridiculous requests come in, these are filtered by the group before IT recieves them. Once IT receives the requests, the users are contacted again and the schedule renegotiated.

However, even so there is usually a backlog of about 30 requests, changes are often late, users often unhappy, IT is stressed to the max, and little data is available on the process.

The entire process is managed with paper requests, signatures, and occasionally data is recorded in Excel.

There really is no SLA or UC to speak of that is enforced or understood. No service catalogue. No cost associated to each task. No data on the average time required to make a particular change.

Currently, IT feels that the problem is the sheer volume of the requests, and the unreasonable schedules demanded by the users, and the time it takes to complete each one.

Seems like a classic Service Desk, Incident management and change management problem to me.

What would people suggest as some quick wins to work into this problem?

[AndyHutchinson]

Sounds a lot like parts of the organisation I work for. A very useful method to make customers think about what they are asking for is to associate the change with the notional cost. Of course, I assume that your organisation doesn't charge (directly) for IT Services. Ask users to quantify the business benefit of the change in monetary terms and then tell them how much it would cost to make the change. We have started doing this and it does make a difference.

[Dr ITIL]

Some ideas...

1. Take the temperature down - re-allocate resource to 'blitz' some of the easier user requests. Overtime perhaps?

2. Take an inventory of all requests. Proactively write out to your user base and inform them that, "Due to exceptional demand...etc etc...your request will be processed by xxxxx time."

3. Find a reason to stop taking incoming requests, or only accept certain types of requests at certain times of the day, say the first hour. This should help control incoming requests more.

4. You need a stronger way of stopping users from putting ALL requests are "urgent" or "super urgent". Why not allow each business unit just 1 (or 2 whatever) super urgent requests per day - if needed. This is to ensure that it's fair across all business areas. It will also educate your business that these things come at a premium.

5. Take the pro-active approach. Advise your users that someone will be walking round their unit between 10 and 11 to process their 6 change requests. The users will love the pro-active service and the engineer/analyst can prioritise the requests with the business whilst he's over there. This means you are only alllocating one person's time for x amount of hours/minutes.

6. Eventually you will need to understand:- Your DEMAND (for service) V's your ability to SUPPLY the service. If demand outstrips supply - then you need to think about:-
- Out-tasking some things
- Stop doing some things / let the business do them
- Get more people (not popular with the finance/resources folks!)
- Automate your request and delivery processes
- Get to the root cause of WHY these things are being requested...is it because a recent project forgot to so something? Is it because a certain type of monitor is failing due to age? Is it because the user community needs re-fresher education

7. Don't lose your grip - keep your cool. It's the acid test for Service Managers - when demand outstrips supply - you've got to keep your head and look after your delivery people. Ensure they have their lunches. Ensure that they are not stressed out all the time. Try to inject a bit of humour into the situation. Lead from the front!

Hope these ideas help!

Good Luck.

Dr. ITIL.

[Harvey]

[Toshi]

Hello!
I our case, we're IT service provider and so many customers and so many problems and backlogs also.
At first we dicided following support escalation rules and agreed with business side.

1. Unable to communicate with TECH group without ticketing tool.
Anybody cannot contact via e-mail/phon as to keep the time focus on technical task.

2. Define the issue priorities and target time to resolve.
TECH team has to meet the target and manage by incident manager, but they don't need get huge phone calls and e-mails.

Actually, they can't the target time to resolve so business has much complain.However we're talking with business that we have to get this process to improve whole support performance for all company.
It's SLM manager's responsibility to be agreed with business and management, so I'm trying to do that still now.

Next we need to find actual performance of our support and then to make the plan to increase that. It's really hard to improve the confused situation, but I believe we can do step by step.

Is it any help for you?

[fair_n_hite_451]

It's starting down the road of an SLA/OLA type structure (which you say you don't have yet), but it would be helpful to document what constitutes an "urgent" or "critical" problem.

Start by sitting down with the business units (which may be difficult in a geographically dispersed organization - teleconference maybe) and the IT group which filters requests and agree on the types of changes which can be catagorized as highest priority.

Communicate that list to both the requestors, and the filter group.

Stick to it.
-------------
It's far easier to get agreement on priority issues when the focus is on "business in general" as opposed to "my problem I'm complaining about at this moment" -- but once the business agrees to the guidelines to be used, then IT has to be prepared to hold them to it.

If your business group is unreasonable about the fact that "everything is urgent", then I would agree with other posters that documenting the costs associated with every change is the definite way to go. Nothing makes business people reconsider requests like dollar signs attached to them. You'll likely find that the number of requests goes down as soon as you start putting cost / benefit numbers together for requests.
-------------

However, these problems don't sound like classic incident / change / problem management to me. The bulk of the issues sound as if they are in fact related to resource assignments and availability, scheduling of development work, and IT's "organizational capacity". Those are project / program management issues. Communicating schedules for development efforts, and meeting those schedules should be the province of the project manager who is running those development projects should it not?

CrS

[Big Al]

On top of some of the other great suggestions, I have two thoughts that may help.

First, you need to develop a prioritization method for your requests and communicate this method to all users. If your business feels that financial impact is of utmost important and a significant emphasis placed on requests that improve the company's bottom line, use that attribute in your formula to determine priorities and apply a large weighting so that requests like these bubble to the top.

Second, your clients need to be able to take the time to document these requests properly and they can't feel like they're throwing garbage over the fence. If it's important enough to them, they will take the time to fill out your form with all of the information and your need to contact them for further clarification will be greatly reduced. You'll also find that the number of requests will diminish if clients are being asked to do more of the work.

[Raven]

1) You seriously need a ticketing tool. Paper forms when you're supporting a "wide geo. area"? Crazy-talk. Decent ticketing tools also let you track approval chains, automatically send requests to relevant teams, record all information pertinent to the process as you go, etc. Anyone, from the requestor on one end of the process to the IT support person on the other, can see what work is coming, what's already there, what state everything in between is in, what additional information or approval might be needed, etc.

2) Differentiate between 'problems' and 'service requests' and provide clear definitions as they're creating their ticket. This allows you to prioritize and/or route - problem fixers are probably not the same people who are making the decisions about what new applications or features to implement.

3) "Severity" definitions can also help - again, this must be well-defined at the initial point of contact. For instance, our users are told that if they call the after-hours support line, something had better be down and affecting a significant service or portion of the user population. You can also build SLAs off of severity levels.

4) With your requests/problems more organized and quantifiable, it should be easier to prioritize them and feed them into your project/program management.

5) The change board should be negotiating the schedule and prioritizing the requests against all the current open or planned work. This is where the business and IT meet to decide the technological direction for the limited resources available. While exact dates might be negotiated later, the change board should at least put it in a ballpark, based on the priority of the request and the current IT workload allocations. This leaves the business groups to arm wrestle over priority - and leaves IT partially out of it! While we should help direct the overall technology roadmap, letting them have a significant role in making these decisions can help them see what you're up against and keeps us from always being the bad guy.