MENU Best Practices in Business Process Documentation
Six Actions to Assure Powerful Business Results
Whether your focus is writing standard operating procedures (SOPs) or drawing process maps, creating business process documentation may seem like an easy –even boring– activity. However, too many organizations find the initiative to be far more time-consuming than they imagined. Worse, the work products may end up on the shelf, rarely to be used as intended.
Leveraging our more than 30 years of experience helping companies achieve operational excellence by documenting, refining and standardizing business processes, Orion’s team has identified six critical actions that will ensure your SOPs fulfill the immediate business objective and become living documents that deliver value to your team members year after year.
Proven, Impactful Best Practices
#1 Make Sure Your Process Documentation Format Is Driven by Business Goals
#2 Understand & Engage Stakeholders from the Very Start
#3 Prepare to Hit the Ground Running
#4 Conduct Workshops, Not Interviews
#5 Validate and Socialize before You Finalize
#6 Establish a System to Govern, Update, and Communicate Best Practices
1) Make Sure Your Process Documentation Format Is Driven by Business Goals.
When tasked with creating process documentation, the simplest path is to either purchase a software product or download a template that can be used with Microsoft Office products (Word, PowerPoint, Visio). That is certainly a convenient way to get started but it can also be a trap, leading you down a path toward a “successful” documentation initiative that delivers little or no business value.
There are three key questions to answer when considering what your process documentation should look like:
- What business goal or goals are we trying to achieve? (Function)
- What is the right level of detail to meet the above goal? (Form)
- What will be most “usable” by our target audience? (Fit)
Of these, the first is most important… and often the most overlooked. It’s easy to say, “I want a process map and SOPs,” and get started. But the work products are not an end in themselves. They are a medium to achieve consistent excellence and/or to satisfy regulators and/or to onboard employees, etc., etc. The Function should drive the Form.
For instance, if you are creating documentation to satisfy regulatory requirements, you probably want documentation components that focus on workflow and perhaps control points but have a lower level of detail. If the oversight agency requires extensive documentation for every process change, then unnecessary detail means you will experience excessive maintenance time/costs down the line.
On the other hand, if your goal is to eliminate exceptions/variations so that you have a clear work standard (and can train new employees to that standard) then you will want more detailed step-by-step instructions.
Or perhaps you are creating process documentation ahead of an ERP implementation. If so, your business goals probably include simplifying the processes before they become automated and creating documentation that will be the foundation for your business requirements.
These are three very different use cases for business process documentation. They require different outputs.
There are many elements your organization may incorporate into its process documentation. Orion’s sample packet contains 10 items:
This is not the “ideal” table of contents. Rather it is a menu of possibilities that contains more elements than any organization needs… and this sample does not even include IT-specific work products (e.g. use case diagrams) that some projects require.
Every process documentation packet should start with a clear statement of Purpose and Scope. It should end with your Documentation Governance standards. What goes in between? That’s what you have to decide based on your business goals. So, after the project is done:
- Who is going to use this process documentation?
- What do they need to accomplish for our business?
- What must we provide for them to enable item #2?
After you have considered those questions, select elements from the following list:
• System Map or SIPOC – Your business processes do not exist in a vacuum. Each is part of your larger business eco-system and often part of a cross-functional process. The SIPOC tool is a simple illustration of the Suppliers and Inputs that flow into the Process as well as the Outputs and downstream Customers, who may include internal customers (e.g. other departments). The System Map is an enhanced SIPOC that provides a 10,000-foot view of the value chain. It may include supplier and customer requirements. Include one of these tools in your packet if your employees would benefit from understanding the big picture.
• RACI – There are a few different ways to specify roles and responsibilities. You can use a simple table that includes each title and a list of responsibilities within this process. The RACI diagram specifies who is Responsible, Accountable, who can be Consulted, and who should be Informed during process execution. Use this tool if there has been a history of overlapping responsibilities or confusion over who makes decisions during process execution.
• Cross-Functional Process Map – This is the classic process map or “Swim Lane” flowchart of how work gets done. Almost every client Orion has worked with included this visual representation of work in their documentation packets.
Why? Because the cross-functional process map –more than any other tool– gives you an immediate sense for how work gets done from start to finish. In the diagram below, the green oval is the start point. In a real-world example, it would specify the trigger. The red oval is the endpoint. This could be a final action or a handoff to the next process.
In between, each row or swim lane is dedicated to a particular player, typically a job title or department name. Each rectangle describes an action with a simple verb-noun description. (The work details can be found in the Step-by-Step procedures.) The arrows trace the workflow. Simple. Clear. Easy to understand.
• Step-by-Step Procedures – This process narrative (or SOP) explains how work should be performed with clear how-to instructions, notes, exceptions and other information your practitioners need to get the job done. In advanced applications, this section can include videos and links to relevant forms. Combined with the cross-functional process map above, Step-by-Step Procedures are the heart of every business process documentation packet.
• Issues and Ideas – When exploring how a process is executed with the process performers, it is inevitable that you will unearth pain points and potential solutions. It is common to generate a dozen or more issues and ideas during each workshop. Even though this content will not be in the ongoing process documentation packet, it is a valuable by-product that many organizations now require during a documentation initiative.
• Performance Metrics – The Purpose and Scope section may include a performance target. (e.g. Invoices paid within 30 days.) Process documentation workshops will reveal additional key performance indicators (KPIs), including input metrics and work execution metrics. (Input metrics answer the question, “What should I be getting from my internal or external suppliers in order to do my job well?”)
• Process Risk Assessment – In some critical manufacturing processes (e.g. building a rocket that will carry humans into space), it is worthwhile to evaluate the likelihood of this process failing and assess the potential ramifications if it does fail.
• Control Points – Similar to the Process Risk assessment, a Control Point identifies a potential failure spot and specifies mitigations. This is most common in financial processes. A simple example would be if we are about to disperse more than $X,000 then you must get two signatures. Orion likes to indicate these control points on the Process Map with red triangles. A separate table describes the mitigation actions for each control point (triangle).
Again, every documentation packet should begin with a Purpose and Scope section that provides clarity on the process trigger, end point, and intended business outcome. Process Governance and Approvals should be on the final page. (More on that in Best Practice #6.)
After you select the other elements that will satisfy your organization’s business goal(s), make sure you use language, visuals, and formats that are accessible and relevant to intended users. Again, we must create business process documentation that fulfills the immediate business objective and delivers value to your team members year after year.
2) Understand & Engage Stakeholders from the Very Start.
A process documentation project may seem like one that does not require change management activities, especially if we are “just capturing the as-is.” That can be a fatal mistake. To achieve high-quality outputs and to make sure the work products are truly put to use, it is imperative to identify your stakeholders, analyze their needs, and take actions to create buy-in up and down the organization chart.
Remember, your process expertise and operational wisdom do not come from consultants (internal or external). They come from your process performers, managers, and even your customers. Early on, we must identify these various stakeholders and make sure everyone understands the why, the what, and the how. That ensures we have the right people/knowledge in the room and that those people are committed to process documentation success.
Ongoing engagement with the process participants results in both “ownership” of the SOPs and support for any process changes and enhancements. Securing their “skin in the game” greatly increases the odds of success for the implementation of any operational improvements.
A successful process documentation initiative takes time and unfettered participation. People who understand the work must show up and openly share their experiences. Managers and supervisors must allow their employees to invest the necessary time. They must also give them the freedom/safety to provide critical feedback and recommend changes. Senior managers must be ready to insist on standardization, new performance metrics, and ongoing governance of the process documentation so that the initiative delivers ongoing value. These outcomes are a result of thorough stakeholder analysis and a comprehensive communication plan.
Key considerations during stakeholder analysis include:
1. In whose brain does critical knowledge reside? The answer is not always obvious. Institutional knowledge is often in the head of process practitioners with the most experience. Sometimes it is a member of the support staff who has the best sense for when the process works well versus when there are hiccups. In other words, it resides not with the person who has the title, but with the person who cleans up problems when they occur. Many times, critical knowledge comes from an internal supplier or an internal customer. A stakeholder identification table will help you work through this question.
2. What do we need from our managers? Obviously, for the initiative to be successful, we need their staff. Sometimes we need the manager in the room because he or she has critical knowledge. Sometimes we need the manager to stay out of the room so that their workers can speak freely. Finally, we need the manager’s commitment to supporting and implementing any improvements that are generated. It’s not just about getting a good work product; it’s about making sure it’s put to good use.
3. How do we get buy-in from everyone in the organization? The WIIFM. (What’s In It For Me?) This includes senior management. They might not participate in the project, but they have to sign off on the investment. Be clear on the business return. Will crisp process documentation mean better performance and fewer headaches for managers? Will it make life easier for people on the front line? The answer to these two questions is almost always “Yes,” but don’t assume that it is understood. Communicate the benefits to drive buy-in and eliminate any fear.
On the subject of fear, don’t underestimate how lack of upfront communication can lead to people questioning the goals of your process documentation project. In a funny yet on-the-mark cartoon from more than 30 years ago, an engineer is asked to capture process documentation from his colleagues. They are worried they will lose their jobs if they tell him how the process actually works. In the final panel, the engineer confirms, “You say you use flying monkeys to deliver the finished design?”
I have seen the same in the real world. Once, during a three-month check-in with a CEO, I shared with him that the project was going well but a few people were saying they thought the real goal was downsizing. The CEO was dumbfounded. “I have made it clear from the beginning that this is about improving life for everyone. No one is going to lose a job. How many times do I have to say that?” My response: At least one more time. It’s better to over-communicate than to under-communicate.
Rigorous upfront engagement ensures buy-in and provides necessary context so that the process documentation work products serve both its real users and critical business objectives.
Drawing boxes and arrows on a process map is the easy part. Eliciting the “process magic” from team members is the source of true value.
3) Prepare to Hit the Ground Running.
A few years ago, Ralph Smith was at a client site for a four-hour process documentation and improvement work session. Ninety minutes in, they were still on Step 1. Why? Because the supplier to this process could be any of a dozen (or more) different customer types, some of whom could skip to Step 2. Were those 90 minutes of discussion worthwhile? Absolutely. But it would’ve been more productive –and less frustrating– for everyone if this complication had been identified and cleared up in advance.
Enter the Orion process documentation questionnaire.
At the onset of every process documentation project, Orion creates a customized questionnaire. Depending upon the client’s business goals, these questionnaires may be as brief as 5 questions or as long as 15 questions. The questionnaire is shared with each subject matter expert who will participate in a documentation workshop. To make these workshops as productive as possible, it is imperative to create upfront clarity on three critical characteristics:
- The goal of the process. What business outcome are we trying to achieve?
- The start and end points. What triggers process execution? When are we done?
- High-level workflow. What are the four, five or six macro steps?
With this framework in place, the process documentation workshop can move quickly into knowledge collection and build positive momentum. It’s similar to the First Law of Motion. If a workshop stalls at the onset, it will likely stay bogged down. If you are able to hit the ground running, it will be productive throughout. Doing the upfront work ensures a productive business process documentation workshop.
4) Conduct Workshops, Not Interviews.
The classic consultant’s approach to process documentation was to interview the manager and all the process participants separately and then have the consultant compile the results into a new “future state” process. This approach should be avoided unless absolutely necessary.
If you have a process that is executed by only one person then the process documentation session, by definition, must be an interview. However, if there is more than one stakeholder then it is always best to get all or most of them in the same room and conduct a process documentation workshop.
A workshop lets colleagues hear from each other. It unearths variations, exceptions and best practices that were never shared. We love it when a process performer tells a teammate, “You do it that way? Wow, I never thought of that.” Having your brainpower in the room will help you not only document the “as is” process but the “one true process” going forward.
It also helps with buy-in. The output is “our” new standard. It’s not what the consultant (internal or external) decided. It’s not what your colleague preferred. It is the outcome of our shared experiences and mutual contributions.
One you have the right people in the room, you can conduct the business process documentation workshop.
If you were effective with Best Practice #3 (Prepare to Hit the Ground Running), then the macro steps of the process in question (the blue boxes in figure at right) 
will be agreed upon before your workshop begins. The high level “what” is set. You can then drill down to determine the “who” and “how.” The top-down flowchart is an excellent, easy-to-understand tool for capturing this process knowledge.
Your workshop facilitator must, of course, have solid BPM skills. More importantly, she or he must be skilled at asking questions that drive positive participation and draw out the “special sauce” that makes your processes unique. That could include subtle differences in customer needs, workarounds that were never shared, key interdepartmental relationships, “life hacks” that simply operations, etc. The goal is not just to document essential activities; it is to standardize your best practices.
Orion conducts workshops either virtually or in person. For virtual workshops via Zoom or MS Teams, it is best to limit the length to two hours. For an in-person workshop try to get a three- or four-hour commitment from participants – even if you end up working on more than one process. Once you get on a roll in a workshop setting, it is easy to continue for a half-day. If your timeline for the project is tight, you may choose to schedule longer sessions. However, Orion always stresses the importance of producing a great product with minimum impact on day-to-day operations. If these workshops become a burden, quality will suffer as will employee buy-in.
How much workshop time is required to document the process? Depending upon how many elements you selected during Best Practice #1 (Make Sure Your Process Documentation Format Is Driven by Business Goals), a medium complexity process may require 3 to 6 hours from your team members, including workshop participation and off-line work product review. Orion has worked on very simple processes that only required 1-2 hours to generate simple outputs. Other clients with more complex processes and comprehensive documentation packets needed longer workshops.
In general, avoid building the finished products during the workshops. Focus primarily on capturing knowledge and wisdom. You can do the editing and chart creation off-line. The workshop approach will enable you to document and standardize new best practices that interviews alone cannot deliver.
5) Validate and Socialize before You Finalize.
It is uncommon to document how a process truly works with 100% accuracy on the first pass. Process Validation ensures that what we’ve documented is what is actually happening. This activity not only guarantees operational integrity but also ensures the documentation will be genuinely useful and adopted by its audience.
Validation is an opportunity to broaden participation and ownership by those who perform the work, especially if not all process performers and stakeholders participated in the workshops. Remember, people don’t resist change; they resist being changed.
For some physical processes, validation may occur via walk-throughs or direct observation to compare the draft process documentation to real-world activities. In the 21st Century,
most process validation occurs by sharing work products electronically. However, another “old-fashioned way” is a great illustration of what validation and socialization looks like. This picture shows a very large process that was documented using Post-it notes and swim lanes on a conference room wall. Stakeholders were given a couple of days to come into the conference room at their convenience, review the process map, and use Post-it notes to add comments.
These comments could include questions, recommended changes, notations about process exceptions, “watch-outs,” or refinements. These validation activities both perfected the work product and made sure that every process performer had a stake in the new process standard.
Once you have achieved accuracy and buy-in, it is time to implement your “one true process.”
6) Establish a System to Govern, Update, and Communicate Best Practices.
For decades, Bob Boehringer and I have spoken about the need to create “living documents.” Even the best process documentation can become outdated after six or 12 months. How do we make sure the documentation stays current as existing processes evolve and new processes are created? How do we communicate process changes and share improvements? The answers to these questions make the difference between a process documentation initiative that delivers short-term success and one that makes continuous process improvement part of your culture.
The bottom of every process documentation packet that Orion creates for our clients includes a Governance section:
This section addresses three key questions:
- Who owns the process?
- Who is responsible for keeping the documentation up-to-date?
- How often should the process documentation be revalidated?
Some organizations have a formal role of Process Owner or Process Manager. Whether or not your company has those titles, one person should be the process expert with the authority to approve or reject changes to the workflow, business rules and tools. That person has ultimate accountability for maintaining the “one true process.”
The Process Documentation Steward is the person who has hands-on responsibility for updating and communicating the SOPs and maps. (In some organizations, this may be the same person who was designated as Process Owner.) The Steward must have the requisite technical skills in Word or Visio or Promapp, etc. to maintain high quality work products.
Communicating any changes is a critical responsibility for the Steward. More on that below.
There is no best practice timeframe for re-validating your process documentation. That should be determined on a process-by-process basis. Orion defaults to a 6-month requirement. Some processes may be more dynamic – especially if they are new or utilize new technologies. Other processes may be extremely stable and only change every few years. If you are unsure about a particular process, settle on a shorter timeframe for starters.
It is extremely important to set the timeframe and to adhere to it. If this does not become baked into your routine, then process documentation will become outdated. Innovations will not be standardized. New employees will learn from outdated materials. Variations in process execution will pop up as new employees navigate the workflow without proper guidance. Which brings us back to communication…
Your one true process standard is not chiseled in stone. Changes will occur. How do you communicate those changes?
• In small organizations, you can email all the process performers and even post updated process maps in a common area.
• If the change to workflow is significant, consider having a meeting with your team to review the changes in addition to providing the new process documentation. If the workflow changes are very significant or involve new technology, hands-on training may be advisable.
• For larger organizations, SharePoint or a similar web-based collaboration / document management platform may be the best medium.
For most small and mid-sized businesses, it does not make sense to invest in a standalone process documentation platform such as IBM’s BlueworksLive, Signavio, Interfacing, Nintex’s Process Manager [nee Promapp], Touchstone, or ProcessPro. However, if you have Promapp, for example, it will push notifications out to every stakeholder when a process changes. That system also allows stakeholders to ask questions and recommend changes to the Process Owner. That’s a nifty way to foster continuous improvement.
In process management, communication is very much a two-way street. Standards come “down.” Improvement ideas and process wisdom flow “up” from the frontline. If you are looking for a dedicated process documentation platform, make sure that two-way communication is one of your requirements.
Final thoughts regarding improvement: Your business process documentation initiative should deliver operational ROI. Utilize surveys and metrics so that you can quantify the benefits. It is nice to be able to say, “That went great, and we really like the quality of our maps and SOPs.” It is much better if you can tell people that your team is saving X hours per week due to the process clarity. Your department is saving $X per month due to less rework and fewer unnecessary exceptions. Employee satisfaction is up X% because work is simplified and less frustrating.
Conclusion
Process Documentation: An underappreciated business asset.
We founded Orion Development Group in 1993. It is impossible to estimate how many business processes we’ve mapped; how many standard operating procedures we’ve written; how many RACI diagrams or responsibility charts we’ve created. Still, if at any time during the first 30 years of our existence someone asked me at a cocktail party, “Paul, what do you do?” There is little chance I would’ve answered, “We document processes!” No, I would talk about how Orion reorganized a 42,000-person telephone company around cross-functional processes or how Toyota asked us to evaluate their process improvement program or how we reduced the major process count of a state pension system by over 40% or improved RONA in a packaging company by over 60%. Reengineering, innovation, redesign, and improvement are exciting words. Documentation? Not so much.
However, since the pandemic shook up most organizations’ understanding of how work gets done and how our customers interact with us, I gained a much greater appreciation of process documentation. Rather than just being a by-product of an improvement initiative, process documentation is a foundational business component that ensures consistency, ongoing improvement, and a culture of knowledge sharing.
Orion is pleased to share these Big 6 Best Practices. We hope you will put them to good use in your organization.
This document reflects the experience of several Orion team members and colleagues, including Bob Boehringer. Joe Brancaccio, Mandy Dietz, Daniella Fajardo, Kelly Feister, Paul King, Mike Parnitzke, Ralph Smith, and Dianna Wilusz. We are grateful to all the clients and professional development students who added to Orion’s understanding of the vital roles process mapping and process documentation play in successful business process management.
Process Documentation Resources
Templates
• Process Documentation packet (MS Word)
• Process Maps (Visio)
Training
• Essentials of Process Mapping webinar
• Process Mapping & Systems Thinking seminar
Articles
• Six Opportunities to Look for During Process Documentation
• IT, Process Management and Change Management
• Using Process Mapping to Redesign the Student Experience
• Process Mapping Words of Wisdom