Hi. Our company has a pretty good foundation and process in place for Reactive Problem Management so I have been asked to help move organizations along with more Proactive Problem Management.

Has anyone been involved with this before and possibly already have a project plan or training presentations that they'd be willing to share that I can possibly tweak for my needs. This would be very helpful to me so I am structured and think about all the steps.

I'm trying to not be tool focused since I'm with a big company and it won't be possible that everyone can use the same toolsets so I was hoping for something more around the basic Proactive PM activities like trending analysis, compliance metrics, etc.

Thanks in advance for any info. I'm sure I missed a lot of details because I was anxious to get this request out there.

It's good not to be "tool focussed" for problem management in all circumstances. Pro-active problem management is about having a strategy to focus on service components and infrastructure in alignment with the business' use (and intended future use) of the services, in order to anticipate what might be detrimental to the services in the future.

In fact, don't even think about tools until you have established policies and objectives._________________"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

Is the questions related to which metrics to measure to identify the best use of your resources towards resolving the problems proactively, so that you can create the process and procedures to foster the identification of the specific areas to focus your resources?

My thought is if you are doing problem management correctly, your reactive problem management should already have the ability to proactively identifying your problems.

You are reviewing your incidents on a regular basis, correct? Do you review the previous day incidents? A weekly roll-up discussion and trending with the Incident Manager and respective Program Managers?

This is sounding quite good basically this is how it grows and i believe that taking it to another level is how the moment works.
What you have highlighted is something that works for that particular time period and that is how it has to be which is fine enough to understand.

But having done thing at enterprise scale I can advise what it looked like for us.

The goal is basically to spot trends and patterns within complex systems and use them to take preventative actions before the incidents / problem occur.
We plotted out our P1 problems (created from P1 incidents) on a linear graph and used root cause codes to identify them individually. Then we performed some simple analysis of the data.

This sounds simple but the more complex the systems you support the more complex that analysis becomes.
We had reasonable success with this and measured by service we were able to reduce like for like P1 incidents.

Problem management has proved to be an elusive process which is not easy to implement. One reason for this is that the process can be understood in different ways. One solution is to have problem management solving all difficult cases but this may well lead to the situation where the problem management team is actually just the second level of the service desk.

A different solution is to concentrate on the proactive approach or risk management. Aale Roos will explain how this works and what the logic in this approach is.

The question comes down to 'why implement proactive problem management'? e.g. what is the outcome the person who asked you to do this wants?

My guess is that they're ultimately hoping to further decrease incident levels (or at a business level decrease costs or increase customer sat).

If this is the case, and you should confirm the true expected outcome - not just what they asked you to do, then step 1 when we go into a business is to look at their problem model. We see two problem models on a regular basis:

1: Problem management as a function, and 2: Problem management as a process.

Problem management as a function:
This is where the business creates a 'team' or 'role' and calls that person a 'Problem Manager' or a 'Problem analyst'. This is great for reactive problem management with regards to managing RCA for P1 incidents. It means that the person can focus on RCA for the big issues within the environment, but terrible for RCA around repeat incidents within Service Operations (this is what people generally refer to proactive problem management - e.g. identifying trends from repeat incidents).

If you are using this model you should look at expanding your Problem "function" to be a Problem "process" and include all "incident managers" within the process.

Problem management as a process:
This is where the team leaders / managers of the functions (e.g. Service Desk, technical support, application support) take off their 'Incident management' hat and put on their 'Problem Management' hat from time to time. This ultimately puts responsibility AND accountability into the hands of the people with the power over their staff to direct their focus each day.

What this basically means is that the people who are dealing with Incidents on a day to day basis, now also have another thought when they resolve an incident or identify a potential incident, that thought being "Should I raise a problem" or probably closer to "is this likely to reoccur".

If the true outcome from an operational level is a decrease in incident levels then this is the way to go.

This way you can develop a 'standard operating procedure' for managing 'minor problems' that can be (and should be) dealt with by the resolver group. This also puts the accountability of reducing incident levels (and provides incentive to the managers) to deliver the expected outcomes of Problem Management.

Taking the 'problem as a process' approach delivers a much better return for the business. My only caution is that when taking this approach, it is best to do so with a reasonably mature Problem Process in place.

Keep Analyzing the facts for previous months years ,check the incident trend .You will automatically move from Reactive to Proactive . I see nice replied on top of mine as well .I hope you already got answer to your question