Implementing Problem Management

[pcolnaghi]

Can anyone give me a brief description of how they run their Problem Management function? I'm responsible for carrying out this function for my IT Dept., but I'm struggling in raising the profile in the eyes of Operational IT Managers who are used to investigating the cause of ongoing issues in their own "style"!

Does anyone have any practical experience of introducing Problem Management into an established Support environment?

We have a well-established Incident Management function, an ITIL-complinat tool (Peregrine ServiceCenter v5), a Change Management function and my immature Problem Management function.

Where we are lacking is although I can identify Problems from Incidents logged (and we're concentrating on high-priority Incidents to begin with), and I have Problem records logged with Incidents associated to them, I'm struggling to translate these into demonstrable investigative work for our Support Teams. They aren't used to the Problem Management role, and I'm having difficulty deciding how to approach them.

[RS200TEZ]

I would try focusing on the effects WITHOUT problem management, what would happen if you do not follow up the incidents. Carry out SWOT analysis on your existing environment - with and without problem management.

Going forward-
Ensure all technical specialists have access to the problem management records and that they have an incentive to assist - resolve - communicate (update records).

In my experience - managers need to ensure that all engineers responsbile have the involvement in problem management as part of their objectives and job role description.

I hope this helps?

[pcolnaghi]

Thanks for the reply, it is indeed of some help!

Can you explain the term "SWOT analysis"? The way we operate now means that the teams seem happy to keep addressing the same incident over and over without feeling the need to remove the root cause!

Can you give me an idea of how to incentivise them? Should it be as simple as explaining the ideaology behind Problem Managment (less calls, less incidents, less hassle?)

[RS200TEZ]

Ok -

SWOT - Strengths, Weaknesses, Opportunities, Threats....

Brainstorm 2 scenarios a.) Service with Problem Management and b.) Service without Problem Management.

These must be applied to the environment you are in....

If Problem Management is the way to go....
you need to energise, motivate, exctite and show a "Can-do" attitude - filter this down to all involved.

To get the "buy-in" of engineers is difficult.
Try these ideas:
1.) Offer a voucher scheme for each Route Cause fixed (£10 CD voucher)
2.) Make it part of their job roles and objectives
3.) Show them the benefits on their job role of RCA and problem management


Provide a knowledge base and a quality method of communication for the solutions and a suggestion box!

Please feel free to ask more questions.

[pcolnaghi]

Thanks for this - excellent ideas!

[javierarcal]

Hi Good afternoon,

If you are using Peregrine Service Center 5 you should know that Peregrine calls "Root Cause Analysis" the module to deal with "problems".

Do you have this "root cause module" implemented or are you using Service Center "essential" package?

If you do not have "root cause", you can establish links between incidents , as soon as you have identified a "problem" you can record it as an incident, and associate to their "incidents" associated (Peregrine allows that) but this is only a "work-around" solution....you should buy "root cause" module to deal in a proper way with problems.

Hope It helps
Javier
_________________
--
Javier G. Arcal
PhD Engineer by Universidad Politécnica de Madrid
ITIL V3 Accredited Trainer
ITIL Service Manager® Certified by EXIN
ITIL Foundation® Certified by UK ISEB
ITIL Consultant and Trainer
Email: javier.arcal@gmail.com
MSN: javierrmad

[pcolnaghi]

We do indeed have and are using the Root Cause Analysis module in ServiceCenter. This is providing me with the ability to log Root Cause (Problem_ records, and associate Incidents with these records.

I can also associate Changes, whether they be the cause of the Incidents or provide the permanent fix to the Root Cause issues.

Where I'm struggling is getting the buy in from my resolver groups, and the Change Managment process owners. I'm also unsure of how to record and manage the investigative work required to resolve our problems.

Some of the ideas suggested by RS200TEZ might be the way to go. I'd also like to hear about any practical implementations of a Known Error/Knowledge database - do you know how these are handled in ServiceCenter v5?

[javierarcal]

Hi,

I have implemented RCA and the main problem I have found where with clocks, in order to manage if problem management (or root cause as peregrine calls) are into admisible levels for an agreed SLAs you need to manage and control "clocks" in Service Center 5.1

I remembered this concept was quite confusing, due to the start and stop functions associated with different states for the RCA tickets, especially when an RCA enter into a state like "pendidng vendor" out of the main state flow.

You know you need to define in apm.clocks.g form you clocks and you need to define any new state you need to have an RCA if this state is not in the out-of-the box product

I Have some documentation about how I have dealt with it, I am not sure this is going to help you, but if you want I can mail or ftp to you.

Contact with me in javierrmadrid@hotmail.com

Regards
Javier
_________________
--
Javier G. Arcal
PhD Engineer by Universidad Politécnica de Madrid
ITIL V3 Accredited Trainer
ITIL Service Manager® Certified by EXIN
ITIL Foundation® Certified by UK ISEB
ITIL Consultant and Trainer
Email: javier.arcal@gmail.com
MSN: javierrmad