Engineering Change Propagation
How an approved change should move through engineering, procurement, project controls, construction and commissioning.
BoRo Studio · Part of BoRo's work on operational architecture for Solar + BESS project delivery.
Approval is not propagation
Most change processes are designed up to the moment of approval. There is a form, a review, a signature and a revision number. What happens after the signature is usually assumed rather than designed.
An approved change that has not reached the functions that must act on it has changed nothing in the field. Until it propagates, the project has two realities: the one engineering approved and the one everyone else is still executing.
What each function needs from a change
Procurement needs to know which open orders and which not-yet-released requisitions are affected, before the next release. Project controls needs the scope and cost consequence, so the forecast stops describing a project that no longer exists.
Construction needs the current drawing at the work front and an explicit statement that the previous one is superseded. Commissioning needs to know whether test procedures and acceptance criteria change. These are four different pieces of information, on four different clocks. Forwarding the same notification to everyone does not deliver any of them.
Where propagation usually stops
It rarely stops at a system boundary. It stops at an ownership boundary: the point where it is nobody's defined job to act on the change. Typically procurement and commissioning have no named owner for incoming engineering changes, so those handoffs depend on a project manager remembering.
The second common stop is the gap between a revision being issued and a revision being in use. Document control records that revision C exists. It does not record that the crew is still holding revision B.
What a designed propagation path contains
A classification, so a change that affects procurement is routed differently from one that does not. A named receiver in each affected function. An acknowledgement that means something specific: not that the message was read, but that the order was checked, the forecast updated, or the drawing replaced at the work front.
It also needs one visible state for the change itself, from approved to fully absorbed, so anyone can see which functions are still on the old reality. That state is what makes coordination latency measurable.
Where systems help, and where they do not
Once the path is designed, parts of it are good candidates for a system: routing by classification, tracking acknowledgements, showing the absorption state per project. Those are the tedious, repetitive parts that a person currently performs from memory.
What a system cannot do is decide who owns the change in procurement, or what counts as absorbed in construction. Those are operating-model decisions. Automating a path nobody has agreed on only makes the disagreement faster.