Your Project Isn't Behind. Your Records Are.

When a project falls behind, the first instinct is to attack the schedule. Re-baseline it. Add resources. Lean on the team. Shorten the meetings and lengthen the days. All of it treats the slippage as a scheduling failure — a problem of sequencing and effort. And sometimes it is. But far more often the schedule didn't fail first. It just reported, late, a failure that happened somewhere upstream: in the records. Your project isn't behind. Your records are behind, and the schedule is only now telling you.

This isn't wordplay. It's a different diagnosis that points at a different cure. If you believe the problem is the schedule, you push harder on the schedule — and you often make things worse, because you're solving the wrong problem with more pressure. If you can see that the records slipped first, you fix the actual cause, and the schedule tends to recover on its own. The trick is learning to read a slip backward, from symptom to source.

How a records slip becomes a schedule slip

Watch the mechanism and it's almost always the same. A decision gets made in a meeting but never written down, so two weeks later the team relitigates it instead of acting. An approval is needed but no one's tracking the queue, so the work that depended on it sits idle while everyone assumes someone else is chasing it. A drawing forks into two versions and a crew builds the wrong one, and now there's rework that wasn't in any plan. A document can't be found, so a person spends a day reconstructing what already existed. None of these show up as "records problems" on a status report. They show up as days. And days are what a schedule is made of.

That's the quiet truth the calendar hides. The schedule doesn't generate delay; it accumulates it. Every undocumented decision, untracked approval, and unfindable file is a small deposit of lost time, and the schedule is just the account where they pile up. By the time the number turns red, the actual slippage happened weeks earlier, in a hundred small moments no one logged.

Read the slip backward

So the next time a project is behind, resist the urge to attack the calendar first. Ask the upstream question instead: what did we fail to write down, track, or find that put us here? Walk back from the delayed task to the thing it was waiting on, and from that thing to the record that should have moved it along. More often than you'd expect, the trail ends not at a lazy team or an aggressive deadline, but at a decision that lived only in someone's memory, an approval no one owned, or a file that took a day to locate.

Fix that, and you're not just recovering this slip — you're closing the source of the next one. A team whose records keep pace rarely has to explain a mysterious delay, because the delays never get to hide. The schedule stops being a place where lost time appears unannounced and becomes what it should be: an honest readout of work that's actually moving. Your project was never the problem. Get the records current, and the project tends to catch up to them.

This is the idea under everything we publish. See how it plays out across real projects in The Records Test series.