One of the biggest problems in project controls is that everyone thinks the schedule is being managed.

Most of the time, it’s just being maintained.

There’s a difference.

Maintaining a schedule means updating progress, moving dates, keeping it technically current.

Managing a schedule means the logic reflects what’s actually happening on site. It moves when the project moves. It challenges assumptions. It tells you something you didn’t already know.

When I look at a schedule for the first time, I’m not looking at the dates.

I’m looking at the logic.

And the red flag I see more than anything else?

Everything is linked to everything.

Hundreds of predecessors. Chains that loop back on themselves. Activities that can’t start until 15 other things are done – most of which don’t actually need to be done first.

It looks thorough. It’s actually noise.

The other one?

A schedule that hasn’t changed in months. On a project that clearly has.

That’s not a schedule. That’s a document that used to be a schedule.

When a program stops evolving, it usually means one of two things: nobody is updating it with honest information, or the people running the project have stopped trusting it and started working around it.

Both are serious problems.

A good schedule is uncomfortable to look at. It should be showing you things you don’t want to see – early warning signs, constraint violations, float that’s disappearing quietly.

If your schedule looks clean and everything is on track… ask yourself when it last told you something that surprised you.

If the answer is never – that’s the red flag.