One late part, and the three parts it made late

Coupling in a build schedule, and why delays multiply rather than add.

A build schedule is really a network of jobs sharing a small number of machines, jigs and pairs of hands, so a single late part costs the schedule its own lateness plus the lateness of everything that was waiting behind it for the same shared resource.

Queueing for one mill, one jig, one oven

Most parts in a build pass through a small set of shared resources: one mill, one welding jig, one curing oven, one pair of experienced hands able to do a given job well. While each job reaches that resource roughly on time, the resource works through them one after another and nothing backs up. The moment one job overruns, every job queued behind it for that resource is pushed back by the full amount of the overrun, because the next job cannot start until the one ahead has finished. Each delayed job can then delay whatever was waiting on it in turn. Queueing theory puts a version of this in Little's law: the average time a job spends in a system equals the number of jobs in it divided by the rate at which they are completed, so the longer the queue behind a resource grows, the longer everything in it waits.

Cooking a large meal with a single oven shows the same thing. Suppose four dishes each need their turn inside it, and the first overruns by twenty minutes. Each of the three behind it is now twenty minutes late without needing any extra time itself, so one slow dish has put an hour of lateness across the meal. A dish that then needs to rest before serving slips further, and one assembled from two others that were both waiting on the oven can end up later still. No dish's own cooking time changed; only its place in the queue did.

Protecting the few parts at the front of a queue

A day's delay on a part nothing is waiting for costs the project roughly a day, and the schedule absorbs it. The same day on a part at the front of a shared jig, or feeding an assembly that three other parts are waiting to join, is copied onto each of them. Jobs that were planned to overlap once the resource freed up are forced into a sequence instead, one after another, which is the sense in which delay multiplies.

Read this way, parts deserve unequal protection against slipping. A part with nothing downstream can afford slack, while a part at the front of a shared resource, or feeding several assemblies at once, deserves buffer time and priority regardless of how hard it is to make. Finding those few coupled parts, and watching them closely, protects a fixed date better than asking everyone to work faster. It also explains why the same size of delay is shrugged off in one build and treated as a crisis in another, since what differs is how much was quietly waiting behind the late part for the same jig, oven or pair of hands.

My key error with this

I ordered the material for the chassis mould so that it would arrive exactly when I needed it, which felt like good planning at the time and was really just a schedule with no slack in the one place slack mattered most. It arrived a month late. The mould was late behind it, the chassis was late behind the mould, and every component that mounted to the chassis inherited the delay without any of those teams having done anything wrong. What saved it was partly luck and partly a decision I cannot claim was strategic, since we had already made a fibreglass article to test the process, and that let the dependent work carry on against a real shape instead of against a drawing, so most of it landed only about a week behind. What replaced the belief is that lead time and slack are different quantities, and that the amount of slack an order deserves has nothing to do with its own cost and everything to do with how many other things are queued behind it.