One comment that was made during a presentation at the Ultrasound World VII Conference (http://www.uesystems.com/resources/ultrasound-world-vii-conference.aspx) has stuck with me. "When you do RCA, you have to make the corrections to the root cause, or you send the wrong message to the organization."
How many teams working on Root Cause Analysis (RCA) really see themselves as sending any message anywhere?
They are, of course. An RCA team is normally a cross-functional group. To begin with, the failure that is being reviewed was noteworthy enough to precipitate the RCA. The team organizer borrows staff from maintenance, production, process engineering, and often a few other groups to conduct the study. The group normally has to gather information from still more sources in order to piece together the story of the failure that is under investigation. All of this gets attention and raises some expectations within the organization. What happens next?
Well, if your organization is like many others, there is usually some mild embarrassment surrounding the results of an RCA. The objective isn’t to fix blame, but it’s hard to avoid some degree of finger pointing. Also, fixing the problem(s), whatever it/they are, is going to require work and expense, often by people who are not the direct beneficiaries of the fix. This is a key point.
In a typical RCA scenario, a reliability engineer convenes the team and writes the report from an RCA. The report recommends that engineering make an equipment modification that maintenance then installs. To make the improvement effective, production staff on three shifts may need to be reinstructed. Then, if we’re following our plan, do, review approach (PDR), someone follows up on the progress and results of the fix and writes a statement of completion to cap the RCA report. The beneficiaries of all this work are out there, but they probably aren't the workers putting the fix in. Good luck.
More often the reliability guy, figuring his job is done, appends the team’s findings to the report and sends copies to the team members, along with a note of thanks for their help. The original usually stays in the personal files of the team leader. They’ll be handy there to be used as a reference the next time a team is convened to solve the same problem. (Yes, Sheldon, that was sarcasm.)
The answer is, of course, to charge the team with fixing the problem, not just analyzing it. A typical RCA should give rise to a project, or at least a few maintenance work orders. These, in turn, should be followed by a designated member of the RCA team until the work is satisfactorily completed and recorded in the CMMS and wherever else it should be logged.
When the mission is completed, a celebration is in order so that congratulations are at least as visible to the organization as the failure and the RCA were. This takes management support. Safety, ecology, and profitability benefits should be computed and shared. After all, if the job was done right, life just got better for a lot of stakeholders in the organization, and an important problem won’t have to be solved again.