Incident Mgmt & Change Mgmt

[ianm]

I am to investigate a new finacial software system.
Users can log calls regarding the functionality of the system e.g a user calls the service desk because a report does not have a margin when sending from an invoice.
The service desk cannot resolve it so an incident is raised.
A support person picks it up and finds that the software does not include margins in its functions.
The software developers need to work on this therefore a RFC is raised.
Permission for the change is given and work goes ahead.
The problem is the change can take a year to implement due to the complexity of the software and the resources available to work on it.
The incident stays open until the change is complete - and the incidents are growing in number daily. Well over a thousand at the last count.
Management want the queues down.
I have identified some calls that can be closed due to the original requester has left the company etc. but incident calls cannot be closed due to age etc because someone somewhere is working on a requested change.
Any ideas how to best manage this backlog and new incidents?

[dboylan]

One aspect of ITIL is to make visible the portions of IT that are not functioning according to expectations so that the organization's management can address them. It sounds like your organization isn't funding the resources necessary to resolve Incidents that are outstanding due to unimplemented Change Requests. If management wants to wants the queues down, then fund the area of the organization that directly affect the number of outstanding Incidents.

That being said, you can partition the number of "Open" Incidents by adding a status of "Open/Awaiting Change". This would segregate the number of open Incidents that aren't pending a Change from those that are pending a Change.

Also, you should investigate the current open Incidents' priority. The example you gave sounds like it would be a pretty low priority issue. If you have set the priority correctly, then you could produce a more meaningful report that shows outstanding Incidents pending a Change by priority level.

Don

[pineapple]

What software are you using to log incidents?

Most software allows the user to defer the incident to the date after the change has been implemented. The incident is then taken out of the reporting for open incidents.

[ferl]

Hi !

I suggest implementing Problem Management.
You create a problem-record for each problem and all open incidents can be closed with reference to that record.
The problem record itself should contain a counter, how many incidents were opened due to that problem ( at least - better it it contains references to the actual incidents ).
Also it should contain a reference to the RFC which should fix the problem
( if there is already a solution for the problem identified ).
As soon as the RFC ist implemented, you close the problem record.

regards
ferdinand glatzl

[ianm]

Thanks all.
Dboylan you are right wrt insufficient funding for the resources necessary to resolve Incidents that are outstanding due to unimplemented Change Requests.
I had put in place a strategy to segregate the number of open Incidents that aren't pending a Change from those that are pending a Change, but I was just looking for assurance on this was the way to go in line with ITIL.
Ferl - To create a problem-record for each problem and all open incidents can be closed with reference to that record would result in a thousand problems substituting for a thousand incidents.

I am going to treat the incidents and RFCs separately, and introduce better queue management. As long as the proper documentation exists linking the incidents and RFCs then all aspects of the initial call will be dealt with.

[Alok]

Hi Ianm,

Understanding your scenario, there is no mention if we have a work-around for the situation where the user are not able to get margin in the report, or not.
If at all you have a work-around and the business is functioning(with some impact ofcourse), then as per ITIL a problem ticket can be raised for this issue.
Every new incident should be given the work-around and closed.
The problem ticket (single PM ticket for this issue) must be updated with the incident reference. The priority of the problem ticket should be well judged based on the impact and urgency.
The resource crunch issue can be highlighted to management, with the evidence that the amount of effort invested in catering to recurring issues, can be re-channelized to effective problem management and thus improve IT service.

Hope, i made sense

[ferl]

That was my opinion, too. But if I understood it right, it's not applicable here.
greetings
ferl