The Keys to Easy Compliance
As consultants, we usually get called to add a little horsepower to an effort already under way to mitigate some issue, whether it is performing gap assessments and remediation or adding resources to speed up resolution of some problem. Sometimes it is to add to the pool of expertise or a new perspective. These are all great reasons to hire a consulting resource.
Based on this experience, I can report that almost all compliance issues that I have come across have one general root cause: the inability, for whatever reason (and there are many good reasons) to plan and understand requirements sufficiently. This is rooted further in the perception that things will get done faster if you skip steps on the way to your goal. Perhaps a feeling that it would “be great to have that problem” because it means you achieved the production goal, but may have to do some cleanup. The complement to that, where you don’t meet your goal, and you have done everything very carefully, is, arguably, even a worse problem.
If you have a written plan, and that plan includes having requirements and a risk assessment to start things off, everything else falls in place.
A plan provides the long term vision, the requirements ensure that when you complete the project you have something that you can use, and the risk assessment helps ensure that you don’t spend too much time doing work that will not be useful.
Also from experience, I can attest to the fact that there is a range of level of detail in this documentation, but the order is critical. Everything becomes easier even if you have any level of detail in these documents if they are available at the beginning of a process. They can always be revised, but never should be written after the fact. This is as close as I have seen to a universal truth in compliance whether we are talking about equipment systems, processes, medical devices, computer(ized) systems, facilities, or products.
At this point, people with experience in this industry are saying that I am stating the obvious, yet this is still an issue you run into from time to time, and you see preventable delays or failures due to, I believe, a perception that the whatever system or process is well understood enough that the documentation would be redundant and not add value. In fact, most of these issues are complex enough and have enough people involved that it is not reasonable to expect them to be completed optimally without strong documentation. And in the end, you make up with it by having a short, event-less, qualification process. But for some reason that is a tough sell up front.
