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.
Posted: Mon Jul 23, 2007 8:49 pm Post subject: Deadline on Problems?
Hello PM's,
I hope that you can give me some good ideas and answers about deadlines for Problems.
Until now my company isn't working with deadlines for Problems. We just try to reach a possible quick commitment to Problems. But this goal isn't really working well and it is hard to follow up.
Now we are thinking about setting up Deadlines on problems (graded by severity of problems).
Do you have any experiences with deadlines on Problems? Is it working well? And what timeframe have you set up for the deadlines?
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Tue Jul 24, 2007 8:46 pm Post subject:
Deadlines on problems are like trying to answer the following question
I have a piece of string... how long is it ? every answer is different
What needs to be done is Problem Mgmt needs to categorize and guessitmate how much time shoudl be spent on a problem and be reviewed on a periodic basis _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Posted: Thu Jul 26, 2007 12:19 am Post subject: deadline - different approach
Hey,
ok, let's see it in a different way. At the moment we have no kind of time frame on problems - that causes many problems to stay untouched a long time.
Should there be a kind of default planned finish date for problems (depending on the severity of the prob)?
Or is it efficient to force people to estimate a finish date after analysing the problem?
Generally speaking, we like to have a kind of deadline, which motivates the problem solving site to react quicker to problems. And it would be great if that can be followed up by a good KPI.
It's not about how long this time frames should be, only if it would be good to have a kind of deadline at all?
Perhaps some of you had some similar thoughts and might give me a good hint, how to approach this?
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Fri Jul 27, 2007 5:15 am Post subject: Re: deadline - different approach
Hello Dena,
I may be wrong but it sounds like you don't have accountable Product and Service Owners.
When Problems are identified, they should be "assessed" (i.e. given a Severity, Priority, etc.) and then "assigned". Unlike an Incident, which gets assigned to a person and/or organization whose job it is to put out the fire, immediately, Problems are long burning fires (for example, a defect in software).
If you're like most enterprises, you're probably collecting many problems, all day, every day. Problems require things like planning, design, development, rollout, testing, etc. and take a different path toward resolution, than do Incidents.
As a result, most Problems get thrown in a bucket, to be dealt with based on the capacity for teams that own those problems to do the work.
Now, with that being said, there are definitely varying degrees of importance in the Problems you collect. Done properly, you will have buy-in, by the appropriate stakeholders, as to those rankings. Once you have this, you can report on who's doing the work, when it's done, how long it will take them, etc.
When you get commitment by the group of key stakeholders, it gets easier to make the work happen.
Also, to go back to the accountable "Owner" topic. If you have "named" and "accountable" Product and Service Owners, you can assign those Problems to their appropriate owners and report on their progress, out to the organization. Trust me, if they know you're reporting things out, with their names on it, the last thing they want to see is "red" next to their names and organizations. The color Red, in publicly communicated reports will get people moving. So, if you're not doing it already, I recommend you publish your reports to the leadership and to the general public, regularly. The color Red on Dashboards, next to their names, is always a quick way to get people engaged.
thanks for your answer! I must admit to have run in a wrong direction thinking about kind of deadline. In the meantime we discussed a lot about this idea. Thinking about it made clear to me, that this kind of pressure will not improve the work on problems. Anyway...
Yes, we do have Product and Service Owner in our organisation, but until now they are not explicitly tied into our problem mgmt. process. The set up of this service owner concept isn't that old, and the process wasn't adopted to that changes yet. But we are going to change this anyway.
And therefor i like your idea of pointing out peoples responsibility (perhaps even with red coloured figures).
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