Project-Managing Your Writing

Wouldn’t you like to write better contract proposals, business plans, executive summaries, recommendation reports and internal business communications, such as e-mail?

The element of persuasion is what sets business writing apart from other forms of writing. Professional business writing convinces your audience to do what you want, even though there may be initial resistance.

You need to project-manage your writing by breaking it into tasks (WBS), scheduling them (Gantt Chart), and identifying any resources you need (RAM).

A four-step technique is:

1. Identify the objective

• What exactly are you being asked to write about?
• What do you need your readers to do when they have read your text?

2. Analyze your audience

• Who are your readers?
• What do they need to know?

3. Research

• What sources will you use for your research?
• Do you need help from a Subject-Matter Expert (SME)?

4. Draft, edit, and revise

• Improve the quality of your writing

When Stephen King finishes a book he puts it away for 2 months and then looks to cut 15% before his editor even sees it.

Crow and Parkin-Dillon suggest the POWER process for project-managing your writing.

Prewrite

• Plan
• Identify objective
• Analyze audience

Organize information

• Perform research
• Generate topics
• Reduce topics
• Structure topics

Write

• Prototype document
• Test prototype
• Draft document

Edit

• Review
• Proofread
• Mark up pages

Rewrite

• Implement changes

Editing and Rewriting are iterative and interactive steps of the POWER process. Using the POWER process helps you avoid last-minute crises and meet due dates with ease.

Crow and Parkin-Dillon recommend these approximate times for a writing project:

• Prewrite and Organize—40 percent

—   Plan

—   Identify scope and  objectives

—   Identify audience and scenarios

—   Research

—   Generate topics

• Write—30 percent
• Edit and Rewrite—30 percent

—   Review and edit

–    Proofread

—   Revise

—   Publish

Keep Prewriting, Writing, and Rewriting Separate

You need to plan, draft, and rewrite your document. Don’t rewrite as you write. You’ll drive yourself crazy and probably never finish.

Many people think revision means they somehow failed. Nothing has ever been written that wouldn’t have been improved by taking the opportunity to revise it.

Professional writers know the real work is done in the rewriting, not in the writing.

Persuasive writing is about assessing your customers’ needs and responding directly to those needs. Audience analysis, brainstorming, outlining, establishing credibility, stating credentials, avoiding logical fallacies and appealing to intelligence are persuasive writing tools and techniques you can use to be successful.

For more on how to project-manage your writing, have a look at Learning Tree, Intl. Course #219: Business and Report Writing Introduction.

James L. Haner

Using a Style Guide for Your Project Documents

Did you ever read a project document and immediately recognize that it was written by many different people? It can be easy to tell when we stick together different sections of our documents that were written by different authors. Sure would be nice if all of our project documents looked like they were written by one person, even if that one person is actually several members of the project team. To achieve this, I recommend that every project team use a style guide to define how they will write the contents of their project documents. A style guide is a great way to define your team’s writing style, diction and grammar use so our documents are more cohesive and more readable. Some organizations have style guides that folks use across all types of documents. Other organizations don’t have anything like this. Style is the “technical issues” within your documents, governing your team’s use of acronyms, capitalization, punctuation, numbers, structure and basic grammar. Let’s take a closer look at these items and how we might address them using a simple style guide.

Acronyms can be confusing to your readers if they don’t know what they stand for. Every organization seems to have its own version of this “alphabet soup”. Sometimes you can have the same letters in an acronym that stand for two entirely different things. One best practice is to spell the acronym out on its first use in any document. You can also include an acronym list at the end of your document for your readers.

Capitalization can be done in a variety of ways within a project document. The team needs to decide whether or not they will capitalize proper nouns, names, titles or other words. Once we know the rules, everyone needs to apply them consistently. I once worked on a project where we wrote our requirements document and upward capitalized every user type just to make sure that our readers paid closer attention to who was involved with the capabilities we were defining.

Punctuation offers a lot of challenges in a project document. The team needs to decide things like whether or not to use a comma after the next to last item in a list, right before the “and”. Then we all need to do it the same way. Are we listing items in our document like “… one, two, and three…” or are we listing like “… one, two and three…” For the sake of our document readability, we need to use punctuation correctly and consistently.

