LP&F log
Communication Guidelines

 Several recent attempts to communicate with business units have demonstrated the difficulty of communicating even simple concepts to busy people. We have a large amount of information  to communicate, and our communication must produce results. To facilitate that process, we have used both ancient lessons and recent experience to prepare a set of  communication guidelines. 

There are only two groups of people who are allowed to cast the first stone. Those without sin and editors. Presumably, those without sin can cast stones without fear of being stoned. On the other hand, editors are subject to both return fire and ricochets from their prior comments. We recognize we are in the editor category and acknowledge the risks of setting forth the following:

  • Use a dictionary, don't make up definitions 
  • Use scope statements to define what you are writing about 
  • Make it clear to the reader what you want them to do with a draft 
  • Write so your work can be forwarded and posted beyond your intended audience 
  • Write in present tense to give your document a longer useful life 
  • Use caution when establishing documentation requirements 
  • Separate assumptions that need to be tested from statements of fact 

1. Use A Dictionary 

You don't have to be slavish to the dictionary, but it saves time and facilitates communication. Don't make up definitions or assume that what is common usage in your location or area of specialization is common usage across the entire organization. I have found that some of the best explanations and distinctions are in The American Heritage Dictionary. Merriam Webster's is available online: http://www.m-w.com/dictionary

2. Scope -- Less than the Entire World

You already have more than enough work to do. Define the scope of your document and subsections to fit what you are writing about and are responsible for. Be particularly careful to avoid using your single item to set policy for the entire corporation. Your project probably won't create "the" database or require testing by "all" business units. 

3. DRAFT -- So What?

If you publish a draft, the reason for publication should be clear to the reader. Have you published it just so you can claim an on-time milestone on your project plan or would you like the reader to do something? If you would like the reader to do something, say what you want and when you want it. Say this in the document. 

4. Addresses in the Document

Cover memos sent via e-mail often get separated from documents in MS Word. Include your electronic address in the document so a reader can contact you to determine if they have the latest version. 

5. Link the Think

You walk the talk, you demonstrate that you are ready, willing and able to do what you say. And then time marches on. Now in addition to doing, you are expected to share -- link the think.  If information is already available to your audience, reference it rather than rewriting it. This makes your document shorter, directs issues to the original author and avoids having two documents that are in real or apparent conflict if one of them is updated.  Write so that that your document can be forwarded and posted and seen by people you don't even know about. Provide links so they can get back to you if they have a question. (See the above note about cover memos and documents getting separated.)  Provide enough context that your meaning is clear to people well beyond your intended audience. Use your organization's official name. Include your name, and e-mail address if you use an electronic format. If you are only writing for a limited audience and really don't want others to read it, say so up front. 

6. Write in Present Tense

Write in the present tense, e.g., applications are tested, not applications will be tested. When you write in future tense, you writing becomes "out of date" as soon as a process starts. Your document has a longer life if you write in present tense. And, it usually takes fewer words. 

7. Documentation

If you establish documentation requirements, you are responsible to assure that those requirements are met. You need to specify what needs to be documented, when, by whom, and what needs to be done with the documentation. You need to state how progress is tracked to assure the documentation is complete and available for reference and/or verification. 

RECOMMENDATION: use caution when establishing documentation requirements. Rely on normal procedures to the fullest extent possible. 

8. Assumptions - Definition and Distinctions

Common corporate practice and the dictionary lump multiple types of statements under the term assumptions. Merriam Webster online defines assumption as: the taking up of a person into heaven; an assuming that something is true; a fact or statement (as a proposition, axiom, postulate, or notion) taken for granted. This can leave the process on shaky, untested ground. 

One of the purposes of a draft is to present assumptions so they can be tested, challenged and moved to something more solid. In a draft, you should be ready to accept challenges to assumptions. As an example, if you are not clear which tool would be best for a particular purpose, you might "assume" that MS Project will be used. This would be an invitation for readers to rebut your assumption by proposing alternatives or giving you reasons not to use it. On the other hand, if you have given it some thought and MS Project should be used, state that in the form of a direction. Some companies use "assumptions" and "non-negotiables" to differentiate between what is open for discussion and what is not. Some other options are: constraints, declarations, and assertions. 

Separate assumptions that need to be tested from statements of fact. Make it easy for the reader to know what you consider open to and worthy of further discussion and what is not negotiable.  If you direct the use of a particular procedure or form, either tell the reader how to get a copy of the procedure or form or acknowledge that is has to be developed. You can use an assumption to force the development of a form or procedure to support what you are doing. But, the simple assumption that a form or procedure will be developed by some unnamed person or persons will not make it happen. Use your assumption about something that needs to be developed as a tool to get the development process started. 

You can send mail to Lyon, Popanz & Forester at hal@lpf.com

Lyon Popanz & Forester's home page

Updated October 2, 1998