PM Articles > Alan S. Koch > Fix It Fast vs. Fix It Right

Fix It Fast vs. Fix It Right

"Root Cause Analysis (RCA) will be our first Quality Improvement initiative." Carl told me. "It fits your definition of 'low-hanging fruit' (within reach and oh-so sweet). Besides, everyone agrees that we would really benefit from doing it right!"

"Carl is a quick study!" I thought to myself. We had just brought in the first two Senior Quality Analysts for his new Quality Office, and now he was ready to get them started on an initiative that would establish the value of the Quality Office by delivering real benefit to the organization!

A few months earlier, when I did their Quality Appraisal, RCA stood out as a big opportunity. They were already doing something (this put them light years ahead of most places), but for a number of reasons, they were failing to get any real benefit from it. This was our opportunity! Take an RCA process that was limping along, and turn it into a quality improvement powerhouse.

Two Responses to Problems

The heart of the problem with their old RCA process lies in the fact they were mixing and confusing the two distinct and different ways that you can respond to any problem that comes along. Your choices when dealing with a problem are to 1) fix it fast, or 2) fix it right. They were trying to do both of them at the same time, which often isn't possible.

They learned how to fix things fast, and so the "fix it right" part of the equation kept failing, even though they were trying to make it work.

Fix It Fast

That Carl's organization is good at fixing things fast is a feather in their cap, because it is not easy to do! There are many moving parts that must come together to get a problem resolved quickly.

First, the fact that there is a problem must be captured reliably. Whether a user calls and complains, or a monitoring system identifies an issue, or a system falls flat on its face, there must be a mechanism to capture not only the fact that it happened, but also all of the critical information about the failure.

Then, there must be an effective triage process that is designed to quickly and consistently categorize the issues that arise, determine which need to be addressed immediately, and identify who should address them. Information about the critical issue must be handed off to the appropriate technical people so they can get to work immediately. In addition, there must be checks and balances to be sure that issues are not dropped.

Finally, the fix must be put into production quickly so the system users can take advantage of it to get back to work. The fix might only be a patch or a work-around, but at least the issue is removed and the end users can get back to work!

Fixing a problem quickly is all about planning ahead and building good systems and processes so that when you are responding to an issue, things just work. Carl's organization had done this, and although they saw some ways to improve that process, it worked!

Fix It Right

Carl's organization was struggling with fixing things "right" mainly because doing so requires a completely different approach. Instead of mechanisms that are designed for speed, an RCA process needs mechanisms that are very deliberate and thoughtful.

First, there must be regular analysis of the organization's data to identify what problems merit analysis. Carl's organization had declared that all "Critical Failures" should be subjected to RCA. This will catch some of the failures that should be analyzed, but not all. And it will waste some of your effort, because not every "big" issue should receive this sort of scrutiny.

Then the right technical resources must be brought to bear to perform the analysis. Often this should include multiple people representing a variety of technical specialties. Carl's organization made RCA one task that the person responding to the issue must do. This practice guarantees that a group does not do the analysis, and may even put that task on an individual who is ill suited to do it.

The analysis cannot be rushed. Getting to the root cause of a problem often requires time as options are explored and data is gathered. Carl's organization decreed that a "Critical" issue could not be closed until the RCA was done. The push to close issues fast meant that the RCA was rarely given the focus and thought that it deserved.

Root Cause Analysis will often identify a variety options for permanently fixing a problem. Each will have costs, benefits, and shortcomings. So the preferred option must be identified and sold to the organization's decision-makers. The RCA process Carl's organization was using did not even consider alternatives. An RCA's action items were whatever the one person thought of.

Finally, when the organization's decision-makers approve the approach to be taken to permanently fix the problem, it must be treated like any other project (or mini-project). It must be resourced, initiated, and managed to closure. This was the piece that Carl's organization recognized was missing! The RCA Action Items were written down and filed. Where they ever acted upon? No one knows!

Fixing a problem permanently is all about taking the time and investing the resources to do the job well.

Blast Problems with Both Barrels

With this information in hand, Carl's Quality Analysts have a template for building an RCA process that will work for them. The key to success is to separate the RCA process from their existing issue response process. Where their current process says that an RCA must be "done" for a Critical issue, change it to "an RCA must be initiated"!

Then they can craft a whole new process for actually doing root cause analysis—a process that brings the right people together, gives them the time to actually investigate the root causes, and ensures that the results of that analysis are actually put to use.

I have pointed them to ITIL for "Best Practices" on doing this. ITIL's "Incident Management" process is all about fixing incidents fast, while their "Problem Management" process ensures that problems are fixed permanently. Not only does ITIL separate these two processes, but it also provides guidance on how to weave them together for the organization's benefit.

Yes, you can fix it fast and fix it right—just not at the same time! Keep these two concepts separate in your mind and your processes, and you will achieve both!

Related Links
Make sure you're getting to the root of the problem with our Root Cause Analysis Checklist, and make an organized case for your solution with our Recommendation Template. For one example of what a problem solving process might look like, review our suggestions for facilitating a group problem-solving session.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.