Numbers are also an interesting topic in our documents. Do we use the numbers themselves, do we spell out their names or do we use some combination of the two? For example, do we use the numbers like 1, 2, 3, 4, 5, 6, 7 and so on or do we spell them out like one, two, three and so on. Or we could choose to spell the numbers out from zero through ten and then use the actual numbers for 11 and above.

Structure is the way we decide to put the pieces and parts of our documents together and build their contents. I am a big fan of using project document templates and outlines for common project documents to be consistent in how things are structured and what content the documents contain. You also need to decide about sentence structure and what’s allowable. For technical writing, I think simple sentences and plain language are the way to go.

Grammar is the system of rules defining our language structure. It is the way we use our words, what their functions are and how we put together their relationships within a sentence. One grammar decision we need to make when writing a project document is whether we all use active or passive voice. Active voice means that the subject of the sentence does the action of the verb, focusing the reader’s attention on the performer of the action (who does what). Here’s an example of an active voice sentence: “The committee reached a decision.” Passive voice is where the subject of the sentence receives the action of the verb versus performing that action themselves. In passive voice, the performer of the action sometimes disappears or is hard to discern. Instead, passive voice sentences emphasize the receiver of the action. The previous sentence can be written this way: “A decision was reached by the committee.” Which one would your readers prefer?

There are many style guides out there for the project team to use, ranging from the massive Chicago Manual of Style to a very nice technical writing style guide that I like very much, The Handbook of Technical Writing. Many industries have industry-specific style guides, as do many organizations. There are country-specific style guides out there as well. If you don’t have a project-level style guide, the team can easily build one for themselves.

In addition to the style guide items I have already discussed, you may want to consider including some or all of these elements in your project’s style guide: 

• Avoid phrases
• Avoid the word “not”
• Omit unnecessary words
• Use simple words
• Avoid foreign words
• Avoid pronouns
• Eliminate synonyms
• Minimize your use of modifiers (adjectives and adverbs)

Remember that your goal is high-quality, readable and understandable project documents across the project life cycle. Sometimes using equations, diagrams and other graphical forms of communication can be clearer than using words, so our style guide will need to address how we use those as well.

If you are looking to refine or define your technical writing skills for your projects or organization, consider Learning Tree’s 4-day introductory course on technical writing.  Happy project documenting! 

Susan Weese

A Step-by-Step Guide to Successful Technical Writing

Do you and your team members have problems writing these types of documents?

• Product specifications and descriptions
• Operating procedures
• End-user documentation
• Definitions of terms
• White papers
• Portions of
• Proposals
• Recommendations
• Feasibility studies
• Documents that explain “how or why”

 “Yes?” . . . then the answer to all of your problems is:

 “Produce less and have it used more. Write what your audience needs.”

 The key to successful writing, is not knowing your subject area (though you have to do that); the key is knowing your audience. You begin with the audience analysis and go on from there.

1.    Analyzing the audience: You begin by understanding the audience FIRST. This addresses productivity issues and doing what matters. By knowing your audience, you can analyze what they will do with the information. Most technical writing situations can be analyzed in terms of how the audience will use the information.

A step-by-step process for analyzing the audience follows:

 1. Determine the audiences: Who, exactly are you writing for?

 2. Prioritize the audiences: You need to prioritize multiple audiences in terms of size, power, impact on the product’s future, importance to the business process etc. Do you need to produce the user manual before the executive summary? Ensure what MUST be done is done. It may not be possible to support every audience.

3. Determine each audience’s needs; what do you have to do meet the needs of each audience?

4. Prioritize the needs; identify the critical needs for the important audiences: critical in terms of the problems that the audience has to solve, importance of the problems to the business process/the users. You may not be able to support every need.

5. Design the documents; Use the information in designing the documents – some documents will meet multiple needs.

2.    Determine the scenarios: This is where you figure out the situations in which the readers will use the knowledge. Understanding your audience isn’t enough—you must also know how they intend to use your information.  At this point, you want to start focusing on the scenario as a primary way of understanding what information your audience needs and, as a result, that you need to know. “When will your audience really need your help?” This question helps bring the audience needs forward.

