Failed incidents?

[viv121]

Hello All,

Do we know if we have a concept of a failed incident anywhere? Something on the lines of failed change really. I am coming from instances where my infrastructure support teams couldn't resolve the medium priority incident and wanted to know if they can associate them to problem and the rectification could lie in the next release (change). What do I do with the incident? My system allows me to leave the incident opened while associating it with Problem and Change. However, does it beat the definition of Incident which is essentially about 'fix or restore' as quickly as possible? Do I close such incidents while getting the boys to work on the Problem? It doesn't matter to me to be honest, but the stats guy got issues with long living incidents.
_________________
regards,

Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill

[UKVIKING]

Viv121

Since an incident is according to ITIL when the expected service does not perform as required

A failed incident could be when it performs as required
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[viv121]

That was easy. Wasn't it?
_________________
regards,

Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill

[UKVIKING]

Almost like an exam question as noted below

Who is buried in Grant's Tomb ?
Who were the combatants in the Franco Prussian War ?
Who were the combatants in the Russian-Japanese War ?
What country was fighting in the American Civil War ?
What country was fighting in the English Civil War ?
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[viv121]

I know most of the answers expect the two. I don't know the names of all the French, Prussians, Russians and the Japanese. I think easier question (whilst I sought answer) would have been what/which countries.
_________________
regards,

Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill

[thechosenone69]

thats what they call Normal operation
_________________
Ali Makahleh
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.

“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.

[Diarmid]

Viv,

once I stopped laughing at the wits on this site I had a look at your question.

Firstly: this is a customer issue and any of the ideas below need to be agreed with the customer and not just sorted out in IT.



1. If you are responsible for the functionality that is failing

The issue is very simple. The incident is open until service has been restored, by whatever means. The reason for this is that until service is restored the user is waiting to do something that. Until the user can do that thing the customer business is affected.

If the task is so non-urgent that it can wait undone for a few weeks. Then you just agree that with the customer (not the user). But you would not close the incident. The stats are valid and if it occurs often (even for very low priority things) you have an issue worth looking at and you will only know this if you have stats. (You can always give such incidents a special category to isolate them from other useful perspectives).

If the task has a short shelf-life (i.e. it becomes not needed if not immediately done) then all the costs of the failure have already been experienced, then you no longer have any resolution requirement (i.e. you can close the incident as no longer needed), but you do have a problem requirement to get it sorted before the next requirement for the task, and you may have a series of such incidents before you resolve it, each closed and each providing pain.

If the user/customer achieves their objective by other means, then that is a workaround (even if not by means of any service you provide) and the incident is closed (but no plaudits for IT services) and you proceed as above with the problem.



2. If a separate body such as a software supplier is responsibility for the functionality that is failing

If you can enable the software to run, it is only that function that has to be avoided, for example, then I would think you can raise the bug report and close the incident. The contract with the supplier is where the penalty will lie.



I told you it was simple.

All the above is just a quick off the top of my head idea and it could be rubbish. I think the practical answer is that you talk through the question with the customer and develop a protocol that is mutually acceptable for dealing with such circumstances. I think that there are many possibilities and the nature of the business, the contract and the relationship affect how you do it. What I think you do not do, is decide within IT what to do. It is a customer issue. I'm repeating myself. So I must have got to the end.
_________________
"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

[UKVIKING]

hopefully you were only giggling for the half wits like me...
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter