Are 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, 2^nd 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 http://www.cotc.edu/Academics/Documents/2017-2018%20policy%20and%20procedure%20final.pdf 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 https://www.linkedin.com/pulse/preparing-operating-manual-chemical-plant-aijaz-ali-mooro 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 http://igs.nigc.ir/STANDS/IPS/e-pr-290.PDF  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 https://policy.ucsc.edu/resources/images/GuidetoWritingPolicy.pdf 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 http://www.hse.gov.uk/comah/sragtech/techmeasoperatio.htm Accessed 2017/09/25. [Comprehensive outline of topics and contents]
6. Instructions for completing the policy template. Central Ohio Technical College. Online at http://www.cotc.edu/Discover/Documents/Instructions%20for%20Completing%20the%20Policy%20Template.pdf 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 http://www.rmpcorp.com/wp-content/uploads/2014/02/GCPS_2013_TipsforEffecitveOperatingProcedures.pdf Accessed 2017/09/25/
9. Sutton, Ian (2015). Chapter 6 Operating Procedures. IN: Process Risk and Reliability Management, 2^nd 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]

References

1. (no date). Developing policies, protocols and procedures. Online at http://www.iaith.cymru/uploads/general-uploads/policies_and_procedures_jan_13___2_.pdf Accessed: 2017/09/13.
2. 9000Store (no date). Process vs. Procedure vs. Work Instruction. Online at http://the9000store.com/articles/iso-9000-tips-process-procedure-work-instruction/ Accessed: 2017/09/13
3. Anderson, Chris (n.d.) What’s the difference between procedure and work instructions? Bizmanualz. Online at https://www.bizmanualz.com/write-better-procedures/are-procedures-the-same-as-work-instructions.html  Accessed 2017/09/21.
4. Knowledge Process (no date). Differences between a policy, process, and procedure. Online at http://www.knowledgeproc.com/proper-process-policy-procedure-methodology/what-are-the-basics-writing-policies-processes-and-procedures/differences-between-a-policy-process-and-procedure/ Accessed: 2017/09/13
5. Mind Tools (no date). Writing a procedure. Making sure things are done without mistakes and omissions. Online at https://www.mindtools.com/pages/article/newTMC_78.htm Accessed: 2017/09/13.
6. Sutton, Ian (2015). Chapter 6 Operating Procedures. IN: Process Risk and Reliability Management, 2^nd 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