Life after CAPA

Need to catch up? Read the entire series here.

Congratulations! You've analyzed your business problem, identified a root cause, and implemented a CAPA. So now you're done, right? Well, not so much.

Webster's Dictionary lists several  definitions for theory. And really, what you've done in the process of RCA is develop theories. You have a good idea of the root cause, and you've developed what seems as though it will be an effective CAPA. But like any scientific theory, your work needs to be proven. Implementing a CAPA is not the end of the process; it's the mid-point.

If you were wondering why I recommended that you focus on one root cause and one CAPA at a time, now you know. You need to test each CAPA to find out if it works; if it doesn't, then you can safely assume that either your root cause or your CAPA is wrong. Increasing the complexity by concurrently working on multiple root causes and CAPAs will make it far too difficult to see if your CAPA is having the desired effect.

I'm not going to get into a lengthy dissertation of how to measure your CAPA; you know your business better than I do. At its simplest, however, is this: if the problem continues, then you did something wrong. If that happens (and it will at some point), gather your team again and figure out the next step: do you want to implement a different CAPA? Was the CAPA you implemented essentially on the money, but needs a bit of tweaking? Or do you need to create a CAPA for a different root cause altogether?

This leads me to documentation. From programmers who don't like to comment their code to managers who fail to document personnel discussions, people hate to document their work. But documentation is a critical part of RCA (as we say in the compliance biz, if you didn't document it, it didn't happen). The reason documentation is so important to RCA is that you might have to revisit what you've done and make changes; if your documentation is poorly developed and maintained, you may find that the team has to recreate some of the work it's already done. And nobody wants to do the same work twice, yes?

In addition to the fact that the team may need to revisit the analysis, you need to consider something else: turnover. People may come and go, but the issues in a given organization tend to hang on; and while everyone will be gung-ho on the CAPA initially, folks tend to get a bit lax once a problem seems to disappear. If this particular problem pops up three years from now (and the original RCA team is gone), think of how helpful it will be for the new folks to have your experience to draw from when working on resolving the issue. The documentation isn't just for you: it's for everyone who follows after you've moved on.

At a minimum, your documentation needs to include:

• The fishbone (or other) diagram that illustrates all of the potential causes identified during your brainstorming sessions
• The FERCS scoring matrix
• Detailed notes from your CAPA brainstorming session

I would also suggest that you develop some sort of system for tracking and trending RCA. You might find that the same types of issues keep occurring; alternatively, you might find that a disproportionate number of negative events are coming from a particular workgroup. The more information you have at your disposal, the more effective you'll be in preventing problems in the long term. And if you can spot emerging problem trends before they become established bad habits, it'll be much easier to resolve them.

Tomorrow I'm going to wrap up with a variety of RCA resources you can visit for more information. And you're always free to e-mail me if you'd like to ask me any questions.