Coordination Latency

Coordination latency is the time between a decision or change being approved and every function operating from the same reality.

It is not the time it takes to make the decision, and it is not the time it takes to do the work. It is the interval in which part of the organization is acting on the new state and part of it is still acting on the old one, without knowing it.

Most delivery organizations measure activity: drawings issued, orders placed, percent complete. Those say how fast each function works. They do not say how long the functions spend working from different versions of the project.

The damage in project delivery tends to happen in that interval. Material is bought against a revision that was already superseded. A crew builds to a drawing that changed two days earlier. A forecast is presented without a scope change that everyone in engineering already knows about. Each function did its job correctly on the information it had.

Engineering approves a change. Ask four questions. When does procurement know, and is the affected order still open at that point? When does project controls carry the new scope in the forecast? When does the crew on site hold the current drawing? When does commissioning update the test plan?

In most growing organizations each answer is different and none is designed. Procurement finds out when someone tells them. Project controls finds out at the next reporting cycle. Site finds out when the drawing arrives. Commissioning often finds out at handover. The latency is not one number; it is a different number per function, and the largest one sets the risk.

Three things. Whether there is a defined propagation path for that type of decision, or whether it depends on someone remembering. Whether each receiving function has an owner for acting on it. And whether there is one agreed record of the current state, or several that have to be reconciled.

Notice what is absent from that list: the speed of the people involved. Coordination latency is a property of the architecture, not of effort. Capable teams working hard inside an undefined path still produce it.

Pick one change that actually happened in the last quarter and reconstruct, with dates, when each function began acting on it. That single trace usually shows more than a process workshop, because it records what the organization did rather than what it believes it does.

Then design the path for that class of change: who is notified, by what trigger, what they must confirm, and where the current state is recorded. Only after that is it worth asking which parts a system should carry.