The Problem with Processes

processpic

A process is a process. However, the use of a process should come down to addressing a need, it must be practical and easy to use. Sounds simple, right? Well, no….   Here’s a story!

Customer ABC had implemented problem management, to help reduce incidents overtime. They had the right idea, but this idea what thought up on a whim and not part of an overall strategy or plan. For a large Service Provider, this concept is interesting. I kept listening to their story as I was keen to hear how it all panned out. As I was certain, this was not going to end well or provide the results and outcomes desired.

The process was designed with stakeholders dragged along to help provide input to the process. Few of the participants had ITIL Foundations training or experience with Problem Management. The Project Manager just wanted deliver quickly and inform his managers that all was progressing well and on target. Overtime a process was documented and accepted and put to use.

Some people used the process and tool and others did not. All of this was reported to management who decided they will introduce some reporting to get some real-time data on how the process was working. KPI’s such as no of problems raised, closed, per work group, per person, were developed. Staff got wind and started raising problem records and closing to meet the average quota they had to raise. Some were raising them when they were not required. The KPIs’ were driving the wrong behaviors.

Like many other implementations of the process, it is failing. The process became an administrative nightmare and brought no value what so ever to date. So they in short were doing Problem Management for the sake of it, wasting time, resources, money without any real business or IT outcomes. These sorts of implementations fail and any moment to reignite this process and re-launch will be difficult. Why this primarily failed can be put down to a few things;

  • Lack of understand from all stakeholders the actual value of this process
  • No Problem Manager championing the process
  • No integration in tool with Incident Management, Services or CIs (Configuration Items)
  • Poorly developed Metrics – no CSF, KPI’s or metrics aligned to process goals
  • Poorly defined goals, objectives and intent of the process
  • No training on process or toolset
  • Policies, when and how problem management needs to work
  • Methodology: Kepner Tregoe or 5 Whys to help with structural elimination of issues
  • There is no consistent way of working

Do you have one of these implementations? Consider reviewing via process audit and bench marking against practice and then look at CSI program to write the wrong right!

SHARE IT: