Where does Problem Management stop?

[noluddite]

Is problem mgmt concerned only with finding the solution or dies it also implement their solution? i feel that its suggestions should be carried out by the Change Mgmt team or Incident Mgmt?

But, shouldn't Problem Mgmt be implementing the change (in a test environment. if needed) to ascertain the viability of its recommended solution? or does it just give the verbal solution and leaves it for the Chane Mgmt or Incident Mgmt to find out if it works.

Any ideas will be appreciated.

[SwissTony]

Briefly work arounds should be recorded in the Known Error Database & then communicated to users via the Service Desk.

For Permanent Fixes the Problem Mgr should work in coordination with the technical teams that assisted in finding the solution to raise an RFC. In which case it would most likely be the tech guys implementing the solution, and the Problem Mgr staying in the loop to be able to monitor the change, and close the Known Error once the permanent fix is successful.

[Diarmid]

1. A reasonable outcome of the management of a particular problem would be the specification of a change and this may have been arrived at by conducting tests and experiments. However it should come to change management as a formally proposed change with proper evidence of correct quality attached.

The above is "this is what needs fixed, and this is how to fix it."

2. Equally a reasonable outcome of the management of a particular problem could be a functional specification of requirement which the business would commission (internally or externally) and which might be owned by the development manager. This would then come to change management by the normal development route. The problem manager would at least keep a watching brief until the product was developed, implemented and proved.

"This is what needs fixed and this the way it has to be different."

----

Both approaches will apply because it would be a waste of time to start commissioning very trivial solutions well within the skill set of problem analysts and it would be a management nightmare if the problem analysts went off on six month development projects just because they know what is needed. where you draw the line will vary from one place to another.

The point is that problem management is responsible for identifying the underlying cause of the problem and seeing that this is addressed by the organization. There can be no hard and fast rule about how involved the PM team becomes in the steps up to implementation since it depends on how your organization deploys its skilled resources.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[BorisBear]

It sounds like you're after a physical answer to a logical subject.

A more useful question might be "where does problem management start" as this is the question that many struggle to articulate a cogent answer to.

[Bluesman]

"The point is that problem management is responsible for identifying the underlying cause of the problem and seeing that this is addressed by the organization. There can be no hard and fast rule about how involved the PM team becomes in the steps up to implementation since it depends on how your organization deploys its skilled resources.
"

This is as close you can get. A very precise piece of text!

Problem Management is just that. Management. Making sure it gets fixed, using the tools available. Your best tool is the "helicopter view". (The second and third IMHO are improvisational skills and good relations to the right people). The PM does not need to be an analyst or even an IT geek. He needs a mandate, though, and a way of knowing who to ask for help.

In some cases, the PM actually has the skills that would help RCA and RFC implementation. Fine. Then let the PM be a part of the solution, maybe as an analyst, or as a part of build&test. If the PM has the skills to package a software rollout - fine. Let the PM do some practical work for the Release process.

Just don´t forget to take the PM hat off while you do practical stuff in other processes. While there, you are just a guest, maybe with special skills, but still.

Once in a while, go back to your helicopter, put your PM hat back on and make sure you still have the helicopter view (and grip) of your investigation(s) and your process = management.
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr

[Marcel]

Keep in mind that for many organizations Change Mgmt is essentially not more than an approval process to get changes into production in an orderly fashion (gatekeeper of the production environment). In other words, the Change Mgmt process does not modify application code. It just gives the approval to go ahead and put it into production after checking certain requirements have been met (i.e. properly tested, communicated to steakholders, etcetera).

It is very well possible that the same people involved in root cause analysis are also involved in developing the fix. Most organizations do not have fully separated teams for these activities. That would not be cost-effective in many cases.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL Certified