How to Write Process Documentation

By Mike Raia Posted July 17, 2020

 

Why do we need process documentation?

Before answering this question, it is crucial to understand what we mean by 'Process documentation.'

In the context of this article, Process Documentation is a:

"Single agreed source of truth for understanding the organization's current business processes."

The document can be used as a guide by employees, managers, auditors, clients, and other company stakeholders.

Process documentation is needed to:

  • Provide transparency across the organization of who does what, when, and how.
  • For training purposes:
    • For new hires
    • For when the process changes
    • To drive performance improvements in the process
  • Provide the capability to analyze the current process and develop enhanced processes that reduce lead time and simplify the process by cutting out non-value adding activities.
  • Preserve key business knowledge
    • When employees leave this knowledge is not lost
  • For compliance or conformance to quality assurance standards such as ISO 9001 or in specific industries such as the AS9100 or American military standards.
    • For some of these organizations, this will be a pre-requisite.
  • Provide operational efficiency, consistency, and reduce the potential risk of poor quality and or rework.

As with all documentation, there will be a cost for developing and maintaining them, but this cost will be more than offset by the benefits of using the documentation.

 

What should be included in process documentation?

Business process documentation should be part of a framework, where the organization's policies, processes, and procedures are inter-connected and aligned to achieve business outcomes. Ideally, they should all be in one place and reference each other.

elements of business process documentation

Figure 1: Elements of Business Process documentation.

  • Policy
    • Set of guidelines, rules, strategic goals, and even regulatory rules under which an organization operates.
    • It would typically cover all facets of the organization, from health, safety, and environment to operational financial and procurement policies.
  • Process
    • Is a series of inter-related value-adding tasks that achieve a business outcome
    • Typically, processes are represented in workflow charts.
  • Procedure
    • A detailed set of steps to perform a process task.
    • A procedure can be a quick reference guide, desktop checklist, work instructions, or detailed step by activities to perform a task or action.

A good way to imagine this is when you set off on a journey:

  • Your Policy will be the traffic laws that determine how you behave on the road in terms of speed, traffic lights, stop signs, and other road rules and regulations.
  • Your process will be the map that outlines the route you will follow for getting from the start of your journey to your destination, including any route stops you may take.
  • The procedure would be the detailed steps you would need to take in terms of the roads, streets, tolls, highways that you need to travel through (liken them to the sat-nav instructions you receive).

 

How do I structure my documentation?

Most process documentation takes a top-down approach and breaks all the organization's processes into several essential organizational functions. For ease of responsibility demarcation, they are usually subdivided by departments/units. These functions are then further broken down into a set of processes. Finally, the processes are further divided into procedural tasks and typically reference business systems software, where they are used. This is shown in the diagram below:

Structured breakdown of process documentation

Figure 2: Showing the structured breakdown of process documentation.

The documentation needs to be templated and modular so that each template can be re-used for different processes. The chart below shows how the documents should be structured and included in each document type.

Content details by document type

Figure 3: Content details for each document type.

When structuring process documentation, it is vital to consider its up-keep and maintenance. If it is written like an article or story, then when changes may impact the whole document necessitating complete re-write. When it is structured, templated, and broken down, as shown in figure 3, a change in the procedure may impact only a single page. This would allow for an efficient update process.

 

Developing Documentation Format & Style

Developing a document numbering system

An important consideration in the development of the procedures is to ensure there is an efficient and structured document numbering system that allows for single page replacement of the document. The system also needs to ensure effective version control, so that only the most up-to-date documents are published.

Each organization will need to develop its pre-defined numbering system that allows for ease of use and a style that meets its business requirements. These formats will need to be agreed and established for:

  • Policy documents
  • Process & Sub-process documents
  • Document procedure

Shown below is an example numbering system:

Structured document numbering system

Figure 4: Example of a structured numbering system for process documentation.

It may be that the organization already has some or all the above documents, and what is required is the alignment of those documents under a single numbering system so that they can be inter-related.

Document format

It is difficult to provide a single format for every organization. It will vary based on industry, the type of product/service offered, the size of the organization, and the complexity of the processes.

For illustration purposes shown below are extracts of real-life industry examples (with company names removed for confidentiality) for each of the document types discussed above:

Policy example

Figure 5a: Example of Policy document showing format, style, and content.

Process flow chart overview

Figure 5b: Example of Process Flow showing an end-to-end process flow.

Procedure document format

Figure 5c: Example of Procedure document showing format and content.

Using Process documentation tools

If you are setting off in this journey with no experience of using software tools, then apply the 'KISS' principle. Before you embark on shortlisting and identifying potential software products, be sure that you have addressed:

  • a Format, and Structure of your documentation
  • Who and How you will develop and maintain your documentation?
  • Who will be the user community for the documents you will create?

In developing your documentation, remember that you can use simple word editing and flowcharting software, using MS Office products, for creating the documents, for instance. Many organizations still use this basic but effective method.

The benefit of using automated documentation tools comes when you have many processes. It becomes unwieldy to manage and maintain them or are looking for quality assurance certification where the software can speed up the adoption process.

In searching for software providers for these tools, you will find a vast array of products available for developing process/procedure documentation from simple Visio type tools to sophisticated Business Process Management tools that incorporate documentation as part of their offering. They suit organizations with less than 50 employees to large enterprises with thousands of employees and multi-company organization structures, so a clear focus is required of the type of tool you are seeking.

Most of these tools work independently, but they can also interface with your business systems, so that the documentation is readily available, as you carry out your tasks (i.e., at the point of use).

It is worth considering that the more sophisticated Business Process Automation tools have documentation incorporated into their software. Hence, if you are using a BPA tool, check if this has an option for documentation.

If you are serious about pursuing a suitable software product, then here are a few tips before going into researching, viewing, and shortlisting to select a suitable product:

  • Have a clear purpose for your documentation
  • How and who will be using the documentation
  • Develop a requirements document of your 'must-have' needs
  • Set a budget and be clear of the benefits you will achieve.
  • Apply the Pareto principle of 80% functionality that you need for 20% of the cost. There are always features on software products that look nice, but they are often not required, and if they are the process and the data needed to make them work can be complicated and thus difficult to implement.

 

Maintaining the documentation

Who should write and maintain the documentation?

Writing the documentation is not a task for one individual; it requires input from many parts of the organization. The organization will need a technical writer or someone who can be trained in those skills to take the lead.

The documentation process will require management approval and buy-in and brainstorming sessions to extract the needed information from those who are currently working on the processes.

Figure 6 below shows the critical roles in developing documentation. These may not be full-time roles and may overlap or be merged depending upon the size and type of organization.

Figure 7 below outlines the steps you need to follow to develop, approve, and publish your documentation. This will apply to all your document types.

Key process document roles

Figure 6: The key players in developing process documentation.

 

Outline of a process documentation steps

Figure 7: Outlines the steps in developing process documentation material.

How often should they be updated?

Bear in mind that policy documents may rarely change over the years, but procedures may change monthly or quarterly. Across all document types, changes should be as and when the process changes due to:

  • Improvements in the business process
  • Feedback of errors and anomalies from those using the documents
  • Changes in business direction and strategy particularly for policy changes
  • Feedback from regular process audits of the actual process vs. the documented process
  • When major business software is changed/upgraded.

Document change control

Approvals for developing and changing the document should be simple but effective. It does not need a multi-layer approval process like a delegation of authority; otherwise, the process will become cumbersome, and changes will not be made. An effective approval process requires no more than three roles. The document writer, the process owner, and the custodian.

 

Summary and Conclusion

Writing and maintaining process documentation is a business overhead but necessary to preserve process knowledge and provide documentary evidence of process understanding. If used effectively, they can deliver tremendous benefits, mainly if they are used alongside business process automation tools.

The documentation needs to be fit for purpose, and for smaller organizations, this may be a simple process flowcharts and minimum textual descriptive templates. For those organizations that are seeking external quality assurance accreditation such as ISO9001, the cost of preparing and maintaining the documentation becomes a pre-requisite for doing business.

Process documentation should not be left as a formal reference guide on the bookshelf or in a SharePoint folder, as it will just gather dust and provide no real benefit. It must be considered a working document and used daily by those working with processes and the middle layers of management.

The realizable benefits of these documents will come when they reflect the living breathing pulse of the organization.

Whatever your objectives, if you do not have process documentation, it is never too late to develop it. We hope that this will give you some insights into what process documentation entails.

Mike Raia

Marketing the world's best workflow automation software and drinking way too much coffee. Connect with me on LinkedIn at https://www.linkedin.com/in/michaelraia/

2

Comments

  • Comment by Zarroug on July 25, 2020

    I think Mike's approach to the documentation leave to room for any thing to fall between cracks which is usually the case with some process mapping , when it happen it my remain for long time and people may monkey-do it for along time before somebody come and say umm why do we do it this way . and I thing the most important is the segregation between procedures and Process maps , which many got wrong .

  • Comment by Mike Raia on July 27, 2020

    Zarroug,

    Thanks for your feedback. I agree there is always a chance that an important element will fall through the cracks. It's critical that the process and the documentation be revisited regularly and reviewed with stakeholders to ensure it's performing as expected.

    Mike

Post a comment

 

Download our complete
feature list to learn more about Integrify.

 

Register Now   Learn More

×

Copyright © 2020 Integrify All rights reserved.