Why Documenting Processes and Procedures Help Steer Your Team

By Susan Beauchamp

Let’s face it, the only constant in life is change. If you find a new best-in-class way of doing something, the natural response is to test your new way, standardize its use and finally communicate it to all impacted parties. But your new process is very likely to change as soon as you document it! For this reason, people often say, “It’s not worth the effort to put it in writing. Let’s just hire the right people who will constantly apply or upgrade our new best practice”.

But how likely is this to be sustainable? Nearly impossible. Therefore, despite the effort and risk of change, we must document our processes and procedures to ensure consistency of results over the long run. Moreover, we need to describe the way we will upgrade every process so that everyone understands the rules and can incorporate change as it occurs. When this does NOT happen, you will often hear:

“Only half the herd gets the word.”

To execute a successful improvement effort, you must have a method to document, update and train your workforce in its use. This also helps to keep your working processes standard, reliable and predictable. Otherwise, your customers will experience inconsistent results, and your people will feel frustrated at having to ‘figure things out on their own’ without proper support and training. Here are the key steps to developing your method and format to document processes and procedures.

#1: Develop a method (including format) and place to store documents.

This should describe the ways to make any updates. It’s important to formalize the way your entire company, all functions and departments, collectively agree to document processes. Without this, each department will develop their own unique way, leading to siloed behavior where no one understands what’s happening elsewhere.

There are many choices you could consider, and all have pros and cons. What’s important is that you decide what’s best for your organization, as a cross-functional group. Do your research to find out what’s best for your organization. Options could be as simple as a word format on an accessible drive or as advanced as using a cloud-based tool designed for documentation such as Atlassian’s Confluence or Jira. Ideally, a senior leader in your company will support a cross-functional team to do the research, make recommendations, invest as may be necessary and communicate the way your organization will document and store process documentation.

Sometimes leadership teams will say, “Our team prefers to document this way. We are not really concerned how the other organizations document”. Worse yet, they might think, “We trust our folks who already know the process, so we’ll just tell them when something changes”. The flaw in this thinking is that it ignores the very real possibilities that:

one group needs to know the methods of another because they are either a customer or supplier of information, tasks or work product, or
it is virtually impossible to bring a new person up to speed to flawlessly execute the process without any documentation, or
as things inevitably change over time, everyone in the organization diverges to do something different, causing miscommunication, inconsistency and defects.

#2: Identify the process!

Not every process requires documentation – some are less critical than others if they are not customer-impacting or where divergence is not a problem. As an example, setting up your office desk environment, or doing research using a website with clear instructions might not require another documentation effort.

Once you do determine your process of focus, make sure you understand when the process starts and stops, from the perspective of the document. Then name the process or procedure using an action format of verb/noun such as:

“Write a request for quotation (RFQ) for capital supplies”, or
“Enter an order into the Order Management System”, or
“Perform the end of shift changeover”.

#3: Determine the experts, scope and the approvers.

The best process documentation starts with a team who knows how to do the process and can approve its use. The team will complete the documentation. Consider the supervisor or leader in charge of the organization’s output as well as customer and supplying organizations who are required to ensure the process flows smoothly.
As an example, if your process focuses on generating monthly financial reporting, you should consider including those who supply this information as well as those who use the reporting as part of your team. Their input will likely strengthen the recommended process as well as the documented result.
The process approver/author is a very important owner of the final documented result; it’s best to designate these people from the start.
Scope is a critical element that people assume is known but often is not. Usually, documentation refers to a particular subset of what the organization does – either a certain set of process steps, or for a specific customer or product group(s). Designate this before you start.

#4: Document the process.

Try writing it in the form of a process map, preferably a swim lane version. The swim lane version of a process map includes process steps, responsibilities and ownership. It shows handoffs from person to person and organization to organization. In this form of a process map, the shapes are process steps and decision points. The horizontal rows (swim lanes) demonstrate a person,

function or organization that has ownership of those particular steps. Arrows are used to connect process steps and show how flow occurs from the beginning to the end of the process. Responsibilities are shown by designating the swim lane – on the left – as belonging to a unique group. You can see visually how the work or product moves from one organization to another and then back again as it finishes.

Usually documenting the process in the form of a process map leads to multiple discussions and changes as people find they are doing things differently. It’s easy to move a shape around in a process map on paper; so, take the time to document it well and ensure everyone agrees before moving to the next step. For more information on how to create a process map, see this OpExecs Academy online course – Discover The Fundamentals of Process Mapping | OpExecs Academy

#5: Convert the process map into a procedure with key elements.

Once the process flows and responsibilities are agreed, document it in the format of a written word or online html page. Include these elements:

High-level summary of the process’ objectives, responsibilities of key people involved and steps.
Scope: what’s included and excluded in this documentation?
Process Steps: number these 1 – xx and include screenshots or other examples which could be helpful to a participant. Ensure you have enough detail that new people can understand the flow. Here you want to strike a balance between describing everything in too much detail and providing the right information for someone to independently perform their role. Be clear as to who is responsible for executing the step. Keep in mind that a picture tells 1000 words; visuals are extremely useful here.
Systems Used: Document this so that participants understand the systems they must access to perform the process.
Troubleshooting – what are some typical ways this process could fail and what should users do if they observe these failures?
Author and approver – the author is the lead documenter. The approver ensures it’s ready to launch to the entire organization. They could be the same person.

Version control/latest revision date – If you are using an online tool such as Atlassian’s Confluence or Microsoft Teams, you might not need this as these tools keep track of all versions. If you’re using a Word document, you will want to designate the version and latest date of update. It’s a good idea to create a footer stating that any printed paper procedure is for reference purposes only and might not be the most recent (and valid) version.

#6: Test the process with new and experienced people.

It’s not enough to simply document the new process. To refine it, test it out with real people: both new and experienced team members. Chances are high that they can improve it. Only after this input should you launch the new documented procedure.

#7: Launch formal training process.

Make sure to include all stakeholders, even if they believe they know the process. You will find everyone benefits from having a formalized session to share knowledge and input. This step takes time and often we want to skip this. We figure if we tell people where it is or send them an email, we’ve done our job. Be assured, you do not want to overlook this step if you truly want the process to be used. It’s also a good idea to document who was trained and when so that you can refer to this later when changes occur or if you see a lack of adherence.

#8: Make sure everyone knows how to make updates and responsibilities.

As mentioned up front, things are going to evolve. When change happens, ensure the original author – or another designated person – has the opportunity to reflect the change in a new version of the document.

In summary, documenting a key process can sometimes be considered boring and tedious. But with dedication, discipline and the right skillset, it will make a huge difference to your customers, your workforce and your bottom-line results. Ensure your project efforts show continued success and results by including a documented solution and training mechanism so that the entire herd gets the word clearly, consistently, and easily.