Too often the objective for producing documentation becomes its own justification- documenting for the sake of the requirement to document. This will inevitably lead to poor quality documentation and more effort. How often have we seen a requirements document produced at the wrong stage in a process because poor planning failed to produce the right content for requirements at the right stage in the project? Poor documentation will always result in additional work as well. A design specification can not hope to document design of a well built, validatable system unless it can draw corollary to the functional and user requirements. Likewise, a validation protocol can not be conceived at the validation phase. Poor validation protocols can attempt to verify that a system functions as it was designed. But without the foundation of acceptance criteria in the user requirements and functional specifications, it can never prove that the system performs as intended. When all the pieces of documentation don’t fit together in their correct chronological order and with appropriate content, then the entire team inevitably becomes encompassed in the tasks of trying to make the pieces fit retrospectively.

Project documentation must start at the beginning and follow a sound plan. Each document must be constructed with appropriate scope and content consistent with that plan, always looking forward to the needs of the next document or next project phase. Documentation can also not be left to the validation team. The entire team must contribute to, review and be thoroughly familiar with each document. Team members from all involved areas, users, customers, developers, testers, quality, IT, project managers, and senior management must recognize documentation as part of their responsibility and actively participate in each.