A colleague recently shared a harrowing story of how she spent half a day searching for the current policy governing her company’s expense reimbursement. She found a current version posted in SharePoint, as well as an earlier version distributed via email, and even a printed copy hidden away between two other 8.5 x 11 binders marked “2023 – FINAL” – on top of several other binders that were similarly marked and contained earlier versions of the same policy. In the end, she made the best of a bad situation and did her best to guess how she thought the policy would finally be written when it was all said and done.
A document that contains a company’s policy is considered to be a part of a company’s system only when the document is treated as a system.
The quiet cost of messy documentation
Most policies are not “badly written.” It is the surrounding system that fails. I mean the documentation of the process of writing the policy; the review process; the meeting at which it was approved; and the repository to which it was then uploaded. The fact that half the company cannot find the current version of a policy is not a problem with the written policy. It is a problem with the documentation of the process of writing the policy, or the lack of one.
For example, a company might be found to be compliant with a company’s expense reimbursement policy as it was 18 months ago.
The real cost of poor documentation is the organizational confusion caused by documentation that the organization cannot trust. It leads to people reading the official company policy and then asking colleagues about how to comply with the policy or procedure. And when that fails, it leads to people making it up as they go along, and thus causing the very inconsistencies that the official policy or procedure was attempting to avoid.
This particular failure is fascinating to me, because it is preventable and yet so very common. It’s not a failure due to ignorance, but rather due to friction.
What documentation software actually changes
This brings us to the point of the post. Policy and procedure documentation software does not fix to change bad policy, bad process, or to stop people doing bad things. It does, however, change where policy is documented, where it is updated, and where it is distributed to people who need to read it in order to comply. That’s a huge change, and a change that is often larger than people realize up front.
Here are a few of the key changes that occur very quickly when documentation is placed into a well-designed documentation tool.
- Single source of truth. One version exists. Everyone links to the same place. No more “which PDF is current?” conversations.
- Controlled review and approval workflows. Changes go through a defined process before they go live, not just whoever happened to have edit access last.
- Conditional content. You can maintain one master document and publish different versions for different roles or departments, without maintaining separate files for each.
- Searchability that actually works, so people can find what they need without filing a support ticket to your documentation team.
Of all the differences that documentation software can make, perhaps the biggest single difference is whether documentation is “findable” or not. Is your documentation well organized and easy to find, or is it hiding somewhere where people are unlikely to find it even if they are looking for it? A library full of books does no good to anyone if the books are all misfiled. Similarly, your compliance policy is technically available but not practically available if it is buried somewhere where no one can find it.
Stuck in the Adoption Stage
Adoption. Almost always adoption.
Before we delve into a comparison of the workflows involved in the majority of documentation tools available on the market today, it’s important to note that the greatest failure point of documentation, for better or for worse, is the natural resistance to change in how a team functions as a group and as individuals. Whether it’s updating a shared Word document that’s already been through rounds of edit, in which multiple people have added in their track-changes, or, worse, printing out a large stack of paper in order to review and edit, there are many aspects of a team’s normal processes that will immediately reassert themselves as soon as the new tool is brought into the mix. The potential for huge amounts of value, however, in changing how a team’s documentation is managed far outweighs the immediate frustrations of getting a team to switch from old processes to using a new set of tools in order to manage that documentation. That’s what I’m hoping to help outline.
Most of the work in really good documentation actually takes place outside of the authoring environment. A lot of the hardest work is in setting up a process, training a team, and then even just maintaining that process, which in itself is a really tough process to enable with current technology.
A workflow example worth stealing
On the other hand, I showed them how one would update a remote work policy (for the 3rd time this year). Currently this is done by HR sending out a Word document to Legal and Department Managers for them to add their comments via track-changes. After that, HR would go through all of the changes, reconcile any contradictions between managers and then upload the new policy to the relevant internal company web site. There are lots of places where things can go wrong, such as not archiving the previous version of the policy and key people not knowing that the policy has changed.
Next, documentation software structures the process for updating policies and procedures. For example, the remote work policy would reside in a structured authoring environment, such as a MadCap Framed or Flare interface. Legal then reviews the document within the same system. The reviewer’s edits are then reviewed by others within the system, such as department heads, and when the document is finally approved, it is published to all locations where the policy is referenced (e.g. employee handbook, company Intranet), simultaneously, with a complete version history. This can greatly reduce the review cycle of a policy, for example, from weeks to days, not because people are working faster, but because there is less friction in the process.
As I mentioned above, there are a variety of different documentation software products available for documenting policies and procedures. All of the teams that I’ve worked with that are using good documentation software have reported a significant reduction in the time required for the review process – sometimes in half or better. I’ve found that this is not because team members are individually working any faster; rather the number of places where a policy can go wrong has been reduced to nearly zero. So for example instead of sending out a Word document and having people add their comments in the form of tracked changes, which soon becomes a mess of different colored text, reviewers can add their comments directly in the system. The comments are then displayed one on top of the other for each reviewer, and the reviewer can turn them on and off as needed. Once all the comments have been dealt with the document is then published in whatever form is required (for example as a web page, or as a downloadable PDF) and the old version is archived. All the people who need to know that a new version has been published are then notified.
Comparing the two approaches
| Area | Traditional document management | Documentation software |
| Version control | Manual, error-prone, often inconsistent | Built in, automatic, auditable |
| Review workflow | Email chains and shared drives | Structured approval process in-tool |
| Publishing | Copy-paste to multiple locations | Single publish to all outputs |
| Findability | Depends on folder structure (optimistic) | Indexed, searchable, linkable |
| Compliance risk | High, especially with stale content | Lower, with clear update history |
The part that often gets overlooked
Policies are communication. Most organizations treat their policies as legal documents written once and then filed away in a dusty part of the organization. These documents are rarely referenced unless something has gone wrong, such as during an audit or after an incident. However, when documentation software brings genuine structure and accessibility to your compliance policies and other procedural documentation, these critical resources become working resources to support your day to day activities. Employees and others can search for needed information and find current procedural guidance that has been written and reviewed by subject matter experts. Employees can refer to specific clauses in conversations rather than paraphrase from unreliable memory.
Policies are communication. When documentation software is used to great effect, policies and procedures become resources that people use all the time. They are looked up by employees before they do anything. They are referenced by managers in conversations by reference to specific clauses. They become a living, breathing part of how work is done, not something that is pulled out of a filing cabinet at the last minute during an audit or after an incident.
(Also, as I mentioned before, the ROI on good documentation is quite hard to measure because it’s not just a matter of how much time you save in review cycles. There’s also the value of having made the correct decision, avoiding confusion, and having better onboarding of new employees.)
Turning written policy into working resources is what good documentation infrastructure does. It is far better to read a list of features in a software comparison chart than to read about how that software will bring about this change. The technology is the enabler. The outcome is what matters.
In conclusion, good documentation is very important. The documentation must be based on a solid process, and it should be a good working tool, a resource for your employees.