The Hidden Lag

One of the ideas I keep coming back to when leading projects is that work usually moves faster than the information about the work.

That sounds backwards at first. We tend to think delays come from slow teams, poor reporting, or lack of discipline. But in practice, what I see far more often is this: the project is moving along, decisions are being made, conditions are changing, and the information that’s meant to describe all of that is always a step behind.

This shows up in a lot of places. Schedules. Cost reports. Risk registers. Even simple updates. Anywhere people are expected to say what they’re seeing, there’s an opportunity for lag.

A very common example is budget updates from contractors. On many projects, it can take a couple of weeks for a budget update to come together and make its way to ownership. On the surface, that feels reasonable. These are complex documents. There are a lot of inputs. People want to make sure the numbers are right.

But when I look closely, the delay usually isn’t about missing information. It’s about wanting the document to be perfect.

The contractor or PM wants it clean. Defensible. Internally consistent. They want to be able to explain every line item without hesitation. They want to avoid revisions, follow-up questions, or uncertainty once it’s in front of the owner.

That mindset makes sense, especially for highly analytical people. It comes from professionalism and pride in the work. The problem is that the time spent getting to a perfect document often comes at the expense of the project.

By the time the update is shared, the project has already moved on. Work has progressed. New decisions have been made. Conditions have shifted. What finally arrives may be technically solid, but it’s already outdated. The energy went into polishing something that no longer reflects the current reality.

This isn’t just a budget issue. The same dynamic shows up in schedules. Long before a schedule actually slips, it usually starts to feel optimistic. A sequence tightens. A dependency feels more fragile. A revision lands later than expected. People notice these things early, but they hesitate to say anything until they feel certain.

It shows up in risk discussions too. Risks often only make it onto the list once they’re well formed, even though the early signals were there weeks earlier. And it shows up in basic questions, where answers stall because someone wants more time to think, believing that thinking longer is the responsible thing to do.

Waiting feels safe. Speaking early feels risky.

If you speak too soon and you’re wrong, you worry about credibility. If you raise something without a solution, you worry about creating noise. If you flag a concern that fades away, you worry about overreacting.

So people wait. Not because they don’t care, and not because they aren’t paying attention, but because being right feels more professional than being early.

The result is what I think of as a hidden lag. A gap between what the team senses and what the project officially knows.

It’s important to say this clearly: this doesn’t mean no one ever flags things early. On most teams, there are people who do. And those people are incredibly valuable. But early signals rarely surface evenly across the entire group. Some people speak quickly by nature. Others wait longer. The project moves at the pace of the slowest truth, not the fastest one.

This is where leadership quietly comes into play.

If you already speak early, this still applies to you. In fact, it applies especially to you. Because leadership at that point isn’t about what you are willing to say. It’s about what others feel comfortable saying around you.

Do people feel they can share something that isn’t fully thought through? Do they believe it’s acceptable to say, “This might be nothing, but here’s what I’m noticing”? Do early signals get explored, or do they get brushed aside until they’re proven?

Projects don’t speed up because everyone has perfect information. They speed up when information moves early enough to matter.

This is closely tied to the idea of slowing down to set up. Setting expectations early that the project benefits from hearing what people are seeing, even when it’s incomplete. Especially when it’s incomplete. Making it clear that the goal isn’t certainty, it’s honesty about direction.

When teams wait for perfect answers, they don’t avoid problems. They just encounter them later, when the options are fewer and the fixes are more expensive.

The project doesn’t need certainty as early as it needs honesty. When that becomes the norm, schedules stop surprising people, budget updates become conversations instead of events, and risks surface while there’s still time to act.

And the project moves faster, not because people rush, but because they stop waiting to be right before they speak.

That’s it.