Fable
The bridge repair crew drew the process as an arrow diagram that only moves forward
The bridge repair crew used to rely on the master's verbal instructions. First prepare the wood, then set the posts, then lay the planks, then inspect. When the bridge was small, everyone could pick up the work by experience. Later the project grew larger; many steps could run in parallel, and many steps had to wait for the previous one. Painting could not come before plank-laying, and inspection could not come before load testing. The foreman first wrote a long checklist. The checklist looked tidy from top to bottom, but it strung together things that could run in parallel, and it did not say who each step depended on.
Once the painting crew came in early and found the bridge deck wasn't finished; the deck crew couldn't get the iron nails either, because procurement was scheduled too far back. The whole team was busy, yet they blocked each other.
The scribe drew an arrow diagram. Each dot was a process, and the arrows indicated what had to be completed first; the diagram did not allow arrows to loop back, otherwise the project would wait for itself forever.
The foreman immediately saw which tasks could run in parallel, which were on the critical path, and which delay would hold up the whole bridge. Scheduling no longer relied on shouting, but on dependencies.
Later, the bridge repair team used this diagram for pipelines, data processing and automation tasks. The diagram did not do the work for them, but it made execution order and waiting relationships computable.
The foreman understood that complex processes most fear ambiguous precedence relationships; an acyclic dependency graph lets the whole apparatus know what can start and what must wait.
The arrow diagram also exposed an old misunderstanding: being busy does not equal being fast. It was no use for the procurement team to run out early, because without a dimension sheet they could not buy nails; it was no use for the painting team to wait by the bridge, because without a load test they could not paint.
Later the scribe asked only three things each morning: which dots were already complete, which arrows were already satisfied, and which path was holding up the whole bridge. The foreman shouted less and judged more; complex projects finally had a skeleton that could be reasoned through. As long as the arrows were clear, even if the crew changed, a newcomer could understand why the project had reached this point. The quiet arrows on the diagram were more reliable than the shouting on the site. Who to wait for, who goes first, who is stuck—no longer depended on memory. Nor on luck.