Every project has a schedule. Far fewer have a schedule that means anything.
The distinction is not sophistication. Some of the least credible programs are the most elaborate — thousands of activities, fully resourced, updated weekly. The distinction is derivation. A credible schedule is the output of constraints. An asserted schedule is a target with activities arranged to reach it.
Four tests separate them, and none requires a planning specialist.
Test one: read the critical path
Open the schedule and look at what is actually driving the end date.
On a credible program the critical path runs through things that genuinely cannot be compressed: the interconnection, the permitting determination, the long-lead equipment delivery, the commissioning sequence. These are constraints imposed from outside the project.
On an asserted program the critical path runs through construction activities, usually fit-out or finishes. That is a signal, because those are the activities most easily shortened on paper. When the binding constraint on a power-intensive project appears to be internal construction rather than the utility connection, the schedule has been built backwards from the date.
Test two: check the long-lead order dates
This is the fastest test available and it is rarely run.
Take the three longest-lead items on the project. Find the delivery date the schedule assumes. Subtract the quoted lead time. That gives the date the order must be placed.
Now ask whether the order has been placed, and if not, what has to happen first. Usually the answer is that the design must reach a maturity it will not reach until after the required order date. Where that is true, the schedule is already invalid, and the only question is when it will be acknowledged.
If the required order date has passed and the order has not been placed, the schedule is not at risk. It is wrong.
Test three: find the float
Float should be visible, deliberately placed, and owned.
On a credible program you can point to where the buffer sits and say why it is there — ahead of commissioning, around the utility tie-in, before a regulatory determination. Someone owns it, and there is a rule about who may consume it.
Two patterns should concern you. The first is a program with no float anywhere, which means every activity must go right. The second, more common, is float spread thinly across hundreds of activities, which reads as comfortable in aggregate and protects nothing in particular. Diffuse float is consumed silently, activity by activity, and its disappearance is invisible until the end date moves.
Test four: apply a single delay
Take one plausible delay — a two-month slip on the main transformer, or a permitting determination that arrives a quarter late — and follow it through the logic.
On a credible program the consequence is traceable and proportionate. You can see what it hits, what absorbs it, and what the end date does.
On an asserted program one of two things happens. Either the delay disappears, absorbed by float nobody can locate, or the whole network shifts by the full duration, revealing that everything was in series and nothing had genuine independence. Both outcomes tell you the logic is decorative.
What a failing schedule is telling you
A schedule that fails these tests is not usually a planning failure. It is a governance signal.
It generally means the date was fixed before the work was understood — by a board approval, a lease commitment, a funding condition, or a public announcement — and the schedule was assembled to reach it. The planner is not at fault. The planner was given an end date and asked to produce a route to it.
That is worth knowing, because the remedy is not a better schedule. It is a conversation about whether the committed date was ever achievable, held while there is still time for the answer to be useful.
