A Writer’s Guide to Documenting Procedures

Written procedures are key to successful food and beverage organizations; here are ways to keep the writing process from becoming a struggle.

By Scott J. Glaser of DeIorio Foods

Why do organizations struggle when it comes to documenting their procedures? How can we make the process of documentation more manageable?

Written procedures document the common tasks any organization relies upon day to day. These tasks make it possible to deliver products that consistently meet customers’ expectations. The benefits of written procedures are many: They provide a reproducible method against which efficiency can be measured. They can be used to engineer safety, quality, and cost savings directly into a task. They give managers a means by which to check training comprehension and establish the basis for corrective action. Written procedures are a common requirement for third-party audits.

There are many reasons the writing process can be a struggle. It is time consuming. The writer’s scope can be overly broad and unfocused. Support for the writer’s efforts may be lacking. The overall task can seem too daunting. Whatever the reason, overcoming these struggles should be a top priority; a systematic approach is all you need to keep your writing process on track.

The job of writing should not be left to one individual to complete in isolation. It would be nearly impossible for one person to understand and communicate each task perfectly. Your organization should establish and support a writing team. There may be only one author but it should be a collaborative effort between the author (technical writer), the subject matter expert (one who understands the procedure best) and the approving authority (usually a department manager or higher). Each of these people has a specific role to fill in the writing process.

The subject matter expert, who performs the task every day, might be able to perform her job as second-nature but she may find it difficult to communicate the steps required. And the manager might have additional safety or regulatory steps he wants included. The technical writer must use his skill to best present all relevant information from these and other input sources (e.g., user manuals, test methodology, maintenance experts, etc.).

The following tips are designed as a way to organize the writing process for the author.

Scope: Start with determining the scope of all the procedures you wish to document. Are you documenting all the tasks for a certain position? For a certain production line? For an entire department? Compile a list of each unique procedure you want to document. This will become your master index. Use your master index as a checklist to gauge your progress throughout the writing process. When determining which tasks to include at first, write down all known tasks. You may build or pare down the list from there. It is important to keep in mind that certain procedures can be the template for similar tasks which will save time by not having to recreate as many procedures from scratch. You must also identify to whom each procedure applies. The responsibility assigned for executing each task is essential for holding employees accountable once the procedures are published.

Outline: For each procedure, begin with a basic outline of the task. Sum the procedure up into its basic steps. At this point, these should not be very detailed. Remember, you are not the subject matter expert so a rudimentary understanding of the task is all that you require.

Observe: Watch the subject matter expert demonstrate the steps. Flesh out additional obvious steps you may have missed. You may also want to observe others who regularly perform the same task to get an idea of which steps make the overall best practice.

Refine: Ask the subject matter expert to look through the written procedure with you. This will give you an opportunity to ask each other questions to make the steps as clear as possible. The steps should be written in such a way that a new trainee with little experience can understand and execute them. Do not assume that the reader will understand the implied sub-tasks. If there is any question, write everything out. You may find certain steps in a process are, in fact, so complex that separating out another procedure is appropriate. Feel free to add the new procedure to the master index to be written later.

Test: Have the subject matter expert oversee a trainee or someone else with little experience as they attempt to follow the steps. This is where you can work out and annotate the practical details of the procedure. If the trainee is struggling to follow the procedure as written, further refine the text. Testing is crucial. Until trainees are getting the consistent results you expect out of the procedure, keep refining.

Approve: Submit the procedure to the approving authority for review and publication. Those employees that will be expected to follow the procedure need to be notified this is now the new standard. The approving authority will also want to periodically review your procedures. Subtle changes or major overhauls in your process can occur over time even if the resulting product remains unchanged. With periodic maintenance, documenting these changes can be more easily managed. Annual review should be sufficient for most purposes.

Written procedures document the common tasks any organization relies upon day to day. These tasks make it possible to deliver products that consistently meet customers’ expectations. The benefits of written procedures are many. Written procedures provide a reproducible method against which efficiency can be measured. They can be used to engineer safety, quality, and cost savings directly into a task. Written procedures allow managers a means by which to check training comprehension and establish the basis for corrective action. Commonly, written procedures are a requirement for third-party audits.

With so many benefits it seems obvious that your efforts would be well-placed in making your organization’s written procedures as robust as possible. Documentation is not its own end. With so many resources invested in these documents, they should be functional, after all.

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments