Posted: Fri Sep 22, 2006 1:05 pm Post subject: papleux dot com update: Get Started on Problem Management
Here is the article. I hope this has some value for you guys.
Get Started on Problem Management Today
Written by Fabien Papleux
Thursday, 21 September 2006
Problem Management is the process of identifying and eliminating root causes of incidents. It is intimately linked to Incident Management as both processes aim at responding to disruptions to IT services. However, while the focus of Incident Management is to restore service as quickly as possible, Problem Management stays behind the scenes and works deep to address the underlying causes of those incidents. The effect is that users get help faster because the frontliners are not busy "fixing stuff" anymore. As much as necessary, the fixing is pushed to the background, and the forefront is now focused on customer relations and business service uptime.
Your first priority should be to establish a plan, appoint a process owner, determine measurables and objectives, gather Executive support, etc etc. You can get this from any books on ITIL and I could write pages about it too. But I would rather discuss the practical things you can put in place to get your organization moving and start harvesting results.
PAUSE. Let's stop for a second before we start. ITIL asks you to define your objectives, determine what you are going to measure, and take a first measurement before you start. That set of data is your baseline. Thanks to that baseline, you will know if the projects described below are working for your organization. I beg you. As much as you want to get started. Do not skip this step. Without it, you will never be able to demonstrate progress and your quest for excellence will end in failure, even though it may have worked perfectly.
Major Incident Process
This is a rather important and easy one. You need to have a Major Incident process in place. If you are looking at ITIL because you experience frequent service outages, this may save you precious hours, and thus money, whenever something big happens. The idea is that as soon as a Customer Support Specialist detects one of those, he/she needs to know unequivocally how to handle it. It has to be very simple and straightforward. ITIL says that in case of a Major Incident, the responsibility for the resolution needs to be transferred to the Problem Manager.
Indeed, most likely, it is out of the scope of the Customer Support Specialist's job to solve this sort of incidents. What you need is the person who has both the technical ability and the seniority to pull together an emergency response team composed of the right people to address the issue in the shortest possible timeframe. The person who is your Problem Management process owner, and who deals with the organization at different levels to ensure the Problem Management objectives are met, is that person.
You will need to define what a Major Incident is. ITIL describes it as an incident for which the impact on the user community is extreme. You could imagine that the unavailability of your main data center would be considered a Major Incident for instance.
Specify the person to call: name, phone number, pager, and/or any other communication method needed to get a hold of that person.
Determine, when appropriate, the elements that should be communicated to the Problem Manager: time, nature and location of the incident, name and phone number of the users reporting the incident, name and phone number of the customer, name and phone numbers of the IT executives who need to be notified, etc.
Also, define a format for a Post Incident Review. After any Major Incident, the IT organization should be able to answer at least the following questions: What happened, How it happened, How it was fixed, what have we done to prevent it from happening again.
Create a quiet zone in Support Operations
One of the objectives of separating Incident Management from Problem Management is to remove technicians from the interruptions of the front line and concentrate on understanding problems, finding workaround that can be applied to other instances of an incident, documenting those problems, evaluating definitive fixes to problems and prepare proper Requests for Change.
You probably cannot get that started if you cannot find a way to allow people to isolate themselves for a few hours. The reality is that as you implement ITIL, you are likely to invite your existing support resources to begin working on Problem Management. Those resources probably work close to the telephone that keeps ringing and if you could just find a way to give them just a few hours here and there, they could start to bring some results.
If possible, find a remote room that the rest of the organization doesn't know about. Lock it. Do not give away the phone numbers to reach that room. Just a few shared desktop space should be enough.
Promote some Service Desk operators to Specialist teams
Facing the problem of staff turnaround on the Service Desk is a challenge. The introduction of the Problem Management process is an opportunity to keep some of the elements that have the most difficulties with Customer Relations and invite them to specialize in an area or another, based on demand.
You will get Increased customer satisfaction because the percentage of Customer Support Specialists with good customer service skills will have increased. You also increased Employee satisfaction because techies will be techies and you just gave them an opportunity to focus on what they like.
Attach them to larger teams so they get a chance to develop further, and you get a chance to introduce Problem Management as a process that goes beyond the Service Desk.
Solve 5 problems per week
Once a Support team has assimilated the concept of Problem Management, it is important to start capitalizing as soon as possible. Before you get a chance to introduce a formal process, re-organize people and deploy a Service Management tool, here is a simple action that can dramatically improve your overall operations.
Charge your team of finding 5 problems in the infrastructure every week, find a workaround, devise a strategy to fix them and present a plan the following week. At the end of the week, during your regular team meeting, review the 5 problems and proposed fixes. Treat those proposals as Requests for Change and discuss them with other areas. Make decisions and solve those problems.
You should start seeing a reduction in number of incidents within a few weeks.
Create a simple Problem Management Dashboard
Pick a metric where you need to make a big difference and make it a poster, a webpage or a weekly e-mail. Witnessing progress gets people on board and soon your staff will ask you how they can take it to the next step.
Let us take the example of Mean Time To Repair. Thanks to documented workarounds, the introduction of Problem Management should start to reduce the average time it takes to resolve an incident. Industry standard says you should be able to close about 80% of your incidents at first level within 20 minutes, no stretch. Take a 3-month rolling average and map it. Keep track of it and promise your team
An organization I have worked with started at 58 minutes. That was a 66% reduction in time to resolution. Even if you achieve only half of that number, that is a lot of money. The good thing with this process is that you sell your team on process improvement and you collect the benefits of increased productivity.
Last Updated ( Thursday, 21 September 2006 ) _________________ BR,
Technology Consulting | Service Excellence
Red Badge Certified
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