Documentation errors can turn the most promising deliverable into an auditing nightmare. This nightmare can be avoided if the manufacturer considers simple, common sense documentation suggestions.
The following is my Top 10 list of documentation considerations. This list does not cover every documentation issue but highlights some of the more common errors that I have seen during my tenure as a regulatory/quality engineer.
- Use of TBD The use of TBD (to be determined) is perfectly acceptable especially if document details are not completed until the end of the product life cycle. However, if you choose to use TBD, be sure to include what needs to be determined, who is responsible for determining this information and when it is expected to be resolved.
- Use of N/A Similar to TBD, the use of N/A (non-applicable) is very common especially when manufacturers are using templates that don’t always apply to every product development situation. However, when using N/A, be sure to explain why it’s not applicable. An auditor may think the information was not completed because the originator ran out of time. Incidentally, one manufacturer tried to get away from explaining the N/As by removing them and shading the box. Shading only works in hot weather.
- Referencing tables, graphs and page numbers Spend some time looking at how the document is formatted. If the text refers to Table A, make sure the table is not identified as Table 1. If the header gives the number of pages, make sure it’s correct. My favorite examples are documents that read Page 7 of 8, Page 8 of 8, Page 9 of 8, etc.
- Focus on facts not opinions All too often I have read documents that included opinions such as “we were told to stop testing because of the schedule” and “the tests passed but I think we did them wrong.” Issues should be resolved in a project team not in an auditable document.
- Simple sentences I think everyone has a bit of Hemingway in them. However, design and development documents are not the appropriate place to demonstrate this talent. By using simple sentences, the quality of the document can improve substantially.
- Tell A Story All good stories have a beginning, middle and end. When writing a document, tell a good story. On occasion, I have read documents that tried to cover too many issues and the reader got lost in the details.
- Determine number of approvals Many people may have the responsibility of creating a deliverable but only a few should have the authority to approve it. By keeping the number of signatures to a minimum, the documentation review process is faster and the approval process is consistent.
- What is a draft approval? This is one of my favorites. Some people thought if they wrote “draft” on their documents, it could not be audited. They also have told approvers that there was no need to review the document in detail because it was only in “draft-form.” If a documented is controlled in your document control system, it is not considered a draft.
- Pass/Fail/Pass Nothing is perfect and it is very likely that certain tests will fail. It is important to document these failures. However, when documenting the failure, include how the failure was resolved and how it was retested. All too often, I have read reports that document the failures but conclude by saying the device passed all testing criteria.
- Next Steps If a report shows next steps, be advise an auditor will ask how those next steps were resolved. Next steps are similar to open issues and open issues are expected to be resolved.
The key to understanding good documentation practices is training and accountability. Before documents are written, it doesn’t hurt for quality and regulatory personnel to spend time with the project team on how to write better documents. Then once the documents are being written, it is important to work with the team to make sure common documentation errors are minimized.
By minimizing these errors, the look of the documents improve while the review will focus on the content rather than being distracted by the number of TBDs.
Tags: Best Practices, Documentation, QSR
