It’s imperative that technical writers stick to the facts, and only the facts. All information published should be traceable back to original design or manufacturer’s documentation. Wherever possible, technical documentation should be checked and approved by an appropriate engineering, design or technical body, usually someone of appropriate position within a design or development team for the product or application being written about. This process is generally referred to as ‘technical verification’ or sometimes ‘technical validation’. This reduces the exposure of the technical author and ensures that what has been written about the system or product is deemed to be correct by both the writer and the designer and is technically underwritten by the technical specialists and design owners.
Many technical authors feel that their professional technical knowledge or integrity is being offended by such an approach. This is not the case. Ensuring you have the appropriate technical governance to be able to confidently publish technical information does not bring your skill or knowledge into question. In fact, it enhances your reputation as a specialist in your field. Such diligence ensures that in the event of future audit or scrutiny, the technical author can demonstrate the provenance of the information published back to the appropriate, authoritative technical source.
In complex technical documentation production projects, large parts of the overall process deal solely with the supply and configuration of source information and with the technical verification of the information produced before any deliveries are made to customers.
The configuration (or issue state, or version) and the type of source information being used is also a vital consideration for technical writers. Draft design or development information should never be used as a basis to produce and issue a technical document. In general, if the source design or product data is still in a draft state, the technical documentation must also be regarded as draft, and not fit for issue or use.
Always ensure that you are using the latest or most relevant version of the source information that you need. Many technical authors will tell you to ‘verify before you specify’. This means, make sure the information is right before you use it.
Where using design data, the writer must always ensure that data relating to the actual product, system or variant being built is used. Many writers will attempt to be pro-active and will use copies of requirements specifications or marketing information to produce the technical documentation. While these source documents will give the technical writer good background knowledge, there is no guarantee that the eventual product or system will be as described or perform in this way. They are therefore not reliable information sources for a completed and published manual.
Hopefully this short article has helped you to understand just some of the things that you need to consider when trying to understand your liabilities and mitigating them. If you haven’t already seen Part 1 of this article, take a look and see if you might have a technical writing liability that you’re not aware of yet.