Long running or never solved problems

[bennyboy]

Hi,

We have a new PM process in place and most things are working well so far. One of the things we've come across though is that problems are starting to back up and clog up our service management tool (the way we currently manage our support queues).

I'd like to know what other people are doing with problems that will never be resolved?

One idea we've had is to close them (if all stakeholders agree), add an entry in the knowledge management system and link the 2 records together. We would then have to change the "logging a new problem" process to include searching both open and closed problems before creating a new one (to stop duplicates being logged). I'm not a fan of this idea.

If we go with this idea then do we still get the service desk to link all related incidents to the closed problem or known error or is that just beating a dead horse?

Thanks in advance.

Ben

[UKVIKING]

bennyboy

the short answer is

it depends

the long answer is

it depends

the detailed answer is

it depends

It depends on your policy document regarding problem mgmt
it depends on the problem and who is responsibile for solving it
it depends on a lot of things


there are some issues where the solution is more expensive or unachieveable.. .if so, state that and deal with the problem record in accordance with your policy/process etc

we here usually close it with no viable solution w/in timeframe
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[m_croon]

Bennyboy,

Just out of curiousity: what is your problem-workload? How many problems do you register each month? How many do you solve?

It seems odd to me that you have created such a workload of problems that you are about to loose your overview...

[bennyboy]

hahaha yeah this is why we keep going round in circles.

I've actually asked this question because we are trying to decide on a policy to move forward with. The policy affects about a dozen resolution groups and no one can agree .

I'm just trying to find out what other people have chosen to do in these situations and why they chose this route.

[bennyboy]

[UKVIKING]

102 open errors / problems

methinks you have a very broad term for Problem mgmt

Problems - under itil - are incident(s) where the under lying root cause is unknown. AND NEEDS to be found....

If the incident is raised and the root cause is within the software application called - Customer Request Action Program; then, lo and behold, you do not have a problem but an incident w/the root cause being the program - CRAP - and the solution is coming from the vendor / provider that wrote / developed the product. - EVEN if it is an internal group

From the Operational/ production point of view, the incident is on hold until the program has been upgraded.

IT IS NOT PROBLEM MANAGEMENT'S ROLE TO MANAGE THE SOFTWARE DEVELOPMENT of a product

And yes that was yelling

You are most likley mixing incident (itil) and problem (itil) definitions which is screwing you up
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[bennyboy]

[asrilrm]

[bennyboy]

Just had a video conference with the process stakeholders to try and make some headway with this decision so I thought I would let you know what's been decided:

- They've asked for help managing their queues more effectively (good news)
- They've agreed to review all open problems in one big refresh to get us closer to an even keel (they've not done any queue management recently).
They will review:
- Is this actually a problem?
- What is the latest update and when will the next update be (we have an email reminder function to ensure the next update is actually done)?
- I have a fortnightly report ready for them so that they can manage manage their problem records more effectively in the future.

There's been no change of policy (yet) but at least I've got their heads out of the sand again...

I'm still keen to hear about other peoples approaches to problems that will never be fixed btw

Thank you all for your advice and comments so far.

[ozz]

I had incidents that were not resolved as there was no funding / did not care to fix the problem. So that is the work around do nothing and close the incident.
Next call the answer 'we are aware of the issue and we have no solution at this time'. These problems sent to change management but that means nothing when there is no money or caring to fix. From a management point of view we left then with the change folks to keep in their todo pipeline
At some point in time the user community will get tired of hearing 'we are aware of the issue and we have no solution at this time" as maybe that will get some action.
Also you should be reporting weekly XX amounts of incident were closed due to zero funding.

Its like business continuity : "do nothing" is an acceptable response as long as you document it and have foundation /agreement that do nothing is the work around ..
Oz
_________________
Ozzie Sutcliffe

NYC

[asrilrm]

Hi,

I would highly suggest to avoid using frames like "do nothing" as a resolution or a permanent workaround.
The users (internal users or business customers) might seem to agree but be careful as most users don't directly express their disagreement in the round table and later spread bad image about our service.

In my point of view, "do nothing" can only be used as a workaround, only for a very narrow time. The problem needs to be resolved, now or later in the future. If it is about fund or care, then why not freeze the service and concentrate on other beneficial services?

Asril

[bennyboy]

We are bordering on a decision and policy change finally

It needs the nod from the important people upstairs but we've agreed that problem and known error records won't be closed unless they are actually resolved.

We will instead, use a function in our SMT tool that allows us to "snooze" a record which effectively removes it from our to do list (solves the queue management issue) for a defined period of time and them emails a reminder to you when it reaches the end of it's "snooze" period.

We came to this decision because:
1. The problem isn't resolved so technically shouldn't be closed
2. Over time a problem that was judged to be low impact originally may rise in impact and the snooze option forces these problems to be re-assessed periodically.
3. Problems where a fix is scheduled for sometime in the future can be removed from the to do list until just before the fix is scheduled.

As far as I can see this has addressed all of my initial concerns but I'm keen to hear others view points on our approach.

Cheers
Ben

[UKVIKING]

Ben,

You have came up with a solution that meets your requirements

It is similar to ours but... we put the snooze for 3 months and after 3 x 3 months snoozing and if there are no more activity (incidents) we would terminate the offending problem

evil laugh
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[bennyboy]