Category Archives: policy, process, procedure

Word choices affect understanding

In formal writing, one of my pet peeves involves the misuse of prepositions. High on my list is the ubiquitous use of the word “on” to the exclusion of other, usually more accurate, prepositions.

“She spoke on the space shuttle.” Was she really aboard the space shuttle and delivered a speech to its crew”? Although we know what it means (she talked about the space shuttle), it’s likely misunderstood, at first. Understanding might require a re-reading, and one might wonder what other misleading or outright wrong statements the writing contains, compromising the writer’s credibility.

Such poor word choices are not so dire in casual conversation. However, in formal writing, this type of slip can affect understanding, job performance, and safety – safety of life and limb, facilities, or the environment.

An engineer told me that he remembers not knowing a thing about his first job out of college. He had the book learning but not the practical knowledge and experience that he needed. He could have made dangerous work decisions if the common belief “they’ll understand it” prevailed.

Poor, inaccurate word choices can confuse and cause mistakes by workers who misunderstand written instructions because they:

  • Are new to the job or field (not everyone understands everything from day one),
  • Have limited reading skills (they’re out there, effectively hiding their disability),
  • Function (in the U.S.) with English as a second language,
  • Won’t ask for clarification because they don’t want to be perceived as stupid, and
  • Are reading a translation to another language, which is faulty or downright wrong because terminology did not translate accurately.

For technical documents (especially procedures and other work instruction), accurate word choices enhance understanding, efficiency, effectiveness, and safety. While eliminating the need to re-read passages, clear writing uses fewer words and is more engaging.

So, if your technical editor questions the phrasing or word choices of a sentence, paragraph, or section, help him or her in the goal of writing for readers’ understanding. If your technical editor attempts a rewrite that changes your meaning, understand that the original writing probably was confusing, and help him or her to rewrite for clarity.

Remember, communication is not simply conveying your message but is having your message received and understood. Your word choices can foster or inhibit understanding.

By the way, I wrote this article on about word choices on Thursday on using my computer.


P Soup : Tips for Writing Policies, Processes, and Procedures

Psoup2Are you writing or leading a team to create this montage of documents and wondering “why me?” Have you no to little training or experience for the task? It’s not your (usual) job? Then no wonder you’re confused. This can be disorienting terrain to navigate. Let’s look at how to make it easier, starting with the recipe—the who, what, where, when, why, and how—for producing this P soup.

Why Make P Soup?

If effectively created, implemented, and sustained, this P soup drives a company’s mission and business success (client satisfaction, referrals, profits) as well as employees’ successes (conduct, job performance, promotions). For industrial facilities (such as oil and gas, chemical, and food processing), success encompasses safety (of people, the plant, the environment) and regulatory compliance, exponentially increasing the importance of this documentation.

Who Does It?

Why you? Someone in the company believes that your experience makes your input valuable.

Usually the writing team comprises a diverse group of professionals, including subject matter experts (SMEs) such as engineers, safety professionals, and facility operators plus regulatory specialists, business analysts, and lawyers.

Starting from the project launch, a technical writer also is an important resource. The late addition of this strategic partner is a poor decision. A technical writer brings to the table an expertise in document structure and content organization that adds value to document design and to streamlining project completion.

What are the Ps?

In other words, define your terms. Defining the pieces (the various documents) is the project’s foundation and should be a team priority. Consider each document type and agree upon its:

  • Purpose: each document type has its own purpose, which drives content
  • Content: what topics should each document contain
  • Structure: in what order content should appear (outline)

The technical writer can be an ideal facilitator for this discussion, especially if he or she will create the document templates.

With this initial organization, the subject matter experts and writers essentially can fill in the blanks. The project moves at an impressive pace. Each set of documents looks like all the others, and the users (employees, contractors) learn where to look for certain information.

(Note: we’re not even discussing here other parts of your documentation hierarchy, such as principles, protocols, guidelines, standards, checklists, forms, etc.)

Without this initial organization, the worst-case scenario is documentation that is disjointed, incomplete, unnecessarily repetitive, and unusable—ultimately undermining their purposes: safe operations, profitability, and success.

Even Authoritative Sources Differ

