How to first introduce Problem Management

By ITIL® from Experience©

The following is an approach to first introduce Problem Management. It starts small and usually does not disrupt current responsibilities and work load while realizing highly visible benefits.

Implement a policy that after each Major Incident a root cause analysis must be done and that recommendations must be implemented to prevent the same incident from happening in the future.

The business case

Generic – A business case captures the reasoning for initiating a project or task. It is often resented in a well-structured written document, but may also sometimes come in the form of a short verbal argument or presentation. The logic of the business case is that, whenever resources or effort are consumed, they should be in support of a specific business need.
ITIL® – Justification for a significant item of expenditure. The business case includes information about costs, benefits, options, issues, risks and possible problems. See also cost–benefit analysis.
PPM – The justification for an organizational activity (strategic, programme, project or operational) which typically contains costs, benefits, risks and timescales, and against which continuing viability is tested.

Source: Best Management Practice portfolio: common glossary of terms and definitions
Version 1, October 2012

for implementation is relatively easy to calculate. Look at the last Major Incident and estimate the wasted effort of:
  • IT technicians required to restore the service (e.g. number of technicians involved x hours worked x average salary)
  • The Service Desk to handle the calls (e.g. number of calls x 3 min. x average salary per minute of a Service Desk Analyst)
  • The business (e.g. number of people affected x hours affected x average salary)
  • IT Management (e.g. at least one manager per technician who worked on the incident x 1 hour x average salary)

Even with a rough estimate, most organizations would be willing to hire a consultant to conduct a root cause analysis to avoid the situation from happening again. They might even consider hiring an employee under contract if the organization recently had several high impact Major Incidents. The reason external help should be used at the onset is that the organization likely does not have the skill set in house to conduct a root cause analysis.

To prepare the organization to be self-sufficient:

  1. Select an executive sponsor (e.g. the person who approved the hiring of the outside help or the executive responsible for the last wide scale and costly Major Incident).
  2. Select one root cause analysis technique that is most appropriate for the organization and consistently use it for all root cause analysis. This will get all participants familiar with one technique.
  3. Select an employee and a backup who are good facilitators and trainers as they will have to lead and coach people through the new process. These individuals also need to be well respected by operations staff as people need to trust that the process findings will be used constructively and not punitively.
  4. At the onset, the lead and backup should conduct or shadow the consultant for all root cause analysis. This will help them build expertise in conducting root cause analysis and to bring continuity and consistency between exercises. This will also get participants familiar with the style and expectations of the facilitator which in turns increases buy-in (don’t forget to involve the backup resource to develop their skills as well!)
  5. Send the root cause analysis lead and the backup on training for the technique selected. If it has a certification program, get them certified.
  6. Lastly, modify the Major Incident process to add a task to initiate the root cause analysis process as this helps institutionalize the use of the technique.

Major Incidents by definition are highly visible, therefore it’s easier to have the implementation oversight required to ensure that recommendations are actually implemented vs. regular process improvements that usually are treated with a lower priority. The owner of the service that suffered the disruption should be made accountable to implement the recommendations, even if it involves cross-functional groups.

Although this is not the complete Problem Management process it enables the organization to get familiar with one aspect of the process and to implement some highly visible improvements.

Another key point is that by using Major Incidents as a trigger to initiate a root cause analysis people can slowly get used to this new way of doing things since, in theory, Major Incidents should not be happening every day.

Last updated on: 2016-06-30

Try harder next time...is not a problem management method mentioned in ITIL®. D.Matte

More Quotes


More on Problem Management

From Around the Web:

ITIL Process > Problem Management


Copyright 2012-2015 - ITIL® from Experience - D.Matte