Updated perfectly. Completely wrong.

A schedule can rot from the inside while every report looks normal. The bars move, the percentages climb, the dates recalculate — and underneath, the model has quietly stopped representing your project.

This week we go looking for the rot. There are three places it hides.

When the site ignores your plan

Start with the one almost nobody checks, and the one that does the most damage.

Your plan says: excavate the whole trench, then lay the pipe. Sensible. Safe. That's the logic in your model.

But site doesn't work like that. The gang has the first forty metres open, the pipe is sitting there, and the foreman — reasonably — starts laying it. Why would he wait?

So now you enter your actuals: the trench is 40% done, and the pipe, which was supposed to start after the trench finished, is 30% done.

You've just told your schedule that an activity started before its predecessor finished. That's out-of-sequence progress, and what your software does next depends on a setting you have probably never opened.

Progress override — the default in most tools — reasons like this: the pipe has started, so clearly it didn't really need the trench. I'll drop that dependency and let the rest of the pipe run free.

The remaining pipe now floats along in parallel with the remaining trench. The finish date jumps earlier. Everyone is delighted.

And it's nonsense. The pipe in the last sixty metres cannot possibly be laid into a trench that hasn't been dug. The physical constraint didn't disappear — the software just deleted it because you gave it a confusing update.

Retained logic does the sane thing. It says: fine, some pipe got laid early. But the rest of the pipe still waits for the rest of the trench. It keeps your logic, and it gives you a later date — a date that is actually true.

Same site. Same progress. Two different answers. One of them is real, and which one you get depends on a dropdown.

Go and check that setting today. Then check what your subcontractors' schedules are set to, because if they're on override, they've been sending you optimistic fiction for months and they don't know it either.

The constraint that hides the delay

We met hard constraints in Week 9. Here's what one actually does to you during execution.

The structure slips ten days. That's real, it's in your actuals, and it's honest.

In a healthy model, that delay travels. The facade moves, the handover moves, float drops, someone's report goes amber, and a conversation happens while there's still time.

But someone, months ago, put a "must finish on" constraint on the facade — because the date mattered and pinning it felt like control.

Now the delay arrives and the facade doesn't move. It can't. It's nailed to a date. Your float shows zero, exactly as it did last month, and the handover looks fine.

Nothing turned amber. Nobody was told. The work is ten days late and the model is serenely reporting that it isn't.

A hard constraint doesn't protect the date. It protects you from finding out about the date. And it will keep protecting you right up until the week the facade was supposed to be finished.

Float made from nothing

The third rot is the quietest.

Remember from Week 11: every activity needs a predecessor and a successor. When one has nothing after it — an open end — the software has nothing to push against, so it hands the activity an enormous, comfortable, entirely imaginary float.

And here's the trap during execution: high float looks like good news. You scan the report, you see 180 days of float on the temporary works, and your eye moves on. Nothing to worry about there.

That number isn't telling you the activity is safe. It's telling you the activity is disconnected. It cannot warn you, it cannot push anything, and it will sit there radiating false comfort until the day the thing it was supposed to feed is standing idle.

Treat suspiciously large float the way you'd treat a pressure gauge reading zero: not as good news, but as a broken instrument.

The ten-minute check

All of this is findable. It takes about ten minutes, and it should happen before you write a single line of your report — not after someone challenges it.

Count your open ends. Count your hard constraints. Look for negative float, and for float so large it's obviously fictional. Look for long lags hiding somebody's work. And look for activities that started before their predecessors finished.

You will find things. Everyone does. The difference between a planner and a controller is that the controller finds them before the client's planner does.

Dates are outputs. Percentages are outputs. Float is an output. The logic is the only thing in there that is genuinely yours — the honest description of how this building has to go up. Every fault in this article is a way that logic gets quietly deleted while you're looking at something else.

Practical insight

Do one thing this week: open your scheduling options and find out whether you're running progress override or retained logic.

If it's override — and it probably is, because it's the default — switch it and recalculate. Do not panic when the finish date moves out. It didn't get worse. You just stopped lying to yourself, and now you have time to do something about it.

Then send the same question to every subcontractor whose programme you accept.

Key takeaways

✔ A schedule can be perfectly updated and structurally broken at the same time.
✔ Out-of-sequence progress is normal on site — how your software handles it is not.
✔ Progress override deletes real dependencies and returns an optimistic, invalid date.
✔ Retained logic keeps the physical constraints and gives you a date you can defend.
✔ A hard constraint absorbs a delay instead of reporting it — it hides the problem, not solves it.
✔ Open ends manufacture float out of nothing; huge float is a broken instrument, not good news.
✔ Run the health check every month, before the report, not after the challenge.
✔ Dates and float are outputs. The logic is the only thing that's really yours — protect it.

What's coming next

Our model is now honest about time. It knows what's been built, what hasn't, and what that means for March.

It knows nothing whatsoever about money.

Next week we connect the two, and it changes what a schedule can tell you. Earned value: how to say, with one number, whether the work you've paid for is actually standing on site — and why "we've spent 60% of the budget" is one of the most misleading sentences in construction.

Time was the easy half.