A new process starts on the shop floor. The process owner explains how the work is done. Someone writes this down as a Work Instruction. The document goes through review and approval. Operators get trained. Then it is released.
A few months later, an auditor watches the line. The operator is doing something different from what the Work Instruction says.
The process owner has a simple answer: "That is how we do it now, the process changed after we wrote the instruction."
No one is surprised. This happens so often that people stop seeing it as a problem. But it is worth stopping to think about it.
Now there are two versions of the process: one in the document and one on the floor. The real question is not why no one updated the Work Instruction. The real question is why the organisation started writing the document before it understood the process.
An SOP is not the process
An SOP or Work Instruction is a way to write down and control information about a process. It was never meant to be the process itself. But once it is written, most of us treat it that way.
ISO's guidance on the process approach says something similar. First, an organisation should understand its processes: what they need, what goes in, what comes out, what activities happen, in what order, and what risks and controls exist. Only after this should the organisation decide what documents are actually needed.
This order matters more than it seems. When you write the document first, the document becomes the main focus. People start worrying about document numbers, revision history, headings, and approval signatures, before they understand what the process actually needs. When you understand the process first, the document becomes just one result of that work. And usually a better one.
What a Work Instruction leaves out
Take a simple example: tightening fasteners on a sub-assembly before a production run. Someone writing this down for the first time might write:
Set the torque gun to the approved value and check the first assembly before starting production.
This sentence sounds fine on its own, but an operator cannot actually do the setup from it. They need to know:
- Which machine?
- Which torque gun?
- Which socket?
- Which fastener?
- Where is the approved torque value written?
- What should the operator do if the reading is outside the range?
- Which points get checked on the first assembly?
- With what tool?
- How many samples?
- Who is allowed to approve the setup for production?
- What happens to the first assemblies after the check?
- What record gets created?
- What happens if the first check fails?
- What safety steps apply during setup?
- What changes when the product changes?
This is not a writing problem. It is a process-definition problem. A good Work Instruction depends on answering these questions before anyone writes a single word.
The knowledge that never makes it into the SOP
A manufacturing process holds much more knowledge than what ends up in the final SOP. Some of this knowledge is written down somewhere: drawings, specifications, machine manuals, control plans, PFMEAs, inspection standards, customer requirements, engineering change notices, old problem-solving reports. Most organisations can find this if they look for it.
Other knowledge is harder to find. It lives in people's heads, not on paper.
- An operator may know that a part must face a certain way before it goes into the fixture.
- A technician may know that a parameter drifts after a tool change.
- A quality engineer may know that a certain feature needs an extra check, even though no document says so.
A short interview with the process owner rarely finds this hidden knowledge. What gets written down is the formal process: what is supposed to happen. But the real process, what actually happens and why, stays in people's heads. This gap is why a Work Instruction can be technically correct, and still not very useful on the shop floor.
Break the process down before you write anything
It helps to break the process into smaller parts before you touch the document. Production breaks down into the fastening process. This breaks down further into torque gun setup, socket installation, torque value setting, first-off check, and production release. Each level answers a different question. The process shows you the overall change from input to output. The sub-process shows you a meaningful part of that change. The activity or task shows you what actually needs to happen at the point of work.
This is not just useful for writing documents. It gives you a structure for everything that comes after the process too.
Why the activity, not the document, is the real unit of work
Look at one activity by itself: check fastener torque. The input is the tightened fastener. The method is how you take the measurement. The equipment is the tool you use. The specification is the acceptable range. The responsibility is who does the check. The frequency is how often you do it. The risk is a fastener that is too loose or too tight passing to the next step. The reaction is what to do when a reading is outside the range. The record is where you write down the result. And often, there is a customer or legal requirement behind all of this.
Once you capture all of this properly, one time, it can support several documents at once. The Work Instruction explains how the operator does the check. The Control Plan defines how the feature is controlled. The PFMEA looks at what could go wrong and how it is caught. A training module uses it to teach new operators. An audit checklist confirms the check is being done. A production record proves it happened. When you capture the activity well, it becomes worth more than any single document built from it. This is why the activity should be your starting point, not the document.
Where PFMEA, Control Plan and Work Instruction disconnect
Automotive manufacturing shows this particularly clearly, because the same activity is meant to travel through several quality documents at once. A characteristic is flagged in the process risk analysis. Its control appears in the Control Plan. The operator gets the requirement through standard work or a Work Instruction, and the result lands in a record. IATF 16949 expects this chain to hold together, especially for special characteristics.
In practice it rarely does. One person writes the PFMEA, someone else the Control Plan, a third person the Work Instruction and a fourth the inspection record, each working from their own understanding, at a different time, sometimes years apart. Every document can look fine on its own while the thread connecting them has quietly gone slack. That is a more serious problem than a badly written Work Instruction: process knowledge leaking out between documents that were never really talking to each other. Our article on PFMEA and process knowledge looks at why the people on the floor matter here.
What to capture before you write the SOP or Work Instruction
At the process level, you need to know: the purpose, the boundaries, the inputs and who supplies them, the outputs and who receives them, the owner, the resources needed, how this process connects with other processes, the requirements it must follow, the risks involved, and how you measure its performance.
Then, for each activity inside the process, similar questions come up each time. What needs to be done? Who does it? What is needed to start? How is it done? What equipment and material are needed? What parameters matter? What is the acceptance criteria? What can go wrong? How is that risk controlled? How do you check that the work is correct? How often do you check? What happens when something is wrong? What record gets created? Which standard or requirement does this activity come from?
These questions are not fixed. A production activity needs different answers than a management review. This is one more reason why a single SOP template never fits every situation.
Not every process behaves the same way
A production process, a calibration process, and a management review process are all "processes" in the ISO sense, but they do not ask for the same kind of documentation. A production activity needs detail on machine parameters, material identification, sequence, inspection criteria, safety, and reaction plans. A calibration process cares more about equipment identification, calibration criteria, traceability, frequency, and status. A management review is mostly about inputs, analysis, decisions, responsibilities, and follow-up. Force all three into the same template and you end up with unnecessary complexity in some places and not nearly enough detail in others. The type and nature of the process should decide what information gets captured, not the template.
SOP, Work Instruction or checklist: choosing the right format
Once you understand the process well, the next question is: what form should the document take? An SOP, a Work Instruction, a checklist, a form, a visual standard, a flowchart, or some mix of these? ISO's guidance is open about this. Process documentation can take many forms: written instructions, flowcharts, checklists, visual media, or electronic methods. The format was never the real goal. The real goal was always the process working well.
This matters most for operators. No one on the shop floor needs long paragraphs explaining the philosophy behind an operation. They need to know: what to do, in what order, what to check, what is acceptable, and what to do when it is not acceptable. Standardised work in the lean tradition makes the same point. It uses a precise sequence as a baseline for training and improvement, not as a document to satisfy an auditor. Some activities are best explained with a short visual instruction. Others truly need a detailed technical procedure. A management process usually works better as a flowchart. The work itself should decide the format. The format should not decide the work.
How to write a Work Instruction that actually works
Once you actually know what the process requires, the writing part is almost mechanical, and that is the point. A good Work Instruction reads as a set of precise, individual actions, not a paragraph of guidance. "Verify fastener torque using the calibrated torque wrench; acceptable range 8–10 Nm; if outside range, stop production and notify the shift supervisor" tells an operator something. "Verify fastener torque per specification" does not, even though the two sentences look similarly professional on the page.
The difference is not vocabulary. It is whether the specific values, equipment, and reactions were actually captured during process definition, and whether the person writing the instruction resisted the temptation to summarise them away for the sake of a tidier sentence. Most weak Work Instructions are not badly written. They are under-defined, and the writing simply inherited that.
Keep the connections alive after the document is approved
Writing a good instruction is only half the job. Most current practice misses the other half: keeping all the connected documents correct after something changes.
Say a machine parameter changes. In most plants, someone updates the Work Instruction and sends it for approval. Then the work stops there. But the PFMEA still shows the old risk. The Control Plan still shows the old control method. The inspection record still shows the old parameter. The training material still teaches the old method. The audit checklist still checks the old point. Nobody touches these, because nobody asks the right question at the moment of change.
The habit worth building is this: every time something changes, do not just ask "which document needs revision?" Instead ask "which parts of the process knowledge does this change actually affect?" This second question covers more than just the Work Instruction. This is the real difference between documentation you can trust and documentation that slowly stops matching reality. It is the same disconnect between PFMEA, Control Plan and Work Instruction described earlier.
Documentation is one stage in this loop, not a filing exercise that ends once it is approved.
Where to actually start
You can start small. You do not need to change everything in your plant at once.
- Pick one real process: machine setup, incoming inspection, calibration, or employee training.
- Choose whatever is closest to you.
- Walk through the process, watch the actual work happen, talk to the people who do the work, not only the process owner.
- Find the activities. For each one, write down the inputs, outputs, requirements, risks, and controls.
- Then ask: what does the person doing the work truly need to know to do it correctly and safely?
- Only after this should you write the SOP or Work Instruction.
At this point, the document is not an attempt to remember the process from memory. It is the controlled record of a process that someone has already taken the time to understand. This is a small difference in wording. But it is a large difference in practice.
If you would like a second pair of eyes on this, our Paper-to-Floor Check compares what your documents say with what actually happens on the line.