Ask three people to bake brownies without a recipe, and you’ll end up with three different results. One may be fudgier, another fluffier, and one has a touch of cayenne for a little kick.
Those variations are fine if you’re feeding friends. But if you’re running a professional bakery, your customers expect consistent quality and flavor. So you write down a recipe with a list of ingredients and step-by-step instructions. That way, even a new employee can recreate your world-famous fudge swirl masterpiece.
The same holds true for any process in your organization. When you document and share institutional knowledge, the outcomes are more consistent. And your teams won’t reinvent the wheel every time they tackle a repetitive workflow.
Of course, most processes aren’t as simple as baking brownies. That’s especially true for large, complex projects with thousands of people completing millions of tasks using dozens of applications. Without documented business processes, employees duplicate efforts, are rarely “in the loop,” and generate a lot of superfluous data that buries the real truth.
Knowing how to document processes is critical to keeping all those parts in sync, even when people join and leave the team.
In this guide, you’ll learn the outcomes of well-documented processes and get a 10-step process to do it quickly, efficiently, and consistently. It’s a process document for documenting your processes.
What is process documentation?
Process documentation is the action of listing each step, participant, and item required to complete a task. You’ll most often document the workflow for repetitive tasks so anyone can follow “the recipe” and achieve the same outcome.
There are several applications for process documentation and various components you can include in them.
When to document processes
Almost any action that requires more than one step and that could be completed by more than one person can benefit from a documented process. If it’s a standard operating procedure in your business, it’s a candidate.
New vs. current processes
The best time to document a process is while you’re deploying it—even if it takes longer to launch. You’ll avoid the inevitable inefficiencies that creep into your new process when people share instructions from memory or recreate their own methods. And you won’t have to retrain everyone down the road.
Documenting existing processes will help you streamline them, too. Especially when you notice:
A loss of productivity or profitability
Increased employee discord
Accurate data is hard to find
Erratic quality
Just about any time a core success indicator dips, the process improvement that comes from documenting it is worth the effort.
Simple vs. large processes
A documented procedure will benefit even a task with just a few steps. A laminated card on the side of a metal press makes it possible to swap out operators without individualized onboarding.
But when projects get really complex, documentation becomes critical to success. Imagine managing the sales, construction, and installation of large solar panels deployed worldwide. There are many local subcontractors involved in every project. Without clear business process documentation, there’s little chance that each new subcontractor would repeat the output of the last.
Components of a process document
A brownie recipe may have a couple of pictures, an ingredient list, and a set of written instructions. Highly complex procedures will include a much broader range of components and media.
Checklists and step-by-step instructions
Step-by-step instructions are the foundation of many process documents. They’re universal methods of sharing a set of instructions so that most people will follow them easily.
Like this example template from Venngage, checklists are a good way to distill instructions into their most basic components.
Source: Venngage
While a list of process steps like this is typical, they’re just one way to convey information in a process document.
Flow chart templates and process maps
Flow charts and process maps are visual representations of a process flow. Here, Lucidchart, a Quickbase partner, shows how flow charts make a complex process with several decision points easy to understand. A text-only version would be a nightmare to follow.
Source: Lucidchart
There are several ways to visualize a process flow. Swimlanes are popular because they also show integrations with other processes.
Images, screenshots, and videos
If you’ve ever tried to use a new application following only written instructions, you know that a picture is worth a thousand words. Documentation with images and videos makes tutorials easier to follow.
Look how Techsmith uses a screenshot with a few arrows and a single text bubble to explain a task in their product quickly.
Source: Techsmith
Images, video instructions, and interactive tutorials can also break down language and other communication barriers, making the process document more accessible to more people.
Responsibility trackers
A complete business process document clearly explains who’s responsible for each action. There are several ways to express this. One popular method is the RACI matrix like this one from CIO.
Source: CIO
The matrix shows each step and shows every role involved. It lists who’s responsible, who’s accountable, and who needs to be consulted or informed.
Benefits of process documentation
Documenting different processes, especially complex ones, takes time and resources. It sometimes seems easier to do the thing instead of taking the time to record how it’s done. But the upfront investment pays off exponentially in several ways. And it’s an essential part of successful project management.
Accelerates training
A succinct multimedia process document is a reusable asset that can train hundreds of new hires with a single time investment. It’s also an asset they can refer to repeatedly, leaving little room for interpretation via memory loss.
Breaks knowledge silos
As organizations and projects scale, individual roles—and the knowledge that goes with them—become more siloed. An accounting team of one evolves into a dozen people handling payments, accounts receivable, and payroll separately.
Process documentation is a library people can access to learn how things are done outside their job function. That makes it easier for everyone to understand how their work contributes to the big picture.
Creates accountability
It might be easy to note that productivity has slipped. What’s harder is figuring out why. A documented process makes it much easier to pressure test different steps in a procedure to see where the bottlenecks and breakdowns happen. And when people know how things should be done, they have a better chance of doing them successfully and safely in the first place.
Future proofs processes
Massively complex projects rely on interoperability—otherwise, the absence of one person could shut down the entire operation. Documentation makes it easier to create redundancies in crucial roles. Plus, it preserves institutional knowledge should a person or team need to be replaced, or a new project require the same process.
Improves stakeholder experience
Surprises are fun at birthday parties, but few stakeholders in a large project are happy when things don’t go as planned. Recorded processes give stakeholders—from workers in the field to investors—predictable rules, communication methods, and outcomes.
10 Steps to process documentation
The complexity and composition of your documentation will depend on the scope of your process. But there are a few minimum qualifications. At the very least, it should be:
Exhaustive, so the least experienced user can complete the task
Accessible, so anyone that needs it can find and understand it
Cross-functional, so it references other functions that intersect with it
These ten steps form a repeatable procedure for you to document any size of task or process.
1. Define the process scope
The scope of the process document describes which process(es) it will cover, the goals of documenting it, and how those goals help the organization.
For example, you can standardize how every team on a large project accesses and reports financials from the cost of goods to adjusted budgets. The scope of the document would clearly explain which processes—like calculating labor costs or reporting budget excess—are to be covered.
The scope also explains how standardizing these practices give everyone real-time visibility to more reliable data.
2. Set process boundaries
Step two is about identifying the process’s starting point and stopping point you want to detail. It’ll include the triggers that kick a process in motion and indicators that it’s complete.
Say there’s a monthly financial reporting cadence for your project. The trigger to start the new reporting process is a date. The end of the process is when all spaces in a spreadsheet are complete.
3. List process inputs
Inputs are the resources an operator needs to complete each process step.
This step is unexpectedly important. For our financial reporting example, imagine if some people used excel, some used financial modeling software, and others tried sending details via email. Working with the same tools makes congruency and cooperation possible.
4. List process outputs
Outputs are measurable, end-of-process goals. They’re like the image of the perfectly baked brownies in your recipe, the ideal goal everyone should strive for.
In our case, it’s a completed monthly financial report with data that’s easily transportable between everyone on the project.
5. Identify the steps
This is the heart of your process doc. List each step an operator needs to complete the project from the initial trigger to the expected output. Now is the time to bring in voices—the doers, planners, and managers—from across the project to brainstorm.
Our steps will include accessing the financial app, calculating various inputs, and notifying a central team when it’s complete.
6. Identify roles
Call out who is responsible for and involved in each step. Consider listing backups for each position.
For example, whose job is it to gather shipping costs? Who will supply revenue details?
7. Create a visual
Some processes are simple enough for a text-only procedure description. Most will require visuals to make the process transparent.
We may add screenshots of the app if there’s potential ambiguity in how to use it. Or we could create a flow chart showing where each piece of information comes from.
8. Identify risks and unknowns
Where is this process likely to break? When you’ve identified those weak spots, you can monitor them so a failure doesn’t cascade into a much larger problem. In general, it’s also a good idea to call out steps that need measurement.
If getting a cost breakdown from subcontractors is a suspected bottleneck, we highlight it in our process document. Then we spot test how long it takes, or the quality of the data, to see if a process revision is in order.
9. Review the process
Here’s another opportunity to get feedback from a variety of roles. Present the draft to a cross-functional group of people who will either use the document or be affected by its outcome. Ask them to point to gaps, incorrect assumptions, and impossible tasks.
Make sure to include people outside your organization if it’s a multi-company project.
Our doc would go to senior controllers, a selection of team leaders, and frontline financial workers.
10. Test the process
Finally, it’s time to simulate the process in a low-stakes environment. Ideally, you’ll want to have someone who wasn’t involved in writing the document do the testing so there’s no inherent bias. Have them grade each step for both clarity and efficiency.
To test our reporting processes, we’d ask a few team leads, including subcontractors outside of our organization, to report monthly financials by following our document. Then we’d ask a controller to port their data into a big-picture report. Can they do it without much data manipulation? Does the data tell the absolute truth? If not, tweak it until it’s right.
Document, review, and iterate business processes
Recipes are rarely ever perfect. Trial and error, plus new knowledge and tools, lead to lower costs, shorter production times, and tastier brownies.
Your processes are dynamic, too. So your documentation has to be created with flexibility in mind. That means an active schedule of business process management. When do operators diverge from SOP? What new technology can make the process more efficient and safe for employees?
Answer these questions at a regular cadence, and your process documentation will continue to support your business instead of being a rigid set of rules that slows everyone down.
