Subscribe
Why should you read this post? Because this little crash course in effective writing is the collective intelligence of thousands of people just like you. It is a living document and benefits from ongoing improvements suggested by our students. Their suggestions and observations, especially in the final section, make us all much better writers.
Last week we discussed the importance of understanding the purpose of anything you write, long before you hit the first key on the old laptop. This post discusses the crucial importance of understanding the likely audience of your document, the main content and the most appropriate style for your purpose.
Audience
Do not begin writing, or even outlining main points, until the main target audience is chosen and then include a little something for everyone.
Will the report be read by seasoned technical staff or by program management people whose technical backgrounds are unknown? You will, of course, want to report at a level of technical complexity that mirrors your primary customer’s level of technical comprehension. Even then, you should introduce your key points in plain speech, followed by detailed engineering discussions about why you chose the approach you chose, how your conclusions were reached, the trade-offs you performed, etc. And if you expect your report to be read by a multi-level audience of lay and technical people, making your main points early in each section is even more important.
This is also a good time to think about the access your competition is likely to have to your report. If the audience is the US Government, then SETA (Systems Engineering and Technical Assistance) contractors, perhaps even your competitors, are likely to read it. If you have Intellectual Property (IP) that needs to be discussed in the report, you should try to discuss it in sufficient detail for the customer to get a feel for its significance, but not in so much detail that you lose competitive advantage to a competitor. Consult your company’s Marketing and Intellectual Property staffs on these issues, before you write those sections. (If you write those sections first and they are later rewritten or deleted, and if the authors of other sections have referenced your earlier [now nonexistent] paragraphs, you may cause lots of confusion.)
Content
Rookies talk mainly about the format of a document. Professionals talk about the content. Ensure that the content and technical/operational level of detail matches the customer’s expectations.
How deeply does your sponsor expect you to discuss key topics and important findings in this report? How much support for your findings will she expect? If in doubt, ask her! One hint can be found in the proposal that won you the job to begin with, and the Work Breakdown Structure (WBS) in your proposal/Statement of Work (SOW): how much funding did you/he allocate to do the report? A report for which 10 hours were allocated in the WBS should look very different from a report that was to consume 120 hours of the team’s time. A study that changed its main thrust in mid-stream also probably needs a little more explanation/support than a study that remained true-to-proposal. If you already know the report will be used to convince/persuade others, then you must be certain to provide sufficient rationale to carry your arguments. Include possible objections and arguments that may occur to the reader and address those crisply and thoroughly. One way to do this is to offer those arguments as ideas that occurred to your team as well, and which were then considered during the course of the study. Psychologically, the reader may then feel vindicated that he thought of the same issues as your technical team. And he may also begin to believe that you and he think alike, a very important psychological milestone in your relationship! And all of this is made possible simply by how you worded your findings.
A cautionary note: If you are working from a document that originated elsewhere, you may not want readers of the finished document to know its detailed lineage. One US prime contractor was writing a proposal to a NATO RFT (Request for Tender) back in the 1990s only to discover that the NATO RFT’s Statement of Work actually had originated months earlier at a competitor’s facility. Previously just pasting a document into a fresh shell document was deemed sufficient but not anymore. Lineage data is still available to a determined sleuth. Software plug-ins are available that can permanently erase the originator, editors and record of changes for a document. Converting MS Word™ and Power Point™ documents to Adobe™ pdf documents works well and also makes alteration more difficult.
Style
Do not permit the concept of writing style to become an excuse for poor writing. Have trained technical writers review important documents before release.
Writing style can determine to a large degree how well the author’s information is conveyed. Our personal writing style is the product of our education, experience and training. A person may have a deep technical education and lots of experience in a given technical/other field, but unless they have been trained to write clearly and succinctly, their writing style is likely to be confusing and verbose. Writing is a skill. It must be taught (even self-taught), practiced regularly, and its impact fine-tuned via feedback from readers. Typically, much of that feedback comes from the writer’s peers. This is why After-Action Sessions are so useful to proposal and report writing teams. These sessions examine what could have been done better and often solicit the opinions of other employees (preferably from varying disciplines) regarding improvements needed in writing style, content, format, etc.
When confronted with recommended changes to a report they authored, technical writers sometimes get defensive, saying “well that is just my style and I cannot change the way I write”. But often the claim of a “unique writing style” is used to mask poor writing skills, plain and simple. There are generally accepted standards for English usage and they should be followed.
Writing user manuals is both a science and an art form. When you need user manuals, do not let the hardware and software teams who built the system/device also write the manuals. Employ people who are trained to write these or risk having your system unfairly maligned by every user who struggles to understand the directions.
When you write a report on behalf of your employer, you are representing the employer. In fact, your report may be the only thing some readers will ever know about your firm. Readers may draw all kinds of conclusions based solely upon that document, far beyond an opinion about the writer’s likely grade in English 101:
- Clarity and Decisiveness. If the document makes clear points and does so quickly, your company will be seen as a team of clear thinkers and decisive managers, as opposed to a bunch of hand-wringers.
- Careful, not Convoluted. If the conclusions are well supported, the firm will be seen as comprised of careful thinkers, as opposed to a group of convoluted thinkers who draw conclusions from thin air.
- Sparingly and Effectively Detailed. If the entire document hangs together well, with short write-ups where warranted and longer sections where needed, your firm will be viewed as being able to communicate complex ideas, with a good appreciation of where the reader might need supporting detail.
- Thoroughness. If there are no typographical or grammatical errors, the reader will feel that the writer cared enough about the impression he would make to thoroughly proofread the entire document. It probably means the company pays attention to detail.
In the next post we will provide a rogues’ list of the main offenders in writing; we will discuss many of the mistakes, large and small, that keep writing from being as clear and crisp as it should be. And if you do nothing more than just read about the mistakes that aggravate others, you will become aware of those errors and I guarantee you will become a better writer!
Copyright: Solid Thinking Corporation
—