When I began one contract assignment, the procedure template I received struck me as a mixture of policy, process, and procedure, and, although nothing changed, I explained my understanding of each:

  • Policy: A policy is a set of rules, guiding principles, standards, or regulations. Examples: Office dress code, OSHA Regulations, or standards for using company email.
  • Process: A process is a series of procedures that are performed in sequence by different people. Example: The process of performing a car tune-up may include change the spark plugs, change the oil, and rotate the tires.
  • Procedure: A procedure is the steps to complete a task that is performed by one person. Example: The procedure to rotate tires may include remove all tires, check the wear of each tire and replace if necessary, check tire balance and rebalance tires as necessary, remount the tires on their new axle (refer to diagram).

Three authorities that define these documents are: (1) The structured writing process that many technical writers use; (2) Ian Sutton, a chemical engineer and prolific book author who has more than 35 years of experience in the process industry, and (3) the International Organization for Standardization (ISO)

Structured writing relies on five principles: chunking, relevance, labeling, consistency, and integrated graphics. Chunking, relevance, and labeling speak to document structure—to ensure that a document contains appropriate and necessary information.

Chapter 6 of Sutton’s book, Process Risk and Reliability Management, 2nd edition, 2015, is a nearly 100-page instructional narrative for writing an operations manual, including sound advice for planning an manual and example document definitions formats. His definitions of policy, process, and procedure mostly align with those of structured writing.

The ISO definitions of these documents differ slightly from those of structured writing and Sutton, and ISO includes another term—work instruction.

Work instruction is the fine detail of a procedure, and it might be referred to from several procedures – being maintained in one place instead of repeated (and updated) in all procedures. For example, “Procedure to Tune Up a Vehicle” might include: “Replace the spark plugs. Refer to Work Instruction: Replace Spark Plugs.” The work instruction details the tools to use, guidelines for selecting the proper replacement plug, instructions for removing old plugs and gapping and inserting the new plugs, proper torque, etc.

Refer to the figure, which compares the document definitions.


Further, the name of ISO’s sample procedure is “Customer Related Processes,” and the name of ISO’s sample work instruction is “Fabrication Procedure.” The two ISO sample documents contain about 90% of the same information.

No wonder we’re confused.

And that’s why it is all the more important to clearly define our documents and their contents before writing a word of content. To make sure we have identified a logical place for all content and everything ends up in its place.

Where, When, and How?

Although these elements are relatively easy to describe, the answers might well affect project outcomes.

Where is each team member’s workspace/office, plus the location of regular status meetings? If the team is geographically spread, the meetings might be conducted via telephone or web conference. How well each person functions with remote meetings can factor into the effectiveness of communication and, ultimately, the timeline.

When the work is done—usually when individuals have, or make, time to do their part, if this project is in addition to their regular workload. They must have the commitment to work it in and see it through. Consider how each author works best: writing their assignments themselves, receiving then revising a draft from the technical writer, being interviewed by the technical writer then reviewing the resulting draft.

How includes document control. The task of central coordinator might fall to the technical writer or a dedicated documentation control manager. It is helpful to work from files on a collaborative, network platform that has version control, such as SharePoint™. Tracking can quickly get out of hand if the review process is loose and the team uses email to exchange different revisions of documents. It is difficult to track the status of any or all of the documents. Agree upon and stick to meeting rules that might include: always have an agenda, start on time, stick to the agenda, be prepared to participate, use a “parking lot” to table time-consuming discussions and assign a person or persons to research and report options at the next meeting.

Suggestions for P Soup Success

Steps for your writing team are to:

  • Build a complete team.

Enlist active participation from the start by all resources that will be required, including a technical writer.

  • Create a document hierarchy.

What documents are needed for what purpose? The previous figure illustrates two examples of a document hierarchy, and it might be starting point for your project.

  • Outline the content for each document category.

Keep the outline consistent for each category. If one outline topic does not apply to a certain procedure, don’t delete it. Instead, address it with some standard text such as, “Not applicable to this procedure.” This way you are telling the document users that a topic wasn’t overlooked or inadvertently deleted.

  • List document titles, naming conventions, and primary authors.

This list is your document inventory and includes the name and deadlines of the author, technical reviewer, technical writer, and others.

  • Decide if document originators (authors) will write directly into document templates or use plain text and leave the templating and formatting to the technical writer/editor.

