The 10 Dumbest Mistakes Business Writers Make

1 November, 2010

Lots of dumb mistakes can slip into even the best writing. Here we look specifically at reports and other technical documents to provide authors with a checklist they can use for their work.

1. Numbers that don't add up

Just one table where the numbers don't add up correctly is enough to shatter confidence in an entire report. Usually this happens when tables are updated manually. The best thing to do is to keep all original tables in a spreadsheet and copy them in each time. You can make sure that colleagues are not tempted to make changes manually if you paste tables in as graphics.

2. Incorrect table and figure references

What does a reader think when he/she reads that 'evidence is provided in Table 3' but then is unable to find that table? Or what happens if the reader finds Table 3 but the evidence is completely unrelated because it should have referred to Table 4? To make sure it doesn't happen to you, use automatic cross-references.

3. Unsourced data

Numbers that appear from nowhere can be just as infuriating as numbers that do not add up. To present a credible argument, evidence needs a source. Insert footnotes as you write.

4. Leaving in details to be completed later

Have you ever come across a document that refers to 'a XX% increase'? A sure-fire way of alerting your reader to careless checking is to leave in phrases like 'more details to be added on this later', or 'note to self: check this is correct'. A good way to avoid this is to agree on a format for all comments within your company and for everyone to adopt it. That way a search can pick these out. You can also use automatic tools to find these errors. PerfectIt contains a test that scans documents for any of these editorial comments that have been left in.

5. Blinding with science

Technical reports are often intended for a non-technical audience. Sometimes authors can get away with blinding the audience with technical language and complex theory. More often, authors who try that will have to face a complete re-write. Technical explanations belong in an annex; keep the flow of your text simple.

6. False accuracy

The way that numbers are presented conveys important information about confidence in the result. If the benefit to the US economy is $1 billion, it means that it could be anywhere from $0.5 billion to $1.5 billion. If the benefit to the US economy is $1,050,023,178, then it means we are confident that the benefit is exactly $1,050,023,178. The degree of rounding should reflect the degree of confidence and the likely range implied.

7. Inconsistent writing

There are an incredible number of consistency errors that can creep into technical documents, especially if there is more than one author. With careful checking and tools like PerfectIt, you can cut down on consistency errors and present your results in your corporate style.

8. Over-reliance on spell check

Spell check is a great tool. But it cannot spot every error. It's easy to write the word 'manage' without the second 'a'. A Google search shows that there are thousands of documents that use the phrase 'project manger'. Errors like these can be difficult to spot and can also be the most embarrassing when clients find them. PerfectIt includes a test for some of the most frequently found typos and customized versions of PerfectIt can be geared to specific industries to increase the power of automated checking.

9. Less is more

Technical reports are not paid for by the word. So long reports are not an advantage. They are difficult to read and harder to check. Sharp, concise reports that are accompanied by more detailed annexes and supporting evidence are better for making almost any case.

10. Acronyms/abbreviations that are not defined

TLAs help to keep your text short. However, if your readers do not know that 'TLA' stands for 'three-letter acronym', then it's important that you define the word in its first instance. Tools like PerfectIt can be used to scan your text for acronyms that are missing a definition as well as instances where the acronym is used long before the definition appears. A table of acronyms can also be helpful for the reader and PerfectIt can generate this automatically.