Target Problem/Incident percentage

[Itilitarian]

Hello everyone,

Is there such thing as a best-practice target/guideline for the percentage of Incidents that should be related to a Problem, on a month-by-month basis.

Our percentage is lower that I think it should be. I believe we can attribute this to needed improvements in Incident classification and overall quality assurance.

Can anyone share their percentages so I can get an idea. I would guess these percentages would depend on maturity levels of the institutionalized processes and maybe even industry and complexity of the organization's IT infrastructure.

Thanks!

[Itilitarian]

On this topic, I think there are a number of factors that affect this percentage in a negative way.

I was speaking to a colleague who's recently come back from the ITIL Practioner Support and Restore training. She shared an interesting story about the instructor's method of getting his point across about the relationship between Incidents and Problems. The instructor asked the audience if everyone agreed that Incidents gave rise to Problems... everyone looked around at the rest of people in the group and eventually everyone nodded in agreement. He then got their attention by stating that's not the case. "Incidents don't give rise to Problems" he said, "................. Incidents are Problems!" The point he was making was that support staff tend ask themselves if a Problem is necessary for each Incident that comes in, when in contrary, the oposite should happen.... Assume it's related to a problem (new or existing) unless you can prove otherwise.

From my experience this is paradigm shift that companies need to make if they're going to become successful at Problem Management. Too often, I've seen support/SD staff say "but we know why why the incident happened....". Ah yes, but what can be done to prevent it from happening again?!? Or they'll say "But there's nothing we can do about it" Ah yes, but what if we uncover exactly how many times the company is impacted by this issue, and we discover it costs less to fix it than deal with it?!?

Another conflicting factor is that some organizations are structured so that the same group who perform incident management are also responsible for conducting problem investigation. In a hectic IT environment, it's easy to see how this conflict of interest can impede the progress of Problem Management, afterall service restoration should always come first!!

Also, as my original note mentioned, Incident classification is critical in making Problem Management a success. If the support organization is not reviewing a Problem/KE database before starting the troubleshooting, they're potentially missing out on key support knowledge that already exists that may very well help them in restoring service for their incident.

These factors among many others will affect how companies recognize Problems and leverage the Problem Management process to its fullest.

I've love to hear from people who have similar/differing views.

[ProbMan]

One factor which has always puzzled me that can skew your stats is the habit of service desks of putting messages on the phones when they have a high level incident to prevent users from calling in. If you don't log all calls how do you know how big the impact is on your userbase.

[eisbergsk]

[szwden]

hi,

i think that problems are defined, where as incidents occur.

because problems are defined, there highly dependent on the categorisation of the incident. on estimating the impact and the problem area.

we have one incident severity of wich always a problem is defined, that severity is "calamity". If a calamity incident occurs incident management works his butt off to resolve hat inciden. afterwards problem management investigates the incident and takes action to stop it from happening again. for us it's the first step to pro-active problem-management.

[Globis]