Process vs Procedure: What is the Difference?Terry Giles
Process vs procedure: what is the difference? This is a question that can keep quality and improvement professionals arguing for hours; and that's because, although a lot of us think we know what a procedure or a process is, as we start to discuss our definitions we often find that someone comes up with something that doesn't quite fit with them.
So what really is the difference between a process and a procedure?
Process and Procedure as defined by the International Organisation for Standardisation (ISO)
In the 2005 edition of ISO 9000, the difference between process and procedure was defined as:
• A process is a set of interrelated or interacting activities which transforms inputs into outputs
• A procedure is specified way to carry out an activity or a process
This set of definitions helped me get an understanding that:
• A process is about what we do
• A procedure is about how we do something
This is all well and good (and for those of you who just came for an easy definition - there it is), but as we start diving into the ‘whats’ and ‘hows’, things can start to get a bit confused - with ‘whats’ sometimes looking like ‘hows' and everything starting to sound like a Dr. Seuss book.
This is why the simple definition above is not good enough and why we need to go deeper for the answer.
My Definition of Process vs Procedure
My take on this has evolved from ISO's definitions above, to understanding a process as being something that has inputs, outputs and activities and can be represented as a diagram - very much in line with the Triaster noun-verb methodology. If you put a sequence of inputs and activities together to describe how to achieve an objective (an output) you have created a process map.
The procedure then becomes a description of how the activity is carried out; generally in text form.
The real difference between process and procedure can be summed up therefore by where you would document with a flow chart and where a written description would work better. If it can be described in a flow chart, it is most likely a process, but where a written description would work best to explain how the activities are carried out, these tend to be procedures.
This is probably open to all sorts of debate, but it works for me.
To read Triaster’s Paul Elson-Vining’s take on the subject (and also policies) have a look at: Processes, Policies and Procedures: What's the difference?
Why the Debate?
So why are we quality and improvement professionals so keen to debate the definition of a processes and procedures? Well, although its perhaps not immediately obvious, there is actually a very practical reason for this. We spend a great deal of our time capturing and improving processes to support best practice working throughout our organisations. That best practice working may adhere to specific safety requirements or be quality certified, or both or neither, but it is certainly the way that it has been agreed everyone in our organisation should work. So... we do our utmost to produce business management documentation that is clear and consistent and the most helpful in getting everyone to follow the process.
Getting Everyone to Follow the Process
Getting everyone to follow the process is hard! Hence all the concern about making the business management documentation as useful and intuitive as possible. However there is also a software solution: ATC Platform. With the ATC Platform processes are set as lifecycles and everyone has to work to them. In a large organisation this works alongside your process maps and procedures, ensuring that all your employees work to them. Smaller organisations however can generally capture their processes directly into lifecycles in the ATC Platform.
This is an updated and refreshed edition of an article originally written in 2017.
Written by Terry Giles
Terry Giles is a consultant for TerryAG Consultancy. He has a great deal of experience in developing Business Management Systems based around a variety of models including ISO 9001, TL 9000, ISO 14001, EFQM, Baldrige, CMMi, ITIL, RiskIT and CobiT 4.1 & 5.