Monday was decided last Thursday.

The horizon nobody states

Every project has this horizon. Nothing in the process produces a document that states it, which is why the same argument keeps happening.

Something turns up on Friday. It's real, it matters, and it changes what should happen on Monday. So it gets raised, and the answer that comes back is that the crews are already committed. That answer is correct and it sounds like an excuse, because the thing it rests on — the notice period for moving a gang — has never been stated by anybody.

Writing it down converts a recurring irritation into a piece of information. If moving a crew needs three working days, then Wednesday is the last day a discovery can affect the following Monday, and everybody can be told that once rather than discovering it individually.

Every function's week starts on a different day

Here is the part that costs the most and gets the least attention.

The crews aren't the only people running a weekly cycle. Engineering answers queries in a meeting on one day. Procurement reviews requisitions on another. A permit desk issues on Thursdays. The client's representative visits on Tuesdays and signs things while present. A subcontractor's own planner produces their look-ahead on a Friday.

Each of those cycles is weekly, each is sensible on its own, and no two of them were set relative to each other. Week 14 established why: the meeting set accumulated rather than being designed, one item at a time, each added by somebody solving their own problem.

So the phases are arbitrary. And a constraint doesn't stay inside one function — it crosses two or three of them on its way to being cleared.

Which means the relationship between the cycles is a real property of the project that nobody owns. Each function can describe its own; there's no document anywhere that puts them side by side.

The elapsed time is phase, not work

Follow one constraint through and the arithmetic becomes visible.

A dimension on a drawing conflicts with something built. The site raises a query on Tuesday. Engineering's query meeting was that morning, so it waits until the following Wednesday, when it is answered in twenty minutes. The answer needs a materials change, and procurement reviews on Mondays, so it waits again. The revised item needs a permit, and permits issue on Thursdays.

Total work: perhaps four hours across three people. Total elapsed: eleven days, almost all of it spent waiting for the next cycle to come round.

And the eleven days aren't a worst case. Raise the same query a day earlier and it catches that morning's meeting; the whole thing closes in four days. The difference between the two outcomes is the day of the week the site engineer noticed something, which isn't a thing anybody manages.

Nobody in that chain was slow. Each function handled the item promptly once it reached them. The delay is entirely in the gaps between cycles that were never phased, and it is invisible in every report, because each function measures its own turnaround and every one of them looks good.

What handing over a constraint actually is

Given that, the moment a constraint moves between functions is worth treating as an event rather than as a formality.

Three things have to be true for the handover to work. Somebody has to receive it — a named person, not a mailbox. The receiving function's next cycle has to be known, so the sender can tell whether the answer will arrive in time or not. And the sender has to keep it, because a constraint handed over is still theirs until it comes back.

That last one runs against instinct. Passing something to the right person feels like completing an action, and in a routing sense it is. In a delivery sense it's the start of a wait whose length the sender can predict and the receiver has no reason to mention.

Which is worth saying plainly, because it changes what a handover looks like. “Sent to engineering” is a status. “Sent to engineering Tuesday, their meeting is Wednesday week, so expect an answer on the 14th” is a forecast, and it is available at the moment of sending.

The day inside the week

The same shape appears one level down and it is worth naming because the remedy is different.

A day has one decision point, in the morning, when crews are directed. After that the cost of moving people rises sharply — a gang redirected at eleven has lost most of a shift to travel, briefing and setting up, and will lose part of tomorrow going back.

So a constraint discovered at nine can be worked around today. The same constraint discovered at eleven can't be, and the honest response is to fix tomorrow rather than rescue today. A project that tries to rescue every day spends its supervision on part-shifts and gets neither.

System design

Row three is the only change this week asks for and it is three extra columns on a log that exists. A log carrying two timestamps, raised and closed, hides the phase problem inside a single number — which is the pair almost every log carries.

Record	Produced by	Required quality	Verified against	Feeds
Commitment horizon	Site, stated once	Expressed in working days, and known by everybody who raises things	How long moving a gang actually takes	Whether a discovery can change Monday
Cycle day per function	You, from the diary	The day each function actually decides, not the day it is meant to	Where items sat last month	Which pairs are out of phase
Constraint log	Whoever raises it	Five timestamps — found, sent, received, answered, cleared	The emails behind each	The split between work and waiting
Working time against waiting time	You, once	Separated, because no function measures the second	One month of logged constraints	The case for moving a meeting
Daily direction	The supervisor, each morning	Recorded as given, so a redirection at eleven is visible as one	What the crews actually did	Whether shifts are being part-spent

Row two is stranger than it looks. The day a function actually decides can differ from the day its meeting is scheduled, because decisions get made when the person who can make them is available. It is recoverable by looking at where items sat, and from nowhere else.

Practical insight

Take one constraint from last month and time it end to end, from records you already hold.

Five stamps: when you found it, when you sent it, when it was received, when it was answered, when it was cleared on site. You can recover most of those from your own emails and a log, and it costs you an hour.

Then split your elapsed time into two columns — time somebody was working on it, and time it spent waiting for a cycle. Your second column will be larger than you expect and larger than anybody has reported, because no function measures it: each one measures from receipt to answer, and the waiting happens before receipt.

That one number is your case for the only fix available, and the fix isn't working faster. It is moving one meeting by a day so two cycles line up. A query meeting the morning after site raises queries, rather than the morning before, removes a week from every item that crosses it — and it costs a diary change you can ask for with one number in your hand.

Key takeaways

• A crew at a work face on Monday is the end of a sequence that started the previous week — labour, material, plant, permit, access.
• The longest of those notice periods sets a horizon past which Monday is fixed, whether or not anybody says so.
• Writing that horizon down turns a recurring argument into a fact everybody can plan around.
• Crews aren't the only weekly cycle: engineering, procurement, permits and client attendance each run one.
• Each cycle is sensible alone and none was set relative to the others, because the meeting set accumulated rather than being designed.
• A constraint crosses two or three of those cycles before it is cleared.
• Its elapsed time is the sum of waits for the next cycle, not the sum of the work.
• Nobody in the chain is slow, and every function’s own turnaround measure looks good, which is why the delay is invisible.
• A handover needs a named receiver, a known next cycle, and a sender who keeps the item until it returns.
• A day has one decision point, and a constraint found at eleven is a case for fixing tomorrow rather than rescuing today.
• The available fix isn't working faster. It is moving one meeting by a day so that two cycles line up.

Records born here. The commitment horizon, stated in working days · the cycle day of every function a constraint has to cross · the constraint log, with five timestamps rather than two · the split between working time and waiting time · the named receiver for each kind of constraint · the daily direction, recorded as given.

What is coming next

Some of what stops a crew is a constraint to be cleared. Some of it is a change, and the difference isn't obvious at the moment it happens.

Somebody senior says do it this way instead. Work proceeds, because the person saying it is the person who says things. What comes next is what has just happened contractually, why it looks like nothing at the time, and how a sequence of those becomes an argument two years later that turns entirely on what was written down in the first hour.