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: MMinaya
New Today: 66
New Yesterday: 66
Overall: 142285

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  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
UKVIKING
Senior Itiler


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

PostPosted: Fri Dec 07, 2007 6:59 pm    Post subject: Reply with quote

mitter,

The problem management team must consisit of a team leader (mgr) and staff.

They, the Problem mgmt team, would have to decide on those long term issues - how much time that is to be done on a particular issue

Monthly status reports would be the best way to tell how long they have spent on an issue

but ultimately it is part of the responsiobility of the problem manager to determine howmuch time is devoted to an issue
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Fri Dec 07, 2007 11:48 pm    Post subject: Reply with quote

Hi,

what I aim for is to try and get the problem to a "resolved" status whereby a workaround or fix has been put in to bypass the problem and restore incidents. The problem is not closed however. Effective problem Management can be partially measured by how long it takes to get the problems resolved in relation to any SLA or notional targets that have been set.

The time it takes to then get the problem from resolved, RCA, solution and closed can take a good deal of time. In addition the error control part of problem management can monitor the time between updates to problem records an set a standard e.g. updates once a week at a minimun to ensure that they are kept up to date. You can also measure the average time from resolved to the solution being implemented to get an idea of how long ot takes on average to implement permanent solutions.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
mitter
Itiler


Joined: Dec 06, 2007
Posts: 21

PostPosted: Tue Dec 11, 2007 12:37 am    Post subject: Reply with quote

"The problem is not closed however. Effective problem Management can be partially measured by how long it takes to get the problems resolved in relation to any SLA or notional targets that have been set"

When you refer to SLA or notational targets, are you referring to Incident SLA's?
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Tue Dec 11, 2007 1:53 am    Post subject: Reply with quote

Hi,

you may have an SLAbased on priority. Some orgs have different SLA's for Incidents and problems some don't. If you have different SLA's you need to haev a way of measuring them which is where orgs fall down. Either the SM tool does not support this or there is too much over head and admin to be done or they do achieve different SLA's for the different disiplines.

So the SLA refers to whatever is in place for Problem Management. In some cases I have set up the same SLA for Incidents as for Problems in reagrds time to fix based on priority. For incidents the SAL is measuered from time of opening the incident to it being resolved and customer agreement has been gained.

For problems the same fix SLA per priority is in place and it is measured from the time the problem is opened until the time that it is "resolved" - basically the same time the incidents are closed. This SLA stops.

Some places had a different measurement from the time problems are "resolved" to the time that the are closed which can take daye, weeks, months. etc.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
mitter
Itiler


Joined: Dec 06, 2007
Posts: 21

PostPosted: Tue Dec 11, 2007 11:14 pm    Post subject: Reply with quote

I guess this is where I am confused.
The Majority of the replies here stated that problem fix timescales should not be used (there could have probably been a better word)