If authors will use the template, make sure to test the template, that font styles aren’t buggy and don’t change in the middle of a document. Use a minimum number of styles; standards are three heading levels, two bullet levels, and write for clarity and emphasis instead of relying on bold, italics, or underlining. Train the authors to properly use the template and styles so they don’t “break” the template or add text styles. Yes, the contents are most important, but the presentation affects readability and usability.

  • Define the review process, appoint a tracker, and follow the process.

Who are the first, second, and third reviewers? Will you have a group review input session? If so, come prepared to contribute. Who has final say in any discrepancy?

  • Review and understand the project’s style guide or editing checklist.

Style guides bring a consistency of style and voice to your set of documents. Your company might have a style guide that includes terminology to use or not use; whether to use British or American spelling exclusively or for only certain words; whether to abbreviate or spell out measures such as 3 inches, 3 in., or 3″. The technical writer/editor probably will create a project style guide, too, that supplements the company guide with elements specific to your project.

  • Provide training and orientation to the team

Provide training and quick-reference guides to the team for using the template and styles, the style guide(s), and the collaborative platform (such as SharePoint) as well as orientation to the writing and review process and ultimate authority if discrepancies arise.

  • Obtain consensus and agreement with the process.

All this forethought saves time and money in the long run. It guides well-written documentation, helps the project to move relatively quickly with few deviations, improves the quality of work, decreases errors and omissions, and increases the effectiveness of using the documents.

Annotated Resources

  1. Academic policies and procedures. Central Ohio Technical College, 2017-2018. Online at Accessed 2017/09/13. [An example of policies and procedures for a U.S. college]
  2. Ali Mooro, Aijaz (October 26, 2016). Preparing Operating Manual for Chemical Plant. LinkedIn. Online at Accessed 2017/09/27. [Guidance from a petrochemical professional regarding outline, conten, and approach to writing an operating manual]
  3. Engineering Standard for Plant Operating Manuals (2015). Iranian Petroleum Standards (IPS). Online at  Accessed 2017/09/13. [Standard of typical types of content and a table of contents (outline) for operating manuals]
  4. Guide to Writing Policy and Procedure Documents (1994). UC Santa Cruz. Online at Accessed 2017/09/13. [Suggested process to develop policies and procedures, questions to ask, templates, approvals, etc.]
  5. HSE (n.d.). Operating procedures. [Technical Measures Document]. U.K. Health and Safety Executive. Online at Accessed 2017/09/25. [Comprehensive outline of topics and contents]
  6. Instructions for completing the policy template. Central Ohio Technical College. Online at Accessed 2017/09/13. [A U.S. college’s guide to writing policies and procedures, such as that in resource number 1]
  7. Operations and Maintenance Assessment Guide for Wastewater Treatment Plants (April 2016). New Jersey Department of Environmental Protection, Division of Water Quality. Online at Accessed 2017/09/25. [Provides a list of typical Appendices for a manual and a checklist to determine the manual’s completeness]
  8. Scholtz CR, Maher ST (2013). Tips for the Creation and Application of Effective Operating Procedures. [Presentation] American Institute of Chemical Engineers 2013 Spring Meeting, 9th Global Congress on Process Safety, San Antonio, Texas, April 28 – May 1, 2013. Online at Accessed 2017/09/25/
  9. Sutton, Ian (2015). Chapter 6 Operating Procedures. IN: Process Risk and Reliability Management, 2nd Kidlington, Oxford UK: Gulf Professional (Elsevier). pp 272–369. [Specific to the process industry, but some content is helpful to anyone beginning to build a corporate manual]


  1. (no date). Developing policies, protocols and procedures. Online at Accessed: 2017/09/13.
  2. 9000Store (no date). Process vs. Procedure vs. Work Instruction. Online at Accessed: 2017/09/13
  3. Anderson, Chris (n.d.) What’s the difference between procedure and work instructions? Bizmanualz. Online at  Accessed 2017/09/21.
  4. Knowledge Process (no date). Differences between a policy, process, and procedure. Online at Accessed: 2017/09/13
  5. Mind Tools (no date). Writing a procedure. Making sure things are done without mistakes and omissions. Online at Accessed: 2017/09/13.
  6. Sutton, Ian (2015). Chapter 6 Operating Procedures. IN: Process Risk and Reliability Management, 2nd Kidlington, Oxford UK: Gulf Professional (Elsevier). pp 272–369. [Specific to the process industry, but some content is helpful to anyone beginning to build a corporate manual]

2018 March 6; updated 2019 August 8