When a company starts building a QMS, one of the first instincts is to start writing: a procedure for purchasing, one for production, one for inspection, one for training. A list of procedures feels like a plan.

A procedure describes how work is to be carried out, but it is only one way to communicate or control a process. If you write one before understanding how the work actually flows, who is involved and where problems can arise, you are documenting assumptions rather than the operation. The result is often generic, unnecessarily long and disconnected from the way people work.

The better order is simple: understand the process first, then decide what, if anything, needs to be written down.

A process and a procedure are not the same thing

A process is the work itself: a set of connected activities that turns inputs into outputs, such as an order into a shipped product. It exists whether or not anyone writes it down.

A procedure is one possible way of describing how part of that work should be carried out. It is a tool, not the system.

The mistake is to treat the procedure as the starting point. In practice, many processes run well with very little documentation, and some critical steps need precise instructions. You only know which is which once you understand the process.

What to understand before you write anything

For each major process, establish a few basics:

  • Purpose: what the process must achieve, and for whom.
  • Inputs and outputs: what it starts with and what it delivers to the next step or the customer.
  • People and roles: who performs the work, who checks it and who decides when something is not right.
  • Handoffs: where work or information passes to another person, shift or department.
  • Critical points: the steps where a mistake would affect the customer, the product or compliance.
  • Existing controls: what already prevents or detects problems, formally or informally.
  • Current information: the drawings, instructions, checklists and system screens people already use.

The best way to gather this is not in a meeting room. Take a real job and follow it through the operation with the people who do the work.

Then decide what needs to be documented

Once the process is understood, documentation decisions become much easier. Ask:

  1. Where would inconsistency cause a real problem?
  2. Where does the work depend on knowledge held by one person?
  3. What do customers, regulators or the standard specifically require to be documented or retained?
  4. What information do people need to perform and control the work, make the right decisions, and respond when something goes wrong?
  5. What evidence does the organization need to show that requirements were met?

The answers often point to something smaller and more useful than a stack of procedures: a clearer setup sheet, a checklist at the critical step, a one-page process map, a better order-review screen or a short work instruction for a task done rarely.

Where a fuller procedure is the right answer, it will be better because it describes the real process, uses the language of the people who do the work, and focuses on the points that matter.

Signs you started with documents instead of processes

  • Procedures describe departments rather than the flow of work between them.
  • The same steps are described differently in different documents.
  • People say "that's what the procedure says, but this is how we actually do it."
  • Critical handoffs between functions are not mentioned anywhere.
  • Documents were written by one person, without input from the people who perform the work.

If these sound familiar, the fix is not another round of editing. Go back to the process, follow the work and rebuild the documentation around what you find.

The bottom line

Define how work actually flows, identify what needs to be managed and controlled, and only then decide what needs to be documented. Documentation that grows out of a well-understood process tends to be shorter, more accurate and far more likely to be used. This is the starting point for designing a QMS around the way work actually flows.

Want a clearer picture of how well your processes are defined today? The free QMS Readiness & Maturity Scorecard gives you a readiness score, a five-dimension profile and three initial priorities to consider. It is a starting point; the next step is to validate it against how the work is actually done.