Project Governance begins at the Tender Planning Stage, not after winning the Tender

Seeds of every project management crisis are planted during the bid planning stage, agree?

There’s a persistent assumption in infrastructure companies that project management begins the day a Letter of Award is issued. Everything before that- the tender, the negotiation, the contract signing- is treated as business development’s territory, and everything after is handed to the project management team as a clean slate.

Having spent thirty years around both sides of that handover, I can say this assumption is one of the most expensive misconceptions in the industry, because the project management team rarely inherits a clean slate. They inherit every commitment, assumption, and shortcut that was made during the bid.

Consider a common scenario: a bid team, under pressure to stay price-competitive, commits to an aggressive project timeline to score well on the technical evaluation, without genuinely stress-testing that timeline against realistic approval delays, monsoon-affected construction windows, or land handover schedules that the authority has a poor track record of meeting on time.

Once the bid is won, the project management team then spends the next two years managing a schedule that was never realistic to begin with, absorbing blame for delays that were, in effect, pre-programmed into the contract at the tender stage.

I’ve seen this repeat across transport and water infrastructure projects with remarkable consistency. The project managers involved are often excellent, technically sound, well-organised, genuinely capable of delivering complex works. But no project management methodology, however rigorous, can fully compensate for a contract whose baseline assumptions were unrealistic from the start.

This is why I keep returning to the point that tender strategy and project delivery aren’t separate disciplines with a clean handoff between them; they’re a continuum, and weaknesses at the start of that continuum surface, reliably, at the end of it.

There’s a specific failure mode worth naming here: bid teams that treat the technical proposal’s implementation schedule as a marketing document rather than an operational commitment. It’s tempting to present an aggressive, impressive-looking timeline because it scores well against evaluation criteria that reward speed. But that same document typically becomes a contractually binding milestone schedule the moment the contract is signed.

The project management function then spends its first year not managing construction but managing the gap between what was promised on paper and what’s operationally achievable on the ground, a gap that a more disciplined, evaluator-aware bid process would have narrowed considerably before submission.

This is precisely where I position my advisory work: not in how project management executes the delivered contract, but in how the tender is structured so that project management inherits a workable contract in the first place. That means stress-testing implementation schedules against real historical data from comparable projects before they’re submitted, rather than after.

It means making sure that risk allocation clauses, who absorbs delay costs from third-party dependencies like utility shifting or environmental clearances, are negotiated with enough foresight that the project management team isn’t left absorbing costs nobody structurally assigned to anyone.

I’d also point to a subtler issue: bid teams and project management teams in most companies rarely sit in the same room during tender preparation, even though the project management team is the one who will live with every commitment made.

Companies that have started deliberately including senior project management input into the bid strategy phase, not to write the technical proposal, but to sanity-check its operational assumptions, report meaningfully fewer disputes and schedule overruns downstream. It’s a structural fix, not a training fix, and it costs very little to implement relative to the disputes it prevents.

I’ve also noticed that companies which formalise this cross-functional input tend to negotiate better change-order provisions during the bid stage itself, clauses that clearly define how scope changes, third-party delays, or authority-side dependencies will be priced and time-extended, rather than leaving those mechanisms vague and open to dispute later.

Project managers who’ve lived through a change-order standoff know exactly which ambiguities in a contract cause the most friction months into execution; involving them before the contract is signed, rather than only after a dispute arises, is one of the simplest structural changes a company can make to reduce downstream conflict.

For infrastructure leaders reading this, I’d frame the question this way: when your project management team escalates a schedule or cost overrun, how often does the root cause trace back to an assumption baked into the original bid, rather than a failure of execution discipline? In my experience advising across sectors, that number is higher than most leadership teams initially expect.

The fix isn’t better project management software or more rigorous monitoring dashboards, useful as those are. It’s making sure the contract that project management inherits was built on assumptions someone tested at the tender table, before the ink dried, because a project management team can only be as effective as the contract it’s asked to deliver.

If your delivery teams keep inheriting schedules and risk allocations they had no hand in shaping, the fix usually starts at the tender table, not the site office.