Ask why engineering changes take so long and you will be told the approvers are slow. Look at the data and you usually find something else: the changes are not waiting for decisions, they are waiting in queues belonging to people who have no decision to make.

That is the difference between an approval and a notification, and most change workflows confuse the two. Every confusion costs days.

The test for whether an approval is real

For each approver in your workflow, ask one question:

Has this person ever rejected a change, and what happened when they did?

The answers sort your approvers into three groups.

Real approvers reject things. They have the standing to stop a change and they have used it. Their step belongs in the workflow as a gate.

Ceremonial approvers have never rejected anything and could not really say what would make them. They are in the workflow because they wanted visibility, or because someone senior once asked to be included. They do not need an approval step. They need a notification, which costs zero days.

Absent approvers are the ones whose queue changes sit in while someone chases them by email. They are usually real approvers who are simply too busy — which is a resourcing problem wearing a workflow costume, and no amount of process design will fix it.

Run this test honestly and most organisations find they can remove a third to a half of their approval steps without losing a single genuine control.

Design from the decision, not from the org chart

The common failure is modelling the workflow on reporting lines: engineer to lead, lead to manager, manager to director. That produces a process that reflects who reports to whom, which has almost nothing to do with who understands the consequences of the change.

Model it instead on the questions that actually have to be answered before a change is safe:

  • Is the design correct? — the technical reviewer
  • Can we build it? — manufacturing
  • Can we buy it, and what does it cost? — supply chain
  • Does it affect anything certified, regulated or contractual? — quality
  • What happens to what we have already built or shipped? — the disposition decision

Each question needs exactly one owner. If two people own a question, both wait for the other. If nobody owns it, the change stalls at the end when someone finally asks.

Notice that this list is a set of questions, not a set of departments. Small changes may only raise one or two of them, which is the basis of the next section.

Not every change deserves the same journey

A single workflow for every change is the most common cause of a slow change process. A typo in a drawing note and a material substitution on a safety- critical part are not the same event and should not queue behind each other.

Two or three routes are usually enough:

Minor, no form-fit-function impact. Documentation corrections, note clarifications, drafting fixes. One technical reviewer. Hours, not days.

Standard. Anything touching form, fit, function, cost or supply. The full question set above, with the questions that do not apply explicitly skipped rather than silently waited on.

Major or regulated. Certification impact, customer notification, safety. Everything, plus whatever your regulatory regime demands.

The classification rule must be written and unambiguous, and — this is the part that determines whether it works — the person raising the change must not be the one who chooses the route. Self-classification degrades to everything being minor within about a quarter, reliably, in every organisation that tries it.

The exposure window is the number that matters

Most change metrics measure the wrong thing. Cycle time from raise to approve tells you about your process. It does not tell you about your risk.

The number that matters is the gap between approval and effect — the period after a change is approved but before the shop floor, the supplier and the ERP system are all working to it. Everything produced in that window is a candidate for scrap or rework, and it is money you are already losing without seeing it on any report.

Measure it on twenty recent changes. That single figure justifies more PLM investment than any productivity argument, for the reasons set out in the business case paper — it is cash that has demonstrably already left the building, rather than capacity you hope to recover.

Signs your process is theatre

Four symptoms, each meaning the same thing — that the formal process is not where decisions actually happen:

  • Changes are approved in batches at the end of the month. Nobody assessed forty changes on the thirty-first. They clicked forty times.
  • The real decision happened in a meeting, and the workflow records it afterwards. Not necessarily wrong, but be honest that the system is a logbook rather than a control, and stop counting its cycle time as though it measured decision-making.
  • There is an emergency route that is used routinely. If a third of changes are emergencies, your standard route is too slow and everyone has quietly agreed to bypass it.
  • Someone maintains a spreadsheet of changes in flight. The system is not answering a question people need answered — most often "what is waiting on me?"

None of these are fixed by adding approval steps, which is the usual response. They are fixed by removing the steps that were never decisions, giving each real question exactly one owner and making the fast route fast enough that nobody needs to route around it.

Working paper. If your change process is slow and you want help telling the real gates from the ceremonial ones, get in touch.