Repeat Incidents - to be or not to be ? That is the question

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
silky666
Newbie
Newbie
Posts: 1
Joined: Mon Jul 16, 2012 8:00 pm
Location: UK

Tue Jul 17, 2012 11:57 am

OK first post - and I have serached and I am still confused.- So here is my issue:

At what point and using what 'triggers' do you re-open an incident (ie: repeat) ?

This is what we are currently doing (I wont go into the politics and culture issues that we have, which is causing the concern/'hole' in the process) ... but would appreciate if you think this is a good 'framework'.

Major Incident set to resolved - with a 48 hr washup meeting planned (in which we can downgrade if needed / handover to problem etc)

If an event occurs again that looks like it is the same as the incident above : - what triggers should we use ? (same ci / same impact / within the 48 washup .. anything else ?? ) to decide to re-open the MI above.
ie: a repeat incident.


Thanks for help in advance.


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Tue Jul 17, 2012 2:27 pm

A recurring incident is a new incident each time. Reopening a closed incident record is not a sensible approach.

If an incident record has been closed then the customer/user is satisfied that it has been resolved (i.e. they acknowledge that normal service has resumed.

If another incident occurs then, once again, you have to manage it to resolution. It helps more than a little if you open a new incident record with the specific details that apply on this occasion (certainly the time of occurrence will be different from the earlier incident, but so might also be the people affected, the level of impact to the business among many other details.

When an incident occurs you may well recognize the symptoms as being the same as a previous incident, but at what point do you know that it has the same cause?

I don't understand how you can downgrade (whatever you mean by that) an incident once it has been resolved - whatever gradings it had were for the expediting of its resolution which has now been achieved.

The phrase "handover to problem" is misleading. An incident cannot be handed over to problem management as any efforts to deal with an incident must, by definition, be under the control of incident management. What you can do is raise a problem with reference to the incident and what you know about its threat and cause.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
Boydness
Itiler
Itiler
Posts: 24
Joined: Thu Aug 02, 2012 8:00 pm

Thu Aug 09, 2012 8:38 am

silky666 wrote:OK first post - and I have serached and I am still confused.- So here is my issue:

At what point and using what 'triggers' do you re-open an incident (ie: repeat) ?

This is what we are currently doing (I wont go into the politics and culture issues that we have, which is causing the concern/'hole' in the process) ... but would appreciate if you think this is a good 'framework'.

Major Incident set to resolved - with a 48 hr washup meeting planned (in which we can downgrade if needed / handover to problem etc)

If an event occurs again that looks like it is the same as the incident above : - what triggers should we use ? (same ci / same impact / within the 48 washup .. anything else ?? ) to decide to re-open the MI above.
ie: a repeat incident.


Thanks for help in advance.

I agree with Diarmid.

We discuss/report the previous days Incidents every morning.

Our policy with Incidents, is that if the Incident occurs during the same reporting cycle (<24hrs), it is reopened, if it appears that it was not truly resolved as originally believed (when it was first closed). Occasionally, we may have an Incident that covers a degraded period of time, so you have something "flapping" so instead of opening an Incident every 5, 10, 15 mins, etc. 1 incident covers the entire period of degradation.

A new Incident is opened after the daily reporting cycle is closed, if the Incident was closed during that time.

The Incident(s) are flagged for problem management review, for consideration of possible problem management investigation. Sometimes there is not enough forensics to indicate a Valid problem, if the Incident(s) cleared prior to isolation.

Once you have a restoration of service, that Incident is done and over. A new Incident should be opened each and every time. That will afford your problem management the information that they need, reopening an Incident should be avoided, especially as it will affect the ability to truly understand the scope of the problem.

Any time they consider re-opening the Incident, that should be a new Incident and the situation should be flagged for Problem Management review.


Boydness
User avatar
rudytucci
Newbie
Newbie
Posts: 2
Joined: Sun Sep 30, 2012 8:00 pm

Mon Oct 01, 2012 10:02 am

in my organisation we leave a 72 hour grace period from the time an incident is Resolved to the time the system automatically closes the case.
My question is regarding this grace period, where in ITIL does it state that it should be in place and it should be 72 hours?
We have an internal debate of which i contend that the practice stated above is a business policy and not ITIL standard
User avatar
rudytucci
Newbie
Newbie
Posts: 2
Joined: Sun Sep 30, 2012 8:00 pm

Mon Oct 01, 2012 10:02 am

in my organisation we leave a 72 hour grace period from the time an incident is Resolved to the time the system automatically closes the case.
My question is regarding this grace period, where in ITIL does it state that it should be in place and it should be 72 hours?
We have an internal debate of which i contend that the practice stated above is a business policy and not ITIL standard
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Mon Oct 01, 2012 12:15 pm

rudytucci wrote:...where in ITIL does it state that it should be in place and it should be 72 hours?
Nowhere. In fact the generic question "where in ITIL does it state that X should be in place and it should Y?" gets the same answer - nowhere.

ITIL does not say anything should be or happen and there is nothing in ITIL that belongs to a category "ITIL standard".

Of course it is a business decision. The question that puzzles me is what this grace period is for. The incident has been resolved the moment that the user(s) have the service restored and are able to do what they were attempting when the incident occurred. And this is irrespective of whether they are using a workaround as part of the service, or the whole service is now working as it ought.

If there is a further failure (with the same symptoms and perhaps the same cause) whether ten minutes later or 72 days later, then what is to be gained from concealing this fact in your records by not raising another incident report? You may have one problem to resolve, but you do have a second incident that needs attending.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Post Reply