Is there a such thing as too many problems?

[mitter]

Hi All,

I have been receiving negative feedback on the number of active problems residing in the queue. The feedback received is that an average of 40 problems is too much. (note, these are problems waiting on changes, stalled..etc)
In my opinion, having identified problems is not a negative, no matter the number.. thoughts??

also.. Do you have any feedback on what to do with problems where the support has advised that yes, this issue occurs, and more incidents will be logged, but we are not concerned with it.. Should this be a Known error, or the problem record resolved and the info added to the Knowledge base.. and if you do close it,do you continue to relate incidents to the closed problem???

[UKVIKING]

Mitter

A couple of questions

Is problem mgmt merely an extension of incident or is there a dedicated team for PM
How many people are Problem Management staff - full time - or part time
How many problems can be classified as application, databases, operation system, hardware, network etc
How many of the staff cover each of the above disciplines

Does the PM mgr review with the PM team on the outstanding problem tickets and determine how much time should be dedicated to each one and by what team and set some 'milestones' for achieving things

For those that are awaiting changes, what is causing the delay
testing ?, scheduling ?, writing the change, buidling the change ? third party dependence ?

Where is grousing coming mgmt, the ticket tool admin etc.

IF you produce reports stating the progress or lack and the reason, then the grousign should stop
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[mitter]

There is a dedicated Problem Manager, however in regards to Problem Analysis, there is not. The support team is assigned the problem and from there it is given to the appropriate skilled person.

The PM mgr does review the problems with the team(frequency based on impact), but does not have input into how much time should be dedicated. That is pretty much decided by the Problem Analyst and their manager.

Most of the PM's awaiting change are waiting on project completion, or are stalled because it has been decided they are low priority (idenitifed though incident trend analysis)..

I guess the reason for the "grousing" is that the tickets are still open.. The reson for my second question.. When a ticket is deemed low priority and we have no plans to implement the fix in the near future should it be resloved even though new incidents will be opened..(Knowledge Mgmt does not exist). Currently I place them in stalled

[UKVIKING]

Because they are not solved for any reason, stalled is a good state

It may be because you dont think the expense of the fix is worth the issue.

It also depends on how your tool works, if you can 'close and reopen later or close and closed is final woudl dictate whether you do anything

And it also depends on what your PM policy is

if you state ' problems that are staleld for # time or are deemed not worth solving are closed'
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Mark-OLoughlin]

Hi,

you shouldn't have a number but you can baseline the number of problems and keep an eye on it that way.

Also if a problem will not be fixed for the reasons stated - close the problem. Make sure you have your problem management process updated to say how and when this happens (i.e. the conditions).

If the problem keeps reoccuring you will build up problems records that can be used to justify getting it fixed. If you have too many problem records it can take time in the admin in dealing with them.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant

[Skinnera]

Having a large volume is not necessraily 'bad' - it depends on the size of your org, infrastructure, etc; it's the variance to the norm that you need to watch.
Trend the data, always try to drive it down, but flag and escalate when it goes up!

[m_croon]

A couple of years ago, I worked for a client where at the service desk they actually celebrated the 50.000th caller of the year. So what did they celebrate? The 50.000th disruption (!) or the 50.000th employee who was willing to call the service desk?

I guess it has a lot to do with politics and PR. If you have a lot of problems, and you are able to explain to business that you create added value through PM by reducing the stress put on ICT by the business, there is nothing wrong with a long(er) list of problems.

On the other hand: if you have a long list of problems which are never solved, business will start asking questions. Then the actual "problem" might be in culture, architecture, governance etc.

[UrgentJensen]

I think it's just great you're actually counting them!

UJ

[mitter]

Do you have any suggestions on what to do with the problems that are stalled because they are "low Priority" and are still generating incidents??

We do not have a policy for this.

In a normal process would this be the case??

Problem is opened.. Deemed low priority (not fixing)
work around is created, identified to incident management
Problem is closed and information is forwarded to knowledge management
for the newly generated incidents

Or would you close the problem even though incidents are still generated and continue to relate new incidents to the closed problem...

[UKVIKING]

then write a policy defining what you do with stalled problems

S P E L L I T O UT

so that any one - from mgmt to SD staff know the policy
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Mark-OLoughlin]

Hi,

I am with John on this. If you don't have it defined - then define it in the process document for PM. Decide what you want to do with them.

I take the approach to review ALL problems like this with the business so you need to figure out who you need to review them with. Have the business approve which ones to close (based on IT providing the required technical detail and the business providing the business impact of not fixing the problem).

Once the business says close it - then do it (unless it really want to fight the case which can happen). If the issues arise again, I would create a new problem record and referece / relate it to the others that were closed. Once you get sufficient no. of problems fight the case again based on impact etc.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant

[mitter]

Thank You very much for the information.. That is what I was looking for,suggestions or examples of a policy for this type of issue.

I guess the issue I am having to deal with is the concept of closing a problem record when the incidents are still going to occur.