Problem Management Meetings

[Susannah]

I am a Problem Analyst and we are currently implementing Problem Management. Can anyone tell me if they currently hold Problem meetings for all Problems raised or just the ones that seem to not be moving along in a satisfactory manner?

Thanks,
_________________
Susannah

[UKVIKING]

To be honest....you should decide that

You being the Problem mgmt team

you decide what problems to work on
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Guerino1]

Hello Susannah,

If you're a typical IT organization, you will collect, log, and track far more Problems than you can possibly fix. This will put you in a position of having to do two things:

1) Effectively prioritize what should get fixed first.
2) Assign Problems to appropriate Product, Service, and Process owners

#1 will allow you to focus on what's important and not over extend yourself.

#2 will ensure that those teams who are assigned Problems are constantly working on improving "their" Problems, proactively, and in a concurrent/parallel manner.

Remember, all Product, Service and Process teams "already" do their own forms of traditional Problem Management. It's called "Defect Tracking" or "Defect Management". Unlike ITIL which really is more about managing Problem "across" all Products, Services, and Processes (i.e. a "horizontal" approach), Defect Management is about performing Problem Management "within" a given Product, Service, or Process (i.e. a "vertical" approach). Product Management and Engineering teams have been doing this for many decades, long before ITIL was in place. To make ITIL effective, use the horizontal ITIL Problem Management process to "feed" into the vertical Defect Management process of each team. This will allow you to "delegate" Problems to the right teams.

Now, you will have a new issue to deal with... You have to standardize the tool that all teams use to track and manage their Problems/Defects. If you can do this, as they fix the Problems/Defects, the status and information they put back into the system will automatically flow back up to you, giving you instant data, information, metrics, etc. about what Problems are being fixed by what teams, how fast they're being fixed, how long they've been opened, what severities the fixed or open Problems have, etc. etc. etc. The tool you pick will have to, both, allow the individual teams to effectively track and manage the Problems/Defects they work with and it will also have to allow the Problem Management team to do the things it needs to, in order to function within the realm of ITIL recommendations.

NOTE: A side effect of standardizing the tool that links the vertical Defect Management to the horizontal ITIL Problem Management is that individual teams are always finding and fixing Problems/Defects that you will know about and that will automatically link into the inventory of all Problems/Defects that are being worked on by the enterprise. Remember, the Problem Management team can't do it all. Legitimate Problems/Defects are being identified and tracked by many different parts of the enterprise. If you link those inventories into your own, you get "free" Problem Management from each of the vertical teams... allowing you to accomplish far more when you perform your own PM functions.

Problem Management becomes VERY easy if you tie it to the Defect Tracking/Management functions of all your Product teams. Two critical dependencies, here, are that you will have to 1) identify each and every Product, Service, Process and put them into centralized catalogs so that you have complete inventories, and 2) each and every Product, Service, and Process will have to be assigned formal "owners" that will be held accountable for the quality and strategic visions for those Products, Services, and Processes.

If you can do all of this, then you're only function in ITIL PM is to function as the Problem "police"... constantly looking across the entire environment to identify or recognize Problems, assigning them, making sure people are working on them, providing metrics to prove success, etc.

I hope this information helps you with your endeavors.

My Best,

Frank
_________________
[Edited by Admin to remove link]

[Susannah]

Thank you so much, that will definately help. That was the kind of reply I was looking for.

Thanks again
_________________
Susannah

[pdw1975]

Hi Susannah

I guess you're trying to find out what others do, in order to try out what you will do. Here's what I have expereinced works pretty well.

Roles within the Prob Mgmt meetings are;

Prob Mgr (or regional ones depending on size of organisation) - PM
Problem Owner - PO
Service Owner - SO

PM responsible for chairing the meet. They formulate a list of the Problems to be discussed at weekly meet based on 1) a 'next update' date as entered by PO 2) priority of problem. This keeps it down to a manageable list.

Only brief updates and authorisation for closure are discussed - don't get too bogged down woth specifics (think of a meeting as the 'tracking, monitoring...' part of the process)

PO gives and update on the Problem aspect (RCA work). SO gives update on the KE aspect (fixes, whether it will be an agreed accepted risk to the business etc)

The PM will ask specifics if a problem comes up that hasn't given adequate update for a while.

Hope that helps.
Piers.