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.
Joined: Sep 16, 2006 Posts: 3115 Location: London, UK
Posted: Fri Dec 07, 2007 6:59 pm Post subject:
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
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
"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?
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
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..
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
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
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Wed Dec 12, 2007 1:06 am Post subject:
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.
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?
"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).
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Wed Apr 08, 2009 6:57 am Post subject:
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
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.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Wed Apr 08, 2009 6:42 pm Post subject:
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
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.
All times are GMT + 10 Hours Goto page Previous1, 2, 3Next
Page 2 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
