Posted: Sat Dec 08, 2007 5:39 am Post subject: Precisely 'When' Do You Create a Probem Record & Why?
We implemented an Incident Mgmt. (IM) process several years ago. We are now upgrading to a newer release of the tool. As we do so, we will also transition our formal Problem Mgmt. (PM) process out of a Notes DB into this same tool. The end result is common and integrated IM & PM Processes using the same tool and clarity among all involved in the processes about the differences (roles, goals & responsibilities) between the 2.
As we work to address and design the procedures for implementing IM & PM concurrently, we've debated at what point we would open a Problem Record. We discussed we would:
1. Need to more crisply (than we do now) define the criteria for identifying a Problem & communicate this criteria to the Service Desk folks.
2. At the time an incident is reported, if it met the criteria for a Problem:
a. A Problem Record would be created at that time. For example: A Priority 1 incident has occurred; i.e. the highest priority incident where multiple users are impacted and unable to perform their main job.
Although the incident will be assigned by the Service Desk to the appropriately skilled individuals to define and implement a workaround, a Problem Record would be created at this time Vs after the incident had been resolved.
This will enable the PM process to immedately become aware of the high impacting incident, and allow an opportunity for them to assist in the identification and the creation of a workaround.
Once service is restored, all relavent detail about the incident will be passed / updated within the Problem Record to facilitate root cause analysis.
The above ensures time and potential for resolving the incident is maximized while minimizing the transition of the details to begin the reactive Problem Mgmt. activities.
Does anyone have insight into why we would not want to manage the creation of a Problem record like this?
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Sat Dec 08, 2007 7:22 am Post subject:
Although having Problems open for the highest impacting Incidents is a good idea, I don't know that you should automatically open a Problem record for every Severity 1 Incident.
Let's say that the building loses power and all the users' non-ups systems go down. Yes, it met the conditions of Severity 1 Incident, but do you really want your PM Analysts doing facilities work to find the root cause of a power outage?
The idea is that the PM Analysts should be mining the Incident database for issues that are related and possibly have the same root cause. Once they have identified a set of potential Problems, they should do a preliminary cost/benefit analysis. Will the cost of investigating the Problem actually achieve a viable return on the investment of their time? If so, then they should definitely open a Problem Record. If not, maybe they should open a Problem record just as a tracker of similar Incidents. Or if the issues are so trivial and infrequent, it's not cost justifiable to open a Problem record at all.
At the point you open a Problem record, you are committing yourself to spending resources (money) to keep track, report, investigate, follow up on, etc the Problem.
Thank you for your prompt response. I get what you are saying about committing resources.
To clarify....I am not suggesting a Problem Record be opened for every Sev 1. I am suggesting that if the Problem Mgmt. team can crystalize the definition of a Problem and an Incident is recorded & it meets those requirements, then - at that time - open a Problem Record.
Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Sat Dec 08, 2007 7:55 am Post subject:
Typically a problem would be initiated through an incident that has a major impact or reoccuring incidents exhibiting same or very similar symptoms.
From practice and experience, criteria for problems are not always clear cut and hence there should be a role that will make that very call: "Let's create a problem." Mind you they will one always use one same and very concrete criteria. Sometime the decision will be fact based and back up by data, already define criteria, etc. Sometime it will be more of a subjective call and based on a good dose of common sense, hunch and experience.
Your service desk or incident manager would typically be the source for originating the problem. If the role of a project manager exists in your organization, it will probably require his/her agreement and approval before proceeding with investigation. In my previous company we did not have that role defined and Incident Manager was activing as a SD manager and Problem Manager (so imagine that )
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum