In a recent blog post we discussed the role of processes in Agile development. In this post I will tackle one of the most frequent questions I have been asked over the last 15 years in my roles of technical/business communication expert and ISO 9001/QMS consultant. That question is, “what is the difference between processes and procedures?”
There is often confusion about the difference between processes and procedures because they are somewhat similar in that they are both ways of documenting “how we do things”. While in the big scheme of things the differences might be subtle, when it comes to the exact role they play in an organization the difference is important and significant.
Every Organization Should Have Documented Processes
Every business and organization operates through executing processes – doing the steps or activities to achieve a desired result. That involves almost anything the organization does including taking orders, creating accurate financial statements, on-boarding new employees, and assembling a widget. If processes are not documented, then they are very likely poorly controlled – meaning that the activities and results vary widely. When someone calls to place an order, you don’t want the information gathered and the interaction with the customer to depend on whether Becky or George answers the phone and whether they take the call on a Monday or a Friday. You want the information collected and the customer experience to be accurate and consistent.
If you have a documented order-taking process on which all personnel who may take orders are trained and familiar, the business is much more likely to have a higher level of consistency in how orders are taken than if no documented process exists. Plus, often the exercise of documenting the process
provides an opportunity for reflection, gathering information, discussion, and review/feedback as is usually the case when taking the time to write anything down. So in the end the people in charge of the process and those involved with executing the process understand it better. When processes are documented organization-wide a clearer understanding of how various processes interact will emerge.
This process-based approach is the foundation of the ISO standards.
Should Every Organization Have Procedures?
Generally, every organization should have all of its key processes documented, and process documents and procedure documents are both ways of documenting processes. Now we return to our original question of, when should an organization use a process document or a procedure document and what is the difference? Here are the factors to consider when deciding:
Scope:
Process documents can be very broad or very specific in scope. For example, there can b
e an overarching sales process that covers all the aspects of generating sales and processes for all the particular sales related tasks. Procedures are usually much more narrow in scope and focus on the steps to complete a specific, individual task.
Format:
While there are no hard and fast rules on how to document processes and procedures, and every business or organization should do what best meets their needs, generally procedures are more formal business documents while process documents are more informal and should be easy to create (e.g., simple flowcharts with concise steps).
Review and Approval:
Process documents have a lower level of review and approval than procedure documents. Processes should be easier to change and update. The reason for this will be more clear when you read about “adherence”.
Adherence:
Processes are general guidance that tell employees, “This is generally how we want this to be done.” With process documents, there should be an understanding that deviation according the situation is acceptable. Achieving the desired result is what is most important, not blind adherence. Procedures, on the other hand, should always be followed to the letter. That is the role of procedures in an organization; it documents the processes that have to be done the exact same way every time. There are typically three reasons when adherence is important and a procedure is created instead of a process:
- Risk Management: For activities or facets of the organization that provide a high degree of risk, then the process should be carefully documented and followed in the form of a procedure. Examples might be IT backups or cash management.
- Importance to the Organization: Key activities that are critical to organizational success should be fully documented in procedures. Examples might be conducting customer design reviews or submitting proposals.
- Compliance: Sometimes procedures are required by customers (via contracts), government regulatory bodies, or by standards. For example, the FDA requires certain procedures exist for those in the food industry, and ISO 9001 requires a set of procedures to gain certification. If your business must comply with regulations or hopes to gain some kind of certification, then there will probably be required procedures.
So while every organization needs documented processes (even in Agile development), it may or may not need procedures. Usually, however, an organization should have at least a few procedures for critical areas to manage risk, ensure success, and gain compliance. But lots of procedures are not really necessary if processes are clearly defined. To gain ISO 9001 certification an organization only has to have seven procedures, but all of its processes have to be documented.
Process or Procedure?
Unless there is a compelling reason (i.e., risk, importance, compliance) for using a procedure to document a process, avoid over-complication and over-documentation by using the more simple, basic process document.
Don Reed is a Senior Technical Writer and Project Support Specialist with the ADEV program. His background includes engineering and programing, project management, quality and business improvement, and business-technical communication. Don has a B.S. in Electrical Engineering and a M.A. in Communication from Saint Louis University.