Understanding the difference between Process, Procedures, and Work Instructions (and why it matters)
by Raquel Rosa, 3/26/2020, 1:27:41 PM
Quite often, there is a general confusion in the difference between the two. We may even find them used interchangeably. Some people may even favor using one term over the other because of the general “pleasantness” in the way it sounds.
My goal in this article is provide an explanation of:
• the differences between these terms • their relationships • how understanding this can benefit your organization
In addition, we will also introduce a term called “Work Instructions”, which is not as regularly mentioned, but it will help us paint a complete picture.
What is a Process?
As a starting point, we can use ISO 9001:2015 (Section 3.4) to give us a definition:
A process is a “set of interrelated or interacting activities that use inputs to deliver an intended result” (the intended result can also be referred to as an “output”)
Think of a process as an overarching entity that sits above everything else. It defines a particular group of activities at a high-level. It is important to note that every process starts with an input (requirements) in order to kick-start a sequence of activities, and finishes with an output.
A typical example is the Incident Management Process, which in the ITIL world is the process responsible for managing the lifecycle of all incidents. The Incident Management Process consists of several activities, ranging from incident logging and categorization, investigation, resolution, incident monitoring, escalation, et cetera. Note that the Incident Management Process requires an input (customer call / email to report the issue) and an output (issue is resolved).
A process does not enter into the details of the activities involved – this is covered by the next level, using Procedures.
What is a Procedure?
Again, we can refer back to ISO 9001:2015:
A procedure is a “specified way to carry out an activity or a process”.
To elaborate on the definition above, a procedure essentially describes How an activity / process is performed, and Why it is performed in that manner.
An ideal procedure documentation would contain the following sections:
• Purpose • Scope • Pre-requisites • Roles • Procedural Steps • Workflow diagram / Cross-functional flowchart if there are more than 1 team involved.
Below is a simplistic example of a Cross-functional flowchart. In general it is a great way of providing a visual representation of a procedure.
As you can see, there is a greater granularity in the description of activities: decision points, relationships between teams, etc. However, while the task and accountability is outlined for each business unit (example: L1 – Investigate Issue), there is still a need for deeper information to understand how an activity is executed. This is where Work Instructions come in.
Last but not least, what is a Work Instruction?
We can enlist the help of the Information Technology Infrastructure Library (ITIL) to explain what are Work Instructions. Note that they are not explicitly mentioned nor made compulsory in ISO.
ITIL defines a work instruction as: “a document containing detailed instructions that specify what steps to follow to carry out an activity. A work instruction contains much more detail than a procedure and is only created if very detailed instructions are needed”.
Basically, a work instruction is where we should expect to find the most in-depth and detailed directions we need to perform a work activity. It involves only one team or business unit.
Think of a work instruction as a cooking recipe; every single tool, ingredient, measurement, and compulsory action is explained. Without this level of detail, the recipe either cannot be cooked, or it would be cooked incorrectly.
It’s like peeling an onion…minus the crying
A useful way of understanding the difference between process, procedures and work instructions (and not getting too caught up with the definitions) is by thinking about it in layers. A process is the highest level, followed by procedures, and finally work instructions. We can visualize their relationships as shown:
Fine, but how does understanding all of this help us?
We all know the obvious advantages of implementing processes and procedures (hint: quality management). But sometimes, poor implementation can happen from the lack of understanding of what each area covers. A poorly written work instruction ultimately becomes subjective to the person(s) whom it is intended for, and therefore less reliable .
By having a clear definition of these terms and its usage, we can:
• promote a common approach to documenting processes, procedures and work instructions • improve the management of such knowledge (easier for teams to find, use, and organize this information)
Scouring the internet to search for answers often leads to more confusion, perhaps even an overwhelming sense of information overload (we have all been there!). Therefore, I hope this article helps to clear doubts about the topic, and perhaps even be a successful launchpad for your team’s best practices in process documentation and knowledge management.
