The Challenges of RCA in ITIL and the "New" Deming Cycle
Metrics: It seems redundant to mention reporting and metrics. Everybody knows the importance of appropriate metrics and reports to manage your environment, right?
With such level of reporting maturity, the probability of a high-performing pPM tends to be low. A solid reporting structure and the correct metrics are necessary to start tackling pPM.
In an outsourcing environment, it is relatively easy for the client to include a clause and a corresponding service level in the contract to increase the probability that pPM is actually done. The basic effect of the contractual clause is to put the onus on the outsourcing service provider and to use metrics and an approval process to reinforce that pPM needs to be performed.
I believe it is not unreasonable to demand a 5% to 15% reduction of the number of tickets year-over-year. As a corollary, it can also make sense to provide the outsourcer with an incentive based on the improvements, e.g., an uplift on the price per ticket.
In an internal IT environment, incentives can be monetary or in the form of a drawing for a prize or dinner for two at a favorite restaurant. The monetary value of the incentive is not very important. However, you can enhance morale and encourage the desired behavior by recognizing the effort.
The importance of communication can not be over-emphasized. In training sessions or introductory presentations, I typically start with the statement that ITIL and its processes are about the principle of the 3 Cs: Communication, Communication, and Communication.
The pPM is a great example of the principle. Since it is invisible to the customer, there is a need for good data that communicates the proactive work you have done. If you dont communicate, you are in a situation where there is no glory in pPM.
·Here are possible elements of a communication strategy that could enhance your pPM by making the Problem Management people and their activities more visible:
6. "Check, Act"
Finally, keep the Deming or Shewhard cycle (Plan, Do, Check, Act) in mind, and specifically, the last two elements of the cycle.
The Check part is the measuring and collecting of metrics regarding the effect on recurrence of tickets. The most important aspect of Check is to define the review mechanism or process, and to appoint a person (again, not a committee!) responsible for determining the root causes within a particular time frame. If the required changes are relatively important, the review activity in which you gauge the ROI of particular changes that could eliminate major chunks of incident numbers might be a part of your project portfolio process.
The Act part is based upon the metrics, the financial impact, and the ROI of the decision. It deals not only with the approval and execution of the change to reduce the likelihood of the recurring tickets, but also with the governance and appointment of the people responsible for the identified corrective action items.
Like so many aspects of IT, the initiation and execution of RCA in an IT environment needs a crisp definition of processes, internal discipline and governance. These elements are the core drivers of action and reaction and the resulting enhanced corporate productivity. When you have these elements in place, your organization can go for the full Deming Plan, Do, Check, Act cycle, and not for the half-baked Plan, Do, Stop.
(Thanks to David Cannon, Jeanette Smith, Lynn Sturdevant, and Dirk Weber for their help with this article.)
Jan Vromant is a process architecture consultant, focusing on outsourcing related services and ITIL processes and is a Lead in the Outsourcing Advisory Services of Deloitte Consulting LLP. He is an ITIL (v2) Service Manager and certified ISO/IEC20000 consultant, and earned an MBA from Rice University in Houston. Before joining Deloitte, Jan worked at Royal Dutch/Shell, BMC Software, PricewaterhouseCoopers Consulting, and Hewlett-Packard. He is originally from Belgium and lives in the Detroit area.