For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Criteria for Problem - Major Incident with "RC" =
Posted: Wed Feb 25, 2009 9:56 am Post subject: Criteria for Problem - Major Incident with "RC" =
Interested to hear opinions on this.
We are working through our Criteria for Problem Creation - essentially, our rules that govern when we will create a Problem record etc.
Major Incidents fall into Sev1 and Sev2 as agreed with the business.
The business are saying:
"any Sev1 or Sev2 with no RC = Problem creation"
so,
"any Sev1 or Sev2 with RC = no Problem creation"
I have tried to explain that they are mixing IM and PM by asking IM to perform RCA.
My questions are:
Is the business correct and should we accept this criteria?
PM do a lot more than driving RC identification so shouldn't we be creating a Problem record regardless of how the business interprets what the RC is?
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Wed Feb 25, 2009 8:02 pm Post subject:
nzmoko,
firstly, you have a problem in that the business is trying to tell you how to manage the services that you are supposed to be managing for them. Problem Management is not a direct business concern.
Secondly, severity of incident is not a primary criterion for raising a problem. The primary criterion is risk of something happening (including recurrence) for which you do not have adequate understanding and counter-measures in place.
When an incident occurs, you will take a view as to its cause (root cause analysis in your head perhaps); you will resolve the incident; you will consider the possibility that it will recur (this often becomes clearer when it has already recurred); you will consider the impact of an occurrence; you will consider the worth of taking pro-active steps to prevent recurrence (i.e decide whether to raise a problem).
To return to my first point. a severe incident occurs; you resolve it; the customer/business quite reasonably asks if this might happen again; you respond either: a) "no because ..." or b) "we are not sure/we believe it might and we are taking steps to be sure/prevent it" or c) "we have thoroughly investigated this and believe the chance of recurrence is minute" or d) "we have thoroughly investigated this and can find no cost effective means to further lower the risk"
If your service is capable of that level of response, then the business will not try to interfere with the nitty gritty of how you go about it. _________________ "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
Joined: May 23, 2008 Posts: 18 Location: Toronto, ON, Canada
Posted: Thu Feb 26, 2009 1:55 am Post subject:
Diarmid makes a valid point. Get the business away from telling you how to manage your business. Also, don't get into mixing IM and PbM. I am implementing PbM here and have just finished fight that battle internally for the past 3 months. Go there and all of a sudden you are getting the call in the middle of the night to lead a resolution because you will be expected to find a permanent solution down the road.
Now that said, you need incidents to reactively look for problems. To that end, I have workign towards the following: Incidents that have no KE. As an example, you can get a SAP error code and the vendor has already done the RC and documented the KE with a workaround and solution (typically apply patch xxx). If we already know this, then why spend the effort to do it again. Let IM take care of it. Now I'm a realist and figure that there is a chance that this can happen again so I use trend analysis to look for these things. As an example, we had a code problem that was "fixed" with a patch however we got further incidents on it. My trend analysis caught this and upon investigation I leanred that the patch was only applied to people who called about it. Well guess what? 5% of the user population was calling each month. We opened a change to apply to patch to everyone and 5 months later, not one single incident logged.
Joined: May 23, 2008 Posts: 18 Location: Toronto, ON, Canada
Posted: Thu Feb 26, 2009 4:01 am Post subject:
too funny UK think we missed one very important role though, the CIO. I'm thinking R2D2 because know one knew what the heck he was saying or where he was going kinda like IT leadership
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu Feb 26, 2009 4:15 am Post subject:
UKVIKING wrote:
check the v3 sixth book posts in the miscellaneouse forum
This sound advise is popping up in about half of John's posts this week.
Either he is on commission or he is trying to compensate for some of his more grumpy posts.
Or, perhaps he is on something else today?
but not confused! _________________ "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
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