In my Org the targets are based on when the problem record is resolved
(Root Cause found, Solution Found and a Change submitted to implement the solution(or not)

My understanding of the last reply is that this should be measured. If this is correct..Questions I have are

1 - There are so many factors that affect RCA, how can you set a timelimit by implementing Resolution SLA's
2 - If it should be measured is there anywhere that could provide me with examples of Resolution target times..
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Tue Dec 11, 2007 11:38 pm    Post subject: Reply with quote

Hi,

I hope this may clarify things.

I consider a problem to be resolved when a workaround or fix has been put in place which bypasses the problem and gets users back working - basically resolving incidents. A fix to me a temporary solution.
During this time I will measure the problem against a problem fix SLA - which can be the general priority SLA in place.

I consider a problem to be closed when the actual permanent solution is implemented - thisis after RCA has been done and what ever development and testing is required. I do not measure the problem against an SLA once it has been set to a status of resolved as the process of RCA and implementing a solution can be a timely one. I do record the time from resolved to closed though and trend it to measure the average time to implement a solution from the time the problem is resolved to closed.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
mitter
Itiler


Joined: Dec 06, 2007
Posts: 21

PostPosted: Wed Dec 12, 2007 12:33 am    Post subject: Reply with quote

Wow.. I guess now I am more confused.

I agree that part of Problem Management's duty is to provide a work around when Incident Management does not have one. However, normally is that not the duty of the incident manager? Restore services as quickly as possible via work around , then pass it to Problem Management to find the Root Cause?

Then once the goal is accomplished (Root Cause known, work around provided and solution found) either Permanent or Temporary based on business decision, the record is resolved
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Wed Dec 12, 2007 1:06 am    Post subject: Reply with quote

I think that what Mark is referring to is changing the status of the Problem record to Resolved when the Workaround is validated (an interesting concept).

Problem Management's job is to validate potential Workarounds. The source for potential Workarounds could be from Incident Management, Release Management, Capacity Management, Problem Management, etc. Once Problem Management has validated the Workaround, then Mark changes the Problem status to Resolved to indicate to Incident Management that there is now have a viable Workaround to start applying to Incidents.

I don't know that I would use the term "Resolved" to flag Problems as having validated Workarounds, but hey, it works for him. I might use a status of "Workaround Available" since Resolved has connotations of the Problem having been fixed.

I would probably suggest a separate flag in the Problem record apart from the record's status since a Workaround being available has a limited relationship to where the Problem is in it's total lifecycle.

Don
Back to top
View user's profile
mitter
Itiler


Joined: Dec 06, 2007
Posts: 21

PostPosted: Wed Dec 12, 2007 2:09 am    Post subject: Reply with quote

Thanks Don!!
A great idea to include this flag!!

I would like to get your feedback on setting resolution targets for escalation.
Ex. If P1 problem not resolved in 7 days to escalate for action plan
instead of setting a hard deadline for resolution?

Mitter
Back to top
View user's profile
entivo
Newbie
Newbie


Joined: Jan 12, 2008
Posts: 17

PostPosted: Wed Apr 08, 2009 12:23 am    Post subject: Reply with quote

This is an old question but a good one.

The question (paraphrased) is

"Usually when we set a priority value, it means commiting to a target number of days. Should we do this for problems and if so, what should they be?"

The general feeling is that one shouldn't apply a time dependant deadline to a problem priority because the ultimate goal of PM is to find the underlying cause of one or more incidents. One should be allowed to take as long as one needs to go through this process in order to get a permanent fix.

I generally agree with this, although I can't help feeling that by adopting that approach we are effectively saying that all problems are the same priority, which isn't the case in reality.

Maybe a better approach would be to use the priority value as simply that, i.e. an indicator of the order in which problems will be dealt with (regardless of how long they take). So we would not be commiting to getting a priority 2 problem to conclusion within 10 days or whatever. We would simply be saying that when we have multiple problems to deal with they will be handled in priority order. So maybe all P1 problems must be driven to conclusion (at least to change management stage) before P2s are looked at etc (or whatever you organization is happy with - another thing that the SLA could provide).
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Apr 08, 2009 6:57 am    Post subject: Reply with quote

entivo wrote:
Usually when we set a priority value, it means commiting to a target number of days...
...I generally agree with this, although I can't help feeling that by adopting that approach we are effectively saying that all problems are the same priority, which isn't the case in reality.


This is a misunderstanding of the concept of priority. The purpose in setting priorities is to resolve conflicting demands for scarce resources (like technical specialists or the test machine). A good priority system will ensure that the resources will be focussed on areas of greatest gain in terms of cost and risk and value.

For this reason, priorities are derived from urgency and impact and this is just as true for problems as anything else. but don't forget that you should be comparing the resolved state with the workaround state, not necessarily some failed state.

Because problems are unpredictable in their nature and because, by virtue of the fact that it is a problem, you cannot predict the resolution at the outset, it makes little sense to apply time objectives as general measures unless you are dealing with very high numbers of problems. Nevertheless a look at urgency will establish a "desirable" resolve time.

The real problem is how to measure the performance of the Problem Management function if you cannot use these easy-peasy metrics.
_________________
"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
entivo
Newbie
Newbie


Joined: Jan 12, 2008
Posts: 17

PostPosted: Wed Apr 08, 2009 5:57 pm    Post subject: Reply with quote

Diarmid wrote:
This is a misunderstanding of the concept of priority.


Diarmid,

Actually I do not mis-understand the concept of priority. I understand it perfectly well, but thank you for your concern.

The point I am making is that priority is usually interpretted by others as having a value in terms of number of days/hours to fix/resolve.

For example, the software we employ uses a priority matrix for both problems and incidents, where a P1 is 15 mins to diagnose and 3 hours to fix. You get the idea. This was not configured by us, it came out of the box like that. We have changed it to better reflect the nature of problems.

What I am saying (in my first entry) is that this may not be the best approach for problems, as by their nature they need as long as it takes to establish the root cause and derive a permanent fix.

The Impact v Urgency equation rings true, but it's up to the individual organization to derive what the impact and urgency criteria are. For example part of the impact may relate to the daily cost of an outstanding problem being 10,000 either in direct costs or lost revenue.
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Apr 08, 2009 6:42 pm    Post subject: Reply with quote

entivo,

perhaps I spoke over-bluntly. I did not doubt that you understood this. It was the way you phrased your statement that misrepresented the issue.

It does not make sense to worry about excluding overall time constraint criteria from Problem investigation and resolution, on the grounds that someone (or even many) might think that that implies there is no prioritization.

After all, you will still have a priority assigned in each case, and you will have procedures in place that tell people how to go about their Problem Management activities, including conforming to priority demands.

I have seen enough to suggest to me that the concept of priority is poorly understood by many people, and in many more ways than the one you identify. But the way to tackle that is through education and stop buying dreadful software designed by amateurs, not by compromising procedures.

Even for the resolution of incidents a priority matrix simplistically tied to fixed target times is appallingly poor. If that is what you have, then it is an obvious target for a service improvement initiative.
_________________
"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
UKVIKING
Senior Itiler


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

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

PM team reviewing periodically and reporting on what is in their queue
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
entivo
Newbie
Newbie


Joined: Jan 12, 2008
Posts: 17

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

Diarmid,

I think that we are in fact agreeing.

I have never said that there is no need for prioritization of problems. In fact, it's vital for the success of the process. What I have said is that problems need to be treated differently to incidents when it comes to priority.

And I think this is what you are also saying. (?)

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.

Priority isn't a difficult thing to understand, so I am not sure why so many people interpret it differently, but they do. On the Problem Manager Practitioner course recently there was a mock exam question about this and everyone gave a different answer.
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  Next
Page 2 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.