The Challenges of RCA in ITIL and the "New" Deming Cycle

People: Because pPM is technically challenging, you should try to dedicate people for it. Driving down the number, duration, and impact of incidents is a skill that requires training and constant vigilance. The usage of dedicated resources also facilitates the financial tracking of the effort, as it is easier to measure the cost of pPM when you are working with full-time people, instead of with scattered time slices of shared resources.

Metrics: It seems redundant to mention reporting and metrics. Everybody knows the importance of appropriate metrics and reports to manage your environment, right?

I recently visited a client who had its service desk outsourced to an East-European entity. The level of reporting was far below expectation. The few reports that reached our client were riddled with inconsistencies. More than 60% of the tickets were uncategorized. There was no effort whatsoever to match clustered service calls with specific incidents in the IT environment. The reported number of tickets was actually the number of “touches” and included Level 2 support. The FCR metric was not available.

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.

4. Incentives

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.

5. Communication

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 C’s: 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 don’t 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:

·

Announcements and compliments to the group that solved an insidious problem;

·

Money-saving case studies in the IT newsletter; and

Additions to the Frequently Asked Questions (FAQs) intranet website with the name of the IT person who added the FAQ.

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.

Conclusion

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.