This guest post was written by Ginny Critcher and Ellis Pratt, both of who have over twenty years’ experience in writing policies and procedures and many years’ experience in using MadCap Flare. They are directors at Cherryleaf , a technical writing and procedures writing services company based in the United Kingdom.
Policies and procedures have a reputation for being dry, boring documents that are hard for staff to read and difficult for the organization to write. It needn’t be that way. Here’s some advice on how to write policies and procedures.
What Does the Organization Want?
Let’s start by looking at the reasons why organizations need to write policies and procedures.
Sharing the vision: In most cases, senior management will have a vision for the company that it needs to communicate. They need to tell staff about codes of conduct, compliance, behavior, and the way an organization wants to be perceived, which is typically disseminated in the form of an employee handbook or procedures manual.
Changing the business: Whenever there is a change in the organization, such as the introduction of new systems, this needs to be passed on to staff.
To prevent a mistake from happening again: Often when something goes wrong, one of the preventative measures is to develop workplace policies on how to avoid that mistake from happening again.
To understand the business: If an organization merges with another, it can result in senior management not knowing how the entire organization works on a day-to-day basis. If departments are merged or reorganized, then this can mean they feel they don’t have control.
Writing Policies and Procedures
Successful organizations tend to have a compelling vision for the future, which staff works together to achieve. They’re able to communicate:
- What the organization and the teams within it are doing. Their goals and vision for the future.
- Why they are doing these activities. What’s at stake, and why it matters.
- Where each person fits in. What everyone’s roles and responsibilities are.
You can do this through your organization’s policies and procedures.
Good policy writing and documentation should help pass on the values of the organization, for example: that it treats people equally; it checks payments are made for legitimate reasons, etc. It should also explain why the organization has an existing policy or procedure in place.
In every procedure document, it should be clear who should do what. In other words, every procedure should have a roles and responsibilities section.
The policies and procedures also need to be coherent. Often, we find the information is contradictory. One procedure states “do this”, another states “don’t do this”. Fixing this requires a staff member to review each policy and procedure to check for consistency across related documents. This governance and editorial role can also help identify the policies and procedures that are hard to understand, hard to find, out of date, or incorrect.
Applying Best Practices From Technical Communication
The principles commonly used by technical documentation writers can help you create policies and procedures that are easy to access, understand, and remember:
- Breaking the information into small, manageable units.
- Limiting each unit of information to a single topic. For example, not mixing policies together with the procedures.
- Labeling each unit of information. This can help the reader scan for the information relevant to them.
- Being consistent with the terminology you use.
- Being consistent in the way you organize and format the content.
Supercharging Your Policies and Procedures
Policies and procedures have a reputation for being boring and hard to use. It can be difficult to find the information you need, which can mean people have to wade through a lot of pages to find it.
There are a number of things you can do to make the information more usable.
Policies tend to be the same for all parts of the organization, but procedures often differ between locations. For example, the fire safety information will differ when it comes to the fire escapes, the fire marshals, and so on. A better way is to have a guide that is specific to each location.
You can do this by using conditional text, marking sections in topics for different audiences. You can also use the table of contents feature in Madcap Flare to add or remove topics from the guides you want to publish.
This process enables you to create different, more personalized, guides, all from a single source.
Don’t Force People to Jump Around
Many procedures are related to other procedures. For example, an email procedure is likely to be affected by any antivirus and portable media procedures. If you add a link or a cross-reference to these other procedures, you are expecting the reader to jump around.
One solution to this is to embed summaries of related policies and procedures in the topics. This is similar to having warning boxes. The Snippets feature in Flare is useful for this; write your summary once, save it as a Snippet, and re-use as you need it.
Create Different Outputs From the Same Source
How will your content be accessed? Via a website? PDF? Word documents? On a mobile device? If you have staff who work in the field as well as in an office, perhaps all of these.
People in different job roles will be interested in different topics. They will probably be only interested in the procedures that directly affect them. Flare enables you to create different navigation routes for different audience types. The buzzword for this is “faceted navigation”.
Before you start writing, you (or your organization) need to make decisions on how the content will be created, not only now but in the future as policies require regular updating.
It makes a huge difference when policies and procedures are written in a way that is clear and easy to understand. One of the ways to do that is to learn best practices on how to become a technical writer and study different technical writing examples. In addition, consider taking into consideration these points before you start writing:
What is the policy?
Before any policy development gets underway, an organization must decide what their new policy is regarding specific areas.
These decisions are made in various ways: via a dedicated policy committee, through a steering group set up specifically for the task or individual areas of the business may be responsible for creating their own policies.
Whoever is tasked with the actual writing of the policy must have a clear understanding of what the company policy is so that they can get that knowledge across to others.
How should it be delivered?
You may decide that your content needs to be accessed in more than one way e.g.: via a mobile device, PDF, website, etc. The presentation formats are usually different for the various mediums. One way to tackle this is by single sourcing.
Powerful technical authoring tools such as Madcap Flare enable single sourcing, meaning you only need to write and edit your content in one place/once? and it can then be re-used across different mediums. This saves time, effort and cost.
Who is the audience?
Do you have audiences with different needs?
Who will write it?
Potentially anyone in an organization can write them. They know your organization and the way it works. You have a lot of knowledge of how tasks are performed and the way your business conducts itself. If you have missing gaps in your knowledge you will know the right people in your organization to help you with missing information. There are also external professional policy writers who bring their expertise and knowledge of many businesses in order to write professional high standard and effective policy documents.
Before you begin to write anything:
- Be clear about what your organization’s policies actually are.
- Decide on an authoring tool.
- Review your existing policies.
- Decide how you will present new content – by task, role, etc. Think about your audience.
When you begin to write: Use the powerful features of your software tool to help you create the content, ideally using single sourcing, snippets, faceted navigation, etc.
Editor’s Note: Originally published on October 21, 2019 and refreshed on May 12, 2021.