Several recent attempts to communicate with IT staff and business units have demonstrated the difficulty of communicating even simple concepts to busy people. You have a large amount of information  to communicate, and your 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 expected to cast stones, that is how they get their job done. Unlike those who have not sinned, 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 imposing future documentation requirements 
• Separate assumptions that need to be tested from statements of fact 

1. Use A Dictionary 

2. Scope -- Less than the Entire World

3. DRAFT -- So What?

4. Addresses in the Document

5. 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 read and unserstood 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.)
• 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 existing 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: givens, understandings (It is our understanding that ...), 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.