Why a schedule breaks when the plat slips

A land development schedule breaks when the plat slips because almost every date on it was typed rather than derived. The cell holds the answer and not the reason: the fact that the first lot release waits on the final plat recording lives in the scheduler’s head and nowhere in the file. When the plat records three weeks late, every date that depended on it is wrong that same morning, and nothing in the file knows. An anchored schedule stores the dependency instead of the result. Each date is one of four things, fixed, event-anchored, task-anchored or composite, and a slip at the top becomes arithmetic instead of an afternoon.

What a date is actually made of

Behind every date on a development schedule are two facts: what has to be true before it, and how long after. A typed date has thrown both away and kept only the result. It is a correct answer with the working erased, which is fine until the question changes.

The question changes constantly on a land deal, because the events that gate the work belong to other people. The county records the plat. The state issues the SWPPP approval. The utility accepts the system. None of those dates are yours, and all of them move.

Four ways a date can know what it depends on

Fixed

A date somebody typed. It moves when they move it and never on its own, and that is the correct behaviour when the date genuinely does not derive from anything else on the project: a contractual takedown date, a bond expiry, a permit expiration, the end of the loan facility. These are the dates worth holding still, because they are the ones everything else has to clear.

Event-anchored

Plat recording plus thirty business days. What is stored is the rule, not the date. When the plat records, the date computes. Until it records, the schedule can still show where the date would land given today’s expected recording, marked as a projection rather than dressed up as a commitment. The difference between an anchored projection and a typed date is that one of them updates and the other has to be remembered.

Task-anchored

SWPPP approval plus five days. The anchor is another piece of work on this schedule rather than an outside event, and the offset is a real constraint: the one cannot start before the other has finished. Task anchors are what let a slip travel. Move the task and the chain behind it moves without anybody deciding to move it.

Composite

The later of bond release and completion. Two things have to be true, so the date is whichever of them lands second. The mirror case is the earlier of two, where either one starts the clock. Workbooks model this with a MAX or a MIN, and they model it correctly right up until the day somebody needs to force a date and types over the formula. From then on the cell is a constant wearing the appearance of a calculation, which is strictly worse than a constant.

Business days are part of the record, not a habit

Thirty days and thirty business days are different dates, and the gap between them widens across a holiday week. Which convention an offset uses is not a preference belonging to whoever built the schedule. It belongs in the record, next to the number.

So does the calendar those business days are counted against. A schedule counting against one holiday calendar while waiting on an office that observes another will be wrong in exactly the weeks it matters, and it will be wrong quietly, because both parties are confident and neither is looking at the same November.

What it costs to keep the dependency in somebody’s head

Four costs, and only the first one is obvious.

• The re-typing. Fourteen dates hang off the plat recording and thirteen of them are still sitting on the old one, because updating them was manual, and manual work gets done in the order of whoever remembered.
• Nobody else can check it. A schedule whose logic is not in the file cannot be reviewed by the person who did not build it. So it is not reviewed, and the one person who understands it is on a plane.
• You cannot ask it a question. If the plat slips another two weeks, does the first takedown miss the builder’s window? An anchored schedule answers that by changing one date. A workbook answers it with an afternoon of careful re-typing, so the question does not get asked, so the answer arrives later and from the builder.
• The record of why is gone. Six months on, a date is wrong, and nobody can tell whether it was wrong when it was typed or right when it was typed and overtaken since. Those need different fixes.

A slip, worked through

The final plat was expected on the fourteenth of September and records on the ninth of October, nineteen business days later. Four of the rows that hang off it:

The interesting output of that recalculation is not the new dates. It is the last row. The takedown used to be governed by bond acceptance and is now governed by the lot release, which means the thing worth working on this week has changed and the bond is no longer the constraint. That is a decision the schedule can hand you the morning the plat records, or a discovery somebody makes in November when a builder asks.

Escalation moves with the date it belongs to

Some dates are worth escalating ahead of rather than reporting on after. A critical date carries escalation checkpoints at T-90, T-60 and T-30, and the whole value of anchoring is that those checkpoints travel with the date. A checkpoint hanging off a stale date fires on the wrong day, and a checkpoint that fires on the wrong day twice is a checkpoint everybody has learned to close.

What to type and what to derive

The rule of thumb is short. If the date is imposed on the project from outside, by a contract or a permit or a bond, type it and hold it fixed. If it follows from something else on the project, anchor it and let it compute.

Anything typed that should have been anchored is a future surprise with a date already on it. The only thing not yet decided is which day somebody happens to look.

Written alongside PadFlow, which keeps a land development schedule, budget and draws on one record.