Before anything else, make sure you instil the following message into your company's culture and never, ever forget it: The purpose of documentation is to transfer the right information to the right people at the right time. Anything that interferes with this objective is at best a waste of time, at worst downright dangerous.

Now, let's explore some other golden rules for minimising pain and maximising knowledge transfer.

Avoid duplicating text

At best, duplicating text increases your maintenance burden because you have two or more versions of the same text to maintain instead of one. At worst, and most commonly, duplicating text wreaks havoc because the different versions get updated independently (or some get forgotten) so you end up with multiple versions of the supposed 'truth'.

In software engineering there's a concept called Don't repeat yourself (DRY) that applies equally to documentation. With a little imagination, you can always avoid the need to duplicate information, eg:

• Copying and pasting text within the same document? Use cross-references or 'Insert bookmark' instead.
• Creating multiple copies of the same document for versioning reasons (eg Document_v0.1, Document_v0.2)? Use the native versioning of a document management system such as SharePoint instead. Even if you're just using shared folders, you can change the folder system's attributes so that prior versions of each document are automatically captured.
• Duplicating the same content across different documents? Merge the documents into one. This works even if you have different readerships for the information, e.g. if you have an 'Overview' and 'Operations' version of the same content you can create a larger document where the 'Overview' content is the opening chapter.

Shorten the reader's journey

If people have to follow a convoluted path to find information (e.g. burrow into a deep folder hierarchy, or search across multiple repositories) there's a risk that either they won't find the information at all, or they'll find the wrong information and assume it's what they need.

According to the principle of least effort, people seek information using the easiest means available and stop looking once they've found minimally acceptable results. Often, enabling people to find wrong (e.g. outdated) information is more dangerous than preventing them from finding it at all.

Here are some ways to shorten your reader's journey:

• Create a single entry point: You know those board maps you sometimes get outside stations and in touristy villages, the ones with a big dot or arrow saying 'You are here'? Your information repository needs the same thing, a home page with clear navigation paths that readers can follow to find whatever information they need.
• Choose flexible searches over rigid hierarchies: Avoid deep folder hierarchies that force readers to bury deep to find the information they want and that give them only one path to finding information. Instead, use the native search/filter/group/sort capabilities of a document management system such as SharePoint, to enable readers to find information according to their own (often highly subjective) search criteria.
• Keep information within reach: e.g. if you're documenting software, create online help instead of separate user guides; or put software installation instructions in a 'read me' file. Similarly, make policies (or at least their URLs) visible from where their target audience is most likely to see them. Even if Human Resources stores all company policies, you'd be wise to add the risk policy's URL to the risk department's home page rather than relying on risk managers knowing they have to visit HR's home page.

Collaborate

Many companies and individuals are resistant to the idea of sharing information, but their fears for doing so are usually unfounded and the consequences severe.

For example, if you hide a document from others 'because it's a draft and I don't want people thinking it's finished', you risk the following negative consequences:

• Hogging information others may be able to complete, needlessly holding up everyone else in the dependency chain for that information.
• Risking 'Chinese whispers' - you don't know the answer to A, so you ask person B who asks person C, who's not really sure but suggests you look at document D - which is out of date, but the only person who knows that is person E (who's hogging a draft with the key information).
• If a document is a draft, all you need to do is add the word 'draft' as a watermark, or in the header or footer.

One of the biggest mistakes companies make is instead of storing information centrally so everyone can pull it off when they need it ('pull' model) they send out the information ('push' model), typically and most disastrously by emailing attachments.

Sending out documents for review, especially when combined with the twin sin of 'versioning by filename', risks comedy capers such as the following:

• The original author creates Document_v0.1.
• Author sends Document_v0.1 to someone else for review.
• Reviewer emails author Document_v0.1_comments.
• ... but - oh whoops! - another reviewer picks up the document and starts creating a version they name Document_vo.2.
• Author gets sent Document_v0.1_comments, but not Document_v0.2 because the other reviewer is still working on it and hasn't told the author.
• Author creates their own Document_v02 from Document_v01_comments, not realising that a different Document_vo2 (see step 4) exists and is being circulated independently.
• The second reviewer has sent their Document_v02 to their manager for approval.
• The manager creates Document_v02_approved but later sees the author's Document_v02 and causes a scene because they think their changes have been ignored, not realising it's a different Document_v0.2 from the one they updated.
• Much confusion as the multiple versions are hunted down.
• The author creates a merged document called Document_v03, only unbeknown to the author...

To avoid such needless pain, keep documents stored centrally, in the same place and with the same name. As mentioned earlier, the best way to manage versions is using the native versioning of a document management system, especially as a DMS provides further advantages such as check-in/check-out capability to enable the integrity of a single master version of each document to be maintained at all times.

Even if your organisation isn't using a DMS (and if you're a large organisation you really should be), the 'same place, same name' approach avoids the recklessness of emailing attachments because you can email the document's URL instead. Think about it: if a person receives a document as an attachment, they have no way of knowing if or when the source document changes; but if instead they receive an email with a URL to the source document, they will always get the latest version when they click on the URL.

Julian Maynard-Smith is a consultant, knowledge manager and novelist who blogs at betterbusinesswriting.weebly.com. Reproduced with permission.