Posts Tagged ‘effective writing’

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.

In this series we have discussed Purpose, Audience, Content and Style and how each works with the others to determine the utility and readability of any document you write.  We will close this series with a discussion of writing “Mechanics” in the form of a simple list of annoyances readers complain about most often.  If you want to make sure you never experience these annoyances again, we humbly suggest you Tweet the link to this document to your family, friends and everyone you work with.  Once they see what they are doing wrong, their writing will improve and your stress level will drop!


Here is a partial list of our students’ and our pet peeves, assembled through the years. 100-101 dumps As a reader, if you find that a major aggravation is not listed here, email me at and we will consider including it in the next update.

This is a collection of the most common mistakes we have observed (and periodically been guilty of) in writing and assembling technical reports, CONOPS, proposals and other documents:

  1. Spell-Check. Failure to spell-check the final version, just before the final printing. Simple typos will lead some readers to conclude you are lazy, careless, stupid or all three.
  2. Total reliance upon a spell/grammar-check program, which will not necessarily catch improper word usage, for example the accidental use of “form” instead of “from”.  Read the document   s-l-o-w-l-y   and be certain every sentence makes sense.  And get others to read it. IIA-CIA-PART1 dumps Microsoft’s automated “help” features often are not of much help, especially with punctuation choices and grammar decisions.  Do not trust Bill Gates to protect your reputation.
  3. Failure to include a list of acronyms or failure to define every acronym the first time it is used.  Assume nothing about what your audience knows.  DOD (Department of Defense – – – see, we follow our own rules) workers, government and contractor, are especially guilty of this.  An example is “CONOPS” which, depending upon the agency, can mean Concept of Operations, Contingency Operations, Continuity of Operations, CONUS Operations (an acronym and an abbreviation within an acronym – “Continental United States Operations”), Continuous Operations and others.  Define it or don’t use it.
  4. Failure to define complex technical terms.  Don’t assume all readers are PhDs.
  5. Incorrect graphic/figure/table numbers. When these are manually input and another graphic/figure/table is added later, there is the ripple effect whereby every subsequent graphic, etc. must get a new number.  Instead, let the application (MS Word, Word Perfect, etc.) assign the numbers.  It precludes the ripple effect and automatically lets you later assemble a Table of Contents, List of Figures and List of Tables.
  6. Incorrect page number references in the text, making it difficult or impossible to find referenced sections.  This is usually caused when text or graphics are added somewhere in front of the page being referenced, causing the referenced section to slide onto the next page.  If sections are numbered as they should be and section sizes are less than a half-page in length, reference the section by name and number.  But if sections are large and referencing them would require the reader to search through several pages to dig out a referenced passage, cite the actual page number but double check all such citations for correctness just before publishing.  And be aware that a web-based document, especially an Adobe pdf document, may have page numbers that do not correspond to the hardcopy.
  7. Changing text color in the main body of the document.  Keep it black.
  8. Failing to italicize non-English terms (fait accompli, ad hoc, coup de grace, blitzkrieg, etc.) so people can mentally pause to remember what the term means or using the terms improperly (and we are not talking here about commonly used terms such as “via” or “vice versa”).  If you cannot pronounce a foreign term properly, or don’t know exactly what it means in the native language and how it are used in the native culture, it is probably not commonly used here in the US.  So don’t use it.  And a special caution to Francophiles (lovers of all things French):  We have found that ad nauseum – – –  Latin for “excessive to the point of causing vomiting” – – –  use of French phrases is often the hallmark of a person flaunting a writing education they never received, insinuating an intelligence they don’t actually possess or adopting a French perspective which, by itself, may upset some Americans.  Politics and cultures aside, English is a fine technical language with plenty of precise, descriptive terms.  Use them.
  9. Beginning sentences with “but” or “and”.  This is common use now.  Increasingly, people write like they speak.  It isn’t the death of English as we know it.  Get over it.
  10. Assuming that the reader can mentally keep track of where all the pieces of a CONOPS reside.  In the case of a CONOPS or proposal that has components classified at various security levels, this assumption is folly.  Give the reader a roadmap showing where all the components are, their classifications, etc.
  11. A document manager’s failure to provide a style guide and then complaining about all the work he/she must do to pull the final document together.
  12. Failure to provide references in support of key claims, instead hoping the reader just accepts the claim.  As in medicine and science, the bigger the claim, the more solid the proof needed to substantiate it.  And be certain the trip is worth it for the reader: make certain the proof you cite is directly related to the claim, not a peripheral issue!  Remember that technical professionals do not spin findings or conclusions.
  13. Failure to cross-check every text reference to a table or figure to ensure
    • The reference is correct, i.e. such a table/figure a) actually exists and b) adequately discusses the subject indicated in the text
    • The table or figure follows the reference
    • The references in the text are sequenced properly (for example Table 3-2 should be discussed in the text before Table 3-3 is discussed)
    • Any referenced document is the most current version available.  And be sure to cite the revision number and date or just use dates as revisions (rev 15 Feb 09).
  14. Reliance upon complex graphics to make a key point instead of to support a point.  Excessive use of graphics throughout the document/section is often an indication of a poor/rushed author or an unskilled writer attempting to use graphics in place of text.
  15. Misuse of the forward slash (/).  The commonly accepted meaning is “and-or”.  If you cannot substitute “and-or” then the slash is inappropriate.
  16. Beginning to write the report without an outline and letting it meander. This is often evident to even a casual reader of the resulting document.
  17. Misuse/absence of embedded links in a document.  In our web-based world, most documents are reviewed in softcopy.  So use hyperlinks to take readers to key sections and appendices. But be sure that each linked page has a “return to previous page” link so the reader can quickly return to the previous page being read.
  18. Starting the report too late and then rushing to finish. The resulting report almost always suffers with sections obviously written by different authors, key conclusions glossed-over, graphics overused and unaccompanied by explanations, typos, etc.  The typical excuse that managers hear most often is “I was too busy DOING the work and did not have time to REPORT on the work!”  My advice is not to use this excuse.  It marks you as a rookie who cannot plan his time properly.
  19. Use of vague terms like “recently”, “some” and “few”.  Quantify!  Use numbers wherever possible.  Imprecision invites varying interpretations.
  20. Use of hidden assumptions.  I’ve heard writers say things like “Everyone knows that quartz is preferable to glass in this infrared application” or “Well, the sponsor obviously knows why we are changing our technical approach because he directed the change.  So we don’t need to say that in the report.” Wrong!  Assume nothing! In the latter example, the sponsor is only one of potentially several dozen (or hundred) eventual readers of a report, most of whom will never know why your firm abandoned a perfectly reasonable technical approach in favor of a very risky one, unless you tell them!  Omit that single detail and you are likely to be labeled foolish in later meetings where neither you nor your sponsor is present to explain your actions.
  21. Excessive use of the passive voice which makes for difficult reading and complicates a document.  Here are a few common examples:
    • “The system will be capable of  . . .”  or “the system will have the ability to . . .”  (just say “the system will…”)
    • “. . . consider implementation of . . .”  (say “implement”)
    • “It was decided that . . .”  (say, instead, “Our team decided . . .”)
    • Other examples to be avoided include “…is favored by . . .” and “it was concluded that . . .”
  22. Use of “shall” in place of “will”.  You aren’t writing a specification so don’t use “shall” which is typically a legal term in business agreements and has a “binding” connotation. Write like you speak.  Use action verbs and an active, future tense.
  23. Lawyer-talk:  Don’t try to use lofty words when a common one will do, for example obtain (use get), accede (use agree), aforementioned (use already discussed), subsequent (use later), cognizant of (use know).
  24. Run-on sentences. A sentence should have a single, main point, not several.  Take a meat cleaver to long sentences.
  25. Lengthy paragraphs.  Most technical writers use fewer than ten lines per paragraph.  Robert Gunning even has a “Fog Index©” that quantifies how easy a document is to read, based on length of words, sentences and paragraphs (see reading list item #3).  Even when you have no page-count restriction, strive for conciseness.  While perhaps not as crisp and unambiguous as German, English is still a wonderful technical language when used concisely.  (This one sentence, written in formal Arabic, could require 3-4 lines of text!)
  26. Excessive use of “which” when “that” would be clearer.
  27. Use of expletives leading to wordy sentences
    • There are, is, were, was, will be . . . .
    • It is, can, was . . .
  28. Awkward page breaks.  Hold thoughts together in the text, forcing a page break to occur where it makes the most sense to the reader.  The worst infraction here is to allow a table/figure caption to become separated from the table or figure. Almost as bad is allowing the first sentence of a section to begin at the bottom of a page: push it to the next page to be with its friends!
  29. Commas inserted where they aren’t needed at all and absent where they are needed.  If you would not actually pause there when reading the text aloud, then you should think twice before putting a comma there.   If in doubt, leave it out.
  30. Lack of proofreading by anyone other than the writer.  Silly mistakes are not caught.
  31. Lack of white space: paragraphs crammed tightly against paragraphs/graphics, with very few blank lines.  Even page-constrained documents need some white space to improve readability!  The human mind appreciates occasional white breaks in the monotony of black text – – – it seems to provide time for ideas to sink in before new ideas show up in the text.
  32. Use of 10-point type size, to cram text into a page-count-constrained document.  Use 12-point or larger and cut the amount of text to make things fit.  Many senior people cannot comfortably read 10-point type and may get annoyed if you force them to use their bifocals.  And an annoyed reader may not even know why he dislikes your report (and hence, your firm), just that he does.
  33. Inconsistent use of abbreviations, terms, capitalization, etc. within the same document.
  34. Overuse of underlines versus italics.  Don’t be boring.  Mix it up but be consistent within sentences.
  35. Failure to add page numbers.
  36. Failure to insert a blank line between paragraphs.
  37. Inconsistent use of indentures.
  38. In a CONOPS, failure to number the sections, making for difficult discussions about paragraphs/sections of interest.
  39. Inconsistent depth in the outline, with some sections a shallow 2-alpha and others at an almost microscopic 5-alpha.  The temptation is to include lots of data for areas where you have it, leaving other areas barren.  Don’t do it. Balance the outline and the body of the document, putting details in an appendix.
  40. Use of “e.g.” (for example) or “i.e.” (in other words).  Since many readers don’t know these definitions, and high schools don’t seem to be teaching much Latin these days, let’s stop using these terms.
  41. Pairing people with “that” or pairing objects with “who”.  Do not write about anyone “that” did something or said something.  Use “who” when referring to people.  Use “that” when referring to anything else (objects, organizations, etc.)
  42. Use of “reiterate” when “repeat’ would do fine.
  43. Excessive use of questions as the opening sentence in a paragraph.  Occasional use of this technique is fine but be aware that it forces the reader to move out of the passive-reception mental mode and actually think, which annoys some people.
  44. Excessive employment of “utilize” when “use” would work fine.
  45. Don’t use “in order to” when “to” works just fine. For example, instead of: “In order to complete the signal processing chain the filter must be tuned to…” use this more succinct and directed version: “To complete the signal processing chain the filter must be tuned to…”
  46. Lifting Power Point ™ graphics and plopping them into Word ™ documents without regard to complexity, applicability or suitability.  In these hurried times this is common but still criminal.  Build graphics from scratch with a pencil and paper, outlining them first to answer the two questions “what do I want this graphic to accomplish” (inform, persuade, explain, motivate, etc.) and “what would be the most effective, efficient possible graphic for that purpose?”.  Then search existing graphics for candidates and give STRONG consideration to using pieces of them to custom craft a crisp hybrid.
  47. Confusion of compose and comprise.  Roget’s Thesaurus© even has this wrong.  Compose is a verb in the music business and in specialized writing such as poetry.  Elsewhere the phrase “composed of” describes a single thing and is often used in place of “made up of”.  A single, complex thing can be composed of many smaller things. But Comprise describes an assembly of multiple things and means “make up” or “add up to”: multiple things can comprise a larger thing.  But published definitions for these two terms overlap so we suggest only infrequent and careful use of them, especially of comprise, to avoid confusion.  Instead of saying “The items inside this bag comprise all my personal effects” (which is correct usage) instead just say “This bag contains all my personal effects” and hand it to the jailer.  He probably won’t believe you and you’ll be strip-searched anyway.

Crisp, clear technical writing is a learned skill and increasingly in demand.  Crafting a crisp, well-worded section in a blog post, book, proposal or report is very satisfying.  And like any other difficult-to-master skill, becoming a good writer takes practice and effort.

Lastly, remember to submit your writings early to peers and others for review because none of us is as smart as all of us.

Suggested Reading List:

  1. The Elements of Style by Strunk and White, 4th Edition (a classic reference book, over 10 million copies sold, available at any major book store)
  2. Systems Engineering Handbook, International Conference on Systems Engineering (INCOSE), California, 2006
  3. Technical Writing, Process and Product by Steven and Sharon Gerson (Prentice Hall, 1992)

Copyright: Solid Thinking Corporation

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.


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.)


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.


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