Anyone who has put a tender programme together at short notice knows how it actually happens. You do not start with a blank page. You find the closest thing you have — a job of roughly the right size and shape — and you open it, save it under a new name, and start cutting.
Then the trouble starts, because the new job is not the old job. The period is shorter. The phasing is different. So you drag durations down, delete the links that no longer make sense, draw new ones, overlap trades that used to run end to end, and drop a constraint in here and there to force a date somebody has already promised.
By about the third day you are no longer sure which links are the template's and which are yours. The bars look right. The finish date says what it needs to say. And the thing you cannot answer — the thing nobody asks until it matters — is whether the logic underneath still holds together at all.
The programme
So we built that exact situation and measured it, rather than describing it. A mixed-use scheme — three blocks, fourteen storeys, four zones a floor — taken from a template that ran to 717 working days, about thirty-three months. The tender wants it done in 547, about twenty-five. That is close to a quarter off, which is roughly what a competitive bid asks for.
It comes to 3,098 activities and 2,956 links after the rewrite. The compression was done the way it gets done on a deadline: durations cut hardest on the finishing trades, links deleted and redrawn around the new sequence, trades overlapped with start-to-start links and negative lags to pull work forward, and a scattering of fixed dates dropped onto the milestones that had already been committed.
What the check found
Importing it takes about four seconds, and the assessment runs before the chart opens. Eleven of the fourteen points have something to measure on a tender programme — invalid dates, missed tasks and the baseline index all need progress, and there isn't any yet.
Three passes out of eleven, and all three are things the rush never touched: hard constraints at 2.2%, long activities at 1.5%, and the critical path test. Everything the compression actually involved came back failing.
647 activities hanging in mid-air
The logic check is the one that matters most, and it failed at 20.9% against a threshold of five. In plain terms, 647 activities have nothing before them, nothing after them, or both — 271 with no predecessor and 422 with no successor.
An activity with no successor cannot push anything. It can slip a month and the finish date will not move, because as far as the programme is concerned nothing is waiting on it. That is not a cosmetic problem. It is the schedule quietly declining to tell you about a delay.
That concentration is the giveaway, and it is the detail I would not have predicted. Snagging is the last activity in every zone. When you rewire a zone, you redraw the links going into the new sequence and you simply never get to the end of it — so the handover of 168 separate zones now leads nowhere at all. Nobody would spot that by scrolling. It only shows up when something counts.
A network that barely constrains anything
Once that much logic is missing, the float goes strange, and float is the honest measure of how connected a programme really is.
A hundred and twenty-one activities out of 3,054 sit in the range you would call normal — four per cent of the job. Everything else is either squeezed below zero or drifting free with months of slack: 71.7% carry more than forty-four days of it. A tight programme does not look like this. A disconnected one does.
And 801 activities — a quarter of the programme — are in negative float, the worst at minus seventy-six days. Negative float is not a warning that something might go wrong. It is the schedule stating that the dates it is showing you are already impossible.
The leads nobody meant to leave in
310 of the 2,956 links carry a negative lag. The threshold for that one is zero, and it is zero for a reason: a negative lag says "start this before the thing it depends on has finished", which is a sentence that makes sense on a whiteboard and no sense in the arithmetic.
Used deliberately, on a handful of links, with a note saying why, it is a reasonable shortcut. Used three hundred times across the fit-out because the programme had to land on a date, it has quietly removed most of the constraint from the second half of the job. Only 82.4% of links are plain finish-to-start, against the 90% the standard asks for, which is the same story told a different way.
And after all that, the date is still wrong
Here is the part that would have cost real money.
All that cutting took ninety-four working days out of the template. The tender needed a hundred and seventy. The programme computes to 623 days and it was submitted as though it computed to 547, because the bar on the screen had been dragged to the right place and nobody re-ran the arithmetic afterwards.
The critical path length index comes out at 0.88, against a pass mark of 0.95. That single number says the same thing as the fifteen weeks: there is not enough room in this programme to deliver the date on the front of it.
One thing worth knowing if you run this on your own file and the negative float comes back as zero. A schedule only knows it is late if it has been told what it is being held to. Put the contract date on the completion milestone — a deadline, or a finish-no-later-than constraint — and the check has something to measure against. Without it, every programme is exactly as long as it is, and the two most useful checks in the set have nothing to say.
None of this is a criticism of the planner
I want to be careful here, because it would be easy to read the numbers above as somebody doing a bad job. They are not. Every one of those decisions is the right decision in the moment. Reusing a template is sensible. Cutting durations under a deadline is normal. Overlapping trades to recover time is exactly what you are supposed to do.
The problem is that there is no feedback. You make four hundred small changes over five days and nothing tells you what they add up to, because checking it properly by hand means tracing three thousand activities and the bid goes in on Friday. So it goes in, and the first honest assessment of the logic happens months later, usually during an argument about delay.
What you would actually do with this
Not fix all 647. Most of them are in zones that are repeats of each other, and the failures cluster — which is the useful part. Open the logic check, it lists the activities behind it, and the pattern shows up immediately: one trade, one position in the sequence, repeated 168 times. Fix the pattern once and re-run, and the failing count drops in chunks rather than one at a time.
The negative float is a different job and a more urgent one, because that is not a tidiness problem — it is fifteen weeks you have not got. Better to find it in the week you are writing the programme than in the month you are defending it.
The mechanics of the check — what all fourteen points are, which four are critical and why, and how to repair the logic on the chart itself — are in the schedule check that runs before the chart opens.
Try it on the one you're working on now
GeneraGantt reads MS Project, Primavera P6 and Asta Powerproject. Drag the file in and the assessment runs before the chart opens, with nothing to configure first. Nothing is saved: the schedule lives for your session and leaves with you.
It is free while it is in testing. If you have a tender programme sitting on your desk right now, that is the one worth checking — four seconds, and you will know whether the logic under it still holds.
The programme in this article is a generated one, built to behave the way a compressed tender programme behaves. Every figure quoted is measured on it rather than estimated — the critical path, the float and the fourteen-point scores were all computed from the file itself.