Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Wed Apr 08, 2009 10:25 pm Post subject:
UKVIKING wrote:
PM team reviewing periodically and reporting on what is in their queue
John,
you make it sound so simple _________________ "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
good day all
just on the SLA for problem management, the client i support has a 14 day sla on delivery of the root cause and proposed solution. while agree that this is a good measure to keep the guys focused on finding the root cause, do you think it will work
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Thu May 14, 2009 1:23 am Post subject:
Renaldo wrote:
a 14 day sla on delivery of the root cause and proposed solution....do you think it will work
Depends what it is meant to achieve and also depends what kind of problems come up.
I dare say there are places where no problem has ever taken more than a week to get to root cause and there might be places where it never takes less than a month.
Now, whether this is indicative of the nature of the problems, the skill of the analysts, amount of time they are able to apply to the work or their degree of willingness to do the work properly and promptly, I cannot say. Nor can anyone else without doing some pretty sophisticated investigation (except, perhaps, for the more extreme cases).
Do you get cobbled solutions from staff desperate to stay within the deadline?
Do you get long drawn out waits of up to 13 days for even the simplest problem?
Do you have an appeal or arbitration system for claims that a particular problem is not susceptible to resolution within this time frame?
How do you decide where to allocate resources between a problem of immense importance and one that is about to fail the fourteen day test?
John said, earlier in another thread, that you will always be short of resource in Problem Management. I think this is true and it kind of makes your SLA problematic ( ).
Why fourteen as opposed to twelve or sixteen; or two or forty two?
How much of your service income is assigned to achieving this? - How much more would you charge the customer to reduce the limit to ten days?
I'm pretty sure there are more questions that need answered before gaining confidence in this SLA and I would certainly have plenty of follow-up questions if I was looking at your actual proposal in situ. _________________ "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
I have implemented an SLA on Problems from initiation to succesful resolution. It is a way of determining whether problem management as a process is under resourced etc.
While the SLA is a "number" the results are important.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Mon Jun 01, 2009 9:05 pm Post subject:
IceCreamMan wrote:
I have implemented an SLA on Problems from initiation to succesful resolution. It is a way of determining whether problem management as a process is under resourced etc.
How do you tell the difference between the effect of too much work and of too little expertise or effort, and of easy or intractable problems, and of poor procedures or communications, and of customer and third party co-operation or procurement and supply timescales?
Do you have sufficient problems to make trending, or other variation analysis, meaningful? (hopefully only if you are in a very large organization with many services and users)
Using a target figure for this purpose is not really to do with service level agreement, but rather with monitoring of performance to feed into improvement initiatives. If you make it an SLA, you still have all the risks of penalty, loss of reputation, etc. for things beyond your control. _________________ "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
I have implemented an SLA on Problems from initiation to succesful resolution. It is a way of determining whether problem management as a process is under resourced etc.
How do you tell the difference between the effect of too much work and of too little expertise or effort, and of easy or intractable problems, and of poor procedures or communications, and of customer and third party co-operation or procurement and supply timescales?
Do you have sufficient problems to make trending, or other variation analysis, meaningful? (hopefully only if you are in a very large organization with many services and users)
Using a target figure for this purpose is not really to do with service level agreement, but rather with monitoring of performance to feed into improvement initiatives. If you make it an SLA, you still have all the risks of penalty, loss of reputation, etc. for things beyond your control.
I agree with all the shortcomings you have identified. WE are startting with a basis of hopefully imporving problem managment in the future. It does not answer or cater for all the potential variables.
Agree, it is merely a "tool" to improve the process, nothing more.
Joined: Sep 16, 2006 Posts: 3544 Location: London, UK
Posted: Tue Jun 09, 2009 7:27 pm Post subject:
Exactly
but Mgmt in their infinite lack of wisdom will try to use your SLA not a guideline but as a yardstick to whack your fingers
You need to make sure the SLAs and its use and the related statistics are used for the good and not for evil _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Posted: Thu Jul 09, 2009 1:52 pm Post subject: Assigning Priority for Problem
entivo wrote:
What I said about our own tool (a commercial product from a major player), is that it treats the prioritization of incidents and problems the same way (with a matrix for calculating how many hours/days you have to get resolution based on severity, urgency and impact).
It came that way (we didn't configure it that way). I didn't like that approach for problems for the reasons stated earlier and have therefore changed the way prioritization for problems works.
I too struggle with our tool, which has an identical prioritisation model for incident and problem (4x4 matrix of Impact and Urgency driving a Priority (a number)). Works great for Incident where a P1 etc. seamlessly ties into SLA's, RTO etc.
Where it falls down is when the same matrix and rationale is used for problem (without the seamless behind the scenes triggering of SLA breaches etc.).
How have you changed your prioritisation model? Keen to understand the criteria.
Posted: Wed Jul 22, 2009 1:00 am Post subject: Re: Assigning Priority for Problem
entivo wrote:
I too struggle with our tool, which has an identical prioritisation model for incident and problem (4x4 matrix of Impact and Urgency driving a Priority (a number)). Works great for Incident where a P1 etc. seamlessly ties into SLA's, RTO etc.
Where it falls down is when the same matrix and rationale is used for problem (without the seamless behind the scenes triggering of SLA breaches etc.).
Having the same parameters (Impact, Urgency, and Priority as a derivative of the other two) and scale (1 through 4) for both Incident and Problem Management does not mean they have to be used in the exact same manner. In fact, they shouldn't, since both processes are different, with different life-cycles, and a different focus (time versus quality). The distinction comes from the way your processes are defined in terms of policies, standards, and procedures that provide guidelines on the use of these parameters.
Take Impact for example. In Incident Mgmt your focus is on the impact of a single event, say the outage of a server that affects 5,000 users. Every time this incident happens, the Impact will be the same. Your Incident Mgmt process should provide guidance on what constitutes an Impact 1, 2, 3, or 4. Let's assume this example would be an Impact 2.
In Problem Mgmt your focus is on accumulated impact of the incidents that are caused by a problem. In our organization we have chosen to closely align the Impact definitions; Problem Mgmt just adds an 'accumulation factor'. This basically means that the Impact of a problem equals the Impact of the incidents that are being caused by it, but can go up depending on the frequency of incidents or based on a number of financial criteria (e.g. monthly cost to support the problem). So in this example, the problem associated with this outage would be an Impact 2 if it only happens once in a while, but would be an Impact 1 if it happens say 5 times a week.
The Urgency definitions for both processes is likely to be more different. In our organization Urgency has not yet been well defined for Incident Mgmt, but it would probably reflect how long the business can do without an IT service before the incident reaches full impact. For instance, it may make a difference whether an incident occurs during business hours, in the middle of the night, or shortly before start of business. In Problem Mgmt, the Urgency indicates the likelyhood that a problem is going to 'hit' us (again) within a certain timeframe. Is it likely to happen again tomorrow or is it something that only happens once per year when we close out the fiscal year? Another factor that we consider is the availability of a 'preventative' workaround, in other words, an action we can take to prevent incidents from happening while we work on addressing the root cause. An example of such a workaround might be an automated script that detects and corrects certain error conditions before they impact the business. This type of workaround is by no means a permanent solution, but it does buy us time and may allow us to focus first on other problems with similar Impact but without such 'preventative' workarounds.
Joined: Jul 24, 2009 Posts: 23 Location: Sydney, Australia
Posted: Fri Jul 24, 2009 5:59 pm Post subject:
shakeyguy wrote:
Do you have suggestions on what to measure to provide good control over the problem management process?
ex. ensure that the problems are actively being worked on if they are not in a stalled status.
Shakeyguy - Do you use different status codes for the different stages at which a problem record is at ? (for example Open, Acknowledged, Under Investigation, Known Error or Root Cause Identified, Fix In Progress, Resolved, Closed)
If so then you can run reporting on the status codes that a problem record is set to, then you can probably start to look at the length of time that the problem records are in the relevant status'. My main question, for each KPI would be,what is the value and business case for each KPI. Once that is established and agreed on, by relevant stakeholders, then KPIs can be implemented and measured upon. This way there can never be an arguement about why a specific KPI is being used and if there is then it can be referred back to stakeholder buy in and sign off. Ofcourse our process will always undergo CSI and these KPIs can be reviewed in time. In most cases it is an "adopt and adapt" approach of formulating the most appropriate way forward and testing it, in practise, then reviewing and refining.
Marcel wrote:
Having the same parameters (Impact, Urgency, and Priority as a derivative of the other two) and scale (1 through 4) for both Incident and Problem Management does not mean they have to be used in the exact same manner. In fact, they shouldn't, since both processes are different, with different life-cycles, and a different focus (time versus quality). The distinction comes from the way your processes are defined in terms of policies, standards, and procedures that provide guidelines on the use of these parameters.
Take Impact for example. In Incident Mgmt your focus is on the impact of a single event, say the outage of a server that affects 5,000 users. Every time this incident happens, the Impact will be the same. Your Incident Mgmt process should provide guidance on what constitutes an Impact 1, 2, 3, or 4. Let's assume this example would be an Impact 2.
In Problem Mgmt your focus is on accumulated impact of the incidents that are caused by a problem. In our organization we have chosen to closely align the Impact definitions; Problem Mgmt just adds an 'accumulation factor'. This basically means that the Impact of a problem equals the Impact of the incidents that are being caused by it, but can go up depending on the frequency of incidents or based on a number of financial criteria (e.g. monthly cost to support the problem). So in this example, the problem associated with this outage would be an Impact 2 if it only happens once in a while, but would be an Impact 1 if it happens say 5 times a week.
The Urgency definitions for both processes is likely to be more different. In our organization Urgency has not yet been well defined for Incident Mgmt, but it would probably reflect how long the business can do without an IT service before the incident reaches full impact. For instance, it may make a difference whether an incident occurs during business hours, in the middle of the night, or shortly before start of business. In Problem Mgmt, the Urgency indicates the likelyhood that a problem is going to 'hit' us (again) within a certain timeframe. Is it likely to happen again tomorrow or is it something that only happens once per year when we close out the fiscal year? Another factor that we consider is the availability of a 'preventative' workaround, in other words, an action we can take to prevent incidents from happening while we work on addressing the root cause. An example of such a workaround might be an automated script that detects and corrects certain error conditions before they impact the business. This type of workaround is by no means a permanent solution, but it does buy us time and may allow us to focus first on other problems with similar Impact but without such 'preventative' workarounds.
Marcel - I like how you guys are applying impact analysis for problems in your organisation. _________________ ITIL V3 Capability - Operational Support & Analysis Certified
All times are GMT + 10 Hours Goto page Previous1, 2, 3
Page 3 of 3
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
