When starting a project to build process docs and SOPs, most people envision themselves sitting down and writing out all the documentation until it’s this wonderful little manual that everyone wants to use and read.

If they’re the one that also does all the work, this is fine.

When someone documents a process for a workflow they don’t actually execute, problems start to appear quickly.

For example, there is generally a difference between how a manager thinks a process is being executed and how it’s actually being handled. If the former is doing the documentation, it’ll never connect or work for the team that actually needs to use the docs.

The solution

Fortunately, the solution is simple: Empower your team, the people doing the actual work, with the ability to rapidly document their own workflows.

The process should work something like this:

1. Pick the right tool. One that makes creating docs super easy. (Making docs easy to build for anyone is one of the reasons I built Arvo)
2. Create a basic resource to guide your team on how documentation should be made.
3. Ensure your team has the ability to prioritize documenting their processes.
4. Once a process is documented, others can review it for clarification and consistency.
5. Publish and announce the new resource’s availability.

Summary

1. Pick the right tool for the job.
2. Create standards for how to document processes.
3. Empower your team with the ability to create their own documentation.