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.
Clear, sharp writing is almost a lost art. And it is sad because to get along in life you must be able to explain yourself clearly. Texting and its shortcuts and abbreviations let us communicate simple thoughts quickly but texting is not suited to explaining complex issues, refuting others’ positions or reporting on a technical approach. In business if you cannot craft a grammatically correct, well-written document that people find pleasing to read, you will always be working for someone else who can. Heck, if you cannot write, you may not be able to get a bank loan for your business or even get a letter-to-the-editor published in your local newspaper!
Once you get the basics right, it also helps to write in a flowing, friendly style that makes people want to read what you write. But why are some documents, even long and involved ones, easy to read while others are difficult to get through? It turns out there are five key considerations in writing: Purpose, Audience, Content, Style and Mechanics. In discussing the first four considerations we will give you some basic rules for creating effective, efficient papers of all kinds (especially the fear-inducing technical reports and business studies). Then in the “Mechanics” section we will help you avoid the wince-inducing writing errors often found in popular articles and papers. The goal is to prevent readers’ getting balled up finding annoying mistakes, and to instead relax, understand your points and enjoy reading the things you write.
Why should you listen to us? Our company, Solid Thinking, teaches short courses in building Concepts of Operations or CONOPS. These documents are combinations of systems descriptions and user’s manuals, brought into one document for use by end users and systems engineers. CONOPS are hard-hitting documents that provide continuity for multi-year (and multi-million $$$) systems development projects, ease reorganizations of major enterprises, and help describe the operational uses of things. CONOPS are read by senior people who have little patience for long, meandering, wordy documents so we have learned to write crisply and succinctly. You will find references to CONOPS throughout this document but in each case, the lesson also probably applies to any written document.
We also teach Project Dominance courses which are basically Project Management courses on steroids. Project Managers are constantly writing and reading, editing and enhancing documents. Our courses teach people to sort out, structure, organize and manage major projects of all kinds by helping them make the best possible use of the talent on their project teams: young and old colleagues, rookies and grey-beards, scientists and business managers – – – everyone has something to contribute. And crisp, clear, unambiguous writing by each person on a team can save time, avoid frustration and help achieve the workplace harmony we all seek.
Note that this paper uses masculine and feminine forms interchangeably. Some people like it, others don’t. Also, a friendly warning: Please do not edit this paper. Editing will cause you to focus on the minutia and you will miss the learning value. Just relax, stay at the 50,000 foot level, read for meaning and content and resist the perfectly human urge to improve everything. But if we have entirely forgotten something really important or we have gotten a concept or technique completely wrong, please tell us in an email.
In our classes we find that just about everyone gets something beneficial out of this paper. But if you are working in a large company or in a government organization (Federal, State or local), or you plan to someday, you will really benefit from reading this paper and applying the no-nonsense lessons. Now let’s get into the meat of effective writing!
Purpose
Decide on the ultimate purpose of your document and make the main points up front. Make your key point in a single sentence, succinctly and in plain English, in the first part of every section/book. Then support your conclusion/results with as much detail as needed to meet the objective of the report (inform, persuade, support, etc.).
Is the report intended to inform a sponsor (via documentation) about work recently completed? Is it intended to persuade a sponsor to support a new idea or to award a follow-on contract? Or will the report be used by other people, perhaps people in the sponsor’s chain of command, to secure funding for additional work? Perhaps all three uses are foreseen for the report: it is usually safest to assume as much and then write for a technical audience but introduce each major section and key point with layman-language. After the main point has been made, support your contentions with text and graphics and with the appropriate technical depth.
This writing technique of main-point-first is the reverse of how many scientists and engineers tend to write. Most judge each other professionally on the thoroughness of their reasoning and on the extent to which they thought-through the various aspects of any given problem. Consequently, when they write down their solution to a problem, they tend to present their solution using progressive-discovery. This involves disclosing a little bit of information at a time, to lay the groundwork for their assertions and arguments. This is supposed to convince the reader of the author’s qualifications and reasoning skills before the assertion or conclusion is unveiled. The hope is that the reader will then be more inclined to accept the writer’s conclusion or position. Here is how this typically unfolds: First the scientist or engineer defines the problem they faced then they discuss aspects of sub-areas of the problem, weaving a web of complex interrelationships. Then they discuss key issues associated with each aspect they uncovered. Next come the assumptions they had to make (because nobody ever has a 100% complete data set) and then the trade-offs they made and why they made certain choices. Lastly they describe the various conclusions they could have reached, and only then do they tell you their actual conclusions.
Why would people write this way? It is human nature. People inherently fear rejection of their ideas so they lay a supporting foundation prior to springing their solution on the audience. This minimizes the chance of initial rejection. But if an entire section of a technical report is written in the discovery-style, it will inevitably have an unintended consequence: managers, technical and non-, who are reading for conclusions will be forced to wade through the entire document to understand the writer’s main conclusions. Similarly, scientific and engineering professionals from disciplines other than that of the author must also wade through the text, and the often-unfamiliar acronyms, to get to the nuggets. These readers will also find the detail too tedious. Do not do this. Use an “elevator speech” to state your conclusion up front and then support it as needed.
Always be clear, blatantly so if possible. Whenever your chosen approach will result in clear benefits to the customer or user, say so! If faster processing will display results faster, or higher fidelity information will aid decision makers, or fewer boards will lower acquisition and life cycle support costs for your system, say so and do it up front in the section where you also present your conclusions. But do not exaggerate: whereas engineers are likely to omit key competitive discriminators in technical reports (a serious mistake), marketers are likely to lean too far the other way (almost as serious), sometimes embellishing the benefits of a study’s findings. To a technical reader, this may appear as an exaggeration of the facts, a “sales pitch” at best and dishonest at worst. One way to highlight your competitive discriminators, without alienating the technical reader, is by quantifying the benefit and couching the description of the finding/result in terms of the benefit to the user. You can also write about how your approach reduces program/technical risk or reduces program cost. An example might be in the case of a redesign effort that permits an assembly to be built using two processor boards instead of three. One way for your team to subtly take credit for the positive aspects of this redesign would be as follows:
“While not required in the government’s Statement of Work, our team wanted to decrease the board count and believed it would be worth the 15 man-hours spent in redesign. Our initial calculations were born out in the cost reduction assessment that followed our redesign: dropping from three to two boards in the receiver will have four major benefits – – – the initial acquisition cost of the prototype will be reduced by $3K (and each subsequent system will be $2K cheaper); we will save at least 110 man-hours in software development for the prototype because we eliminated a very complex board; one entire module can be deleted from the user’s maintenance training sessions; and a chapter can be removed from the course manual we will write as part of our contract. Perhaps most importantly for the users, the system will now be much easier to configure and maintain.”
Remember a business or technical report may be initially written to inform but 80-90% of the time a technical report will be eventually used somewhere as a proposal to sell an idea. Often this reuse of your report will take place without your knowledge or involvement and a later audience may be very different from the original one for whom you wrote the report. Since the intent of a proposal is to persuade or convince someone to take an action, write every report with that possibility in mind. Write the opening part of every document and every section with the assumption that the audience will be relatively unfamiliar with the subject matter. Then dive as deeply as needed into the technical discussions. Just remember the old Sears© slogan: “Something for Everyone” (technical and non-).
Next week we will discuss the critical importance of knowing your audience. Mess this up and you’ll be writing for . . . well . . . nobody. And we will briefly discuss content and style.
Copyright: Solid Thinking Corporation
—
