Deadline on Problems?

[Dena79]

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?

bregs and thanks in advance for your answer,
Dena

[UKVIKING]

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

[Dena79]

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?

Bye,Bye,
Dena

[Guerino1]

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.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL

[Dena79]

Hello Frank,

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).

Thanks a lot for your helpful comments,
//Dena

[Guerino1]

Dena,

You're very welcomed and good luck.

Please always feel free to reach out to me directly, if you feel I can help you in any way, at: Frank.Guerino<@>TraverseIT.com.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL

[mitter]

Hi Frank,

I really got a lot of help out of your post!

This may be much to ask, but do you have a sample template for the type of report that you are talking about??

Thanks
Mitter