Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: EStover
New Today: 15
New Yesterday: 42
Overall: 148426

People Online:
Visitors: 56
Members: 1
Total: 57 .

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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 - Problem Fix timescales
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problem Fix timescales
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Wed Apr 08, 2009 10:25 pm    Post subject: Reply with quote

UKVIKING wrote:
PM team reviewing periodically and reporting on what is in their queue


John,

you make it sound so simple Twisted Evil
_________________
"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
Back to top
View user's profile Send e-mail
Renaldo
Newbie
Newbie


Joined: May 13, 2009
Posts: 1

PostPosted: Wed May 13, 2009 10:29 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu May 14, 2009 1:23 am    Post subject: Reply with quote

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 ( Twisted Evil Twisted Evil Twisted Evil ).

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
Back to top
View user's profile Send e-mail
IceCreamMan
Newbie
Newbie


Joined: Mar 05, 2009
Posts: 13

PostPosted: Mon Jun 01, 2009 7:56 pm    Post subject: Reply with quote

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.

Regards
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Mon Jun 01, 2009 9:05 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
IceCreamMan
Newbie
Newbie


Joined: Mar 05, 2009
Posts: 13

PostPosted: Tue Jun 09, 2009 6:59 pm    Post subject: Reply with quote

Diarmid wrote:
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.


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.

But we have to start somewhere.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3318
Location: London, UK

PostPosted: Tue Jun 09, 2009 7:27 pm    Post subject: Reply with quote

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
Back to top
View user's profile
nzmoko
Newbie
Newbie


Joined: Aug 29, 2008
Posts: 17

PostPosted: Thu Jul 09, 2009 1:52 pm    Post subject: Assigning Priority for Problem Reply with quote

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.
Back to top
View user's profile
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Wed Jul 22, 2009 1:00 am    Post subject: Re: Assigning Priority for Problem Reply with quote

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.
Back to top
View user's profile
Caperz
Itiler


Joined: Jul 24, 2009
Posts: 23
Location: Sydney, Australia

PostPosted: Fri Jul 24, 2009 5:59 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.