The two steps for defining scenarios are:

First: Determine the scenario, as defined by the audience

1. Goals

         i.    What the audience wants to or must accomplish

         ii.    The scenario ends when the goal is accomplished

1. The trigger

         i.    What causes the audience to need the information?

1. The tasks

         i.    What the audience does to reach their goals?

Second: Analyze to determine what to write

1. Determine information required by the audience

3.    Research: You’ll look at research . . . what you’ll come to call the “knowledge domain” . . . what you need to write about (which is never everything that could be written about). You use the information from the previous two steps to figure out what you actually need to know and write about. You’ll be looking at issues around tacit knowledge (what you assume the reader knows) and explicit knowledge (what your document explicitly states) which are key to making sure that everything necessary is covered.

4.    Writing: To write a document worth reading, you’ll need to create great sections.

Different kinds of information work best with different ways of presenting.

Concept

• General-to-specific
• Specific-to-general
• Compare and contrast

Scenario

• Order of importance
• Effect and cause
• Problem-methods-results

Procedure

Narrative

5.    Editing: Editing is about finding the problems, which leads you back to writing to fix the problems. Effective technical writing is all about rewriting/enhancing.  Rewriting is NOT a failure on your part. In fact, it’s where the quality and excellence happens.

6.    Testing: All through this, at every stage, you’re going to look at the testing that can be done to make sure that you arrive at the publishing phase with the right thing.

Your new definition for successful technical writing is:

“To help people do something or to make a decision.”

For more on successful technical writing, check out Learning Tree’s course Technical Writing: A Comprehensive Introduction.

James L. Haner

 

Writing as Part of Effective Project Communications

Effective project managers and business analysts communicate well with others, in writing and when they speak. Be careful not to spend too much time documenting, recording and sharing project information. Even though this work takes place across the project life cycle, it is essential to only document and communicate what is necessary.  You also need to make sure that you document and communicate clearly.

If a requirement can be interpreted in more than one way, it is ambiguous. Choosing the right word is not always easy. Where terms have multiple meanings, it is best to define each word in a glossary based on the document’s audience, scenario, and purpose.

There are inherent problems with “natural language”, which is the way tend to we speak and write. Natural language lends itself to multiple interpretations, includes too many compound sentences, has multiple definitions for words, and uses imprecise adjectives, imprecise conditional instructions, and compound conditions.

On the flip side, structured language combines the language elements with structured programming rules.  For example, structured English uses imperative English verbs, terms are defined in a data dictionary, and reserved words for logic such as “If,” “Then,” and “Else.” Our goal as effective  writers is to strike the right balance between understanding and precision in our project documents.

If you are not a good technical and business writer, you will need to master these skills.  You must be able to write effectively for different contexts and audiences on your projects. Effective writing on your projects requires the following minimum set of written communications skills:

Broad vocabulary. Words are your primary medium for project communications. Make sure you speak the language of the business where you are working. Make sure the project team speaks and writes in a clear way as well.  If the users don’t understand what you are describing, how can they know if it will work for them?

Strong grasp of grammar and style.  Watch your sentence structure and your style of writing.  Most experienced business analysts and project managers can write in a number of styles, depending on what they are documenting and the audience for that document.  Keep sentences simple and write in a concise, plain style to maximize understanding.

Understanding of idioms and terms. Watch the words you use in your project documents. Use words that say what you want to say, no more and no less.  Remember that project documents are intended to be clear and to the point versus being a creative writing exercise with a lot of words that no one understands.

Be sure you are comfortable explaining the basics of information exchange using the sender-receiver model. This model governs both written and oral communications on your projects. Senders package or encode messages that are sent to the receivers. The receivers then unpack or decode the messages. Transmitting gets information from the sender to the receiver for both spoken and written forms of communication. Decoding of the received message is performed by the receiver. This is where the receiver converts the message to a form that they understand.

Happy writing!

Susan Weese

To learn more about how to improve your writing skills, check out Learning Tree’s Business and Report Writing course.