Beneath the Price: A Dependency Ledger for UK Bids

The cost of an untested assumption

A bid is often treated as a statement of intent. In practice, it is a bundle of promises held together by assumptions. Some of those assumptions belong to the bidding organisation. Others sit with subcontractors, software suppliers, certification bodies, regulators or the client itself. When the proposal is written under time pressure, those dependencies tend to be compressed into a single optimistic sentence: subject to third-party confirmation, or allowing for client approvals.

That sentence is where delivery disputes begin. A price built on an unconfirmed licence, a start date that ignores a client’s internal sign-off, or a scope that assumes a subcontractor can mobilise at short notice is not a commercial judgement. It is an unmanaged risk. The discipline required is not elaborate. It is a one-page dependency ledger, prepared before the bid goes firm and reviewed at the points where commitments become difficult to reverse.

Why dependencies hide in plain sight

Most bid teams are competent at listing their own work. They are less systematic about the work that must happen elsewhere. A software licence may be assumed to be transferable. A specialist subcontractor may be assumed to have capacity. A regulatory approval may be assumed to be a formality. A client-side technical authority may be assumed to be available in the week the project needs them.

These assumptions survive because they are rarely owned by a single person. The bid lead owns the document. The commercial lead owns the price. The delivery lead owns the plan. The dependency sits between them, visible to no one in particular. The purpose of the ledger is to give that dependency a name, an owner and a date.

A single page, not a second plan

The ledger should not become a parallel project plan. Its value lies in its brevity. One page, landscape, with no more than fifteen or twenty live dependencies. If the list grows beyond that, the bid is probably not ready to be priced firmly. The ledger is a decision aid, not an audit trail.

A workable structure is as follows:

Field	Purpose
Dependency	A plain description of what must be in place
Type	Subcontractor, licence, regulatory, client-side, internal
Owner	The named person accountable for confirming it
Evidence required	The document or confirmation that proves it
Needed by	The date by which it must be confirmed
Impact if late	Cost, date or scope consequence
Fallback	What the bid does if the dependency fails

The right-hand columns matter most. A dependency without an impact statement is merely a note. A dependency without a fallback is a single point of failure.

Assigning owners who can actually confirm

Ownership is where most registers fail. It is tempting to assign a dependency to a function: legal, procurement, technical. That is not ownership. The owner must be a named individual who has the authority and access to obtain confirmation. For a subcontractor dependency, that may be the delivery lead who holds the relationship. For a software licence, it may be the commercial lead who can read the terms. For a client-side approval, it may be the account lead who can ask the question directly.

The test is simple. If the owner cannot produce evidence by the needed-by date, the dependency is not owned. It is merely observed.

Separating fact from expectation

The ledger should distinguish between confirmed dependencies and expected ones. A confirmed dependency has evidence: a signed subcontract, a licence schedule, a written confirmation from a client authority. An expected dependency has a plausible route but no proof. Both can appear on the page, but they should not be treated as equivalent when the price is signed off.

The common failure is to price the bid as though expected dependencies are confirmed. A framework call-off may assume a specialist is available. A software implementation may assume the client will provide data in a particular format. A regulated project may assume a sign-off will arrive within a standard period. Each of these may be reasonable. None of them is a fact until someone has checked.

The client-side dependency is the one most often missed

Bid teams tend to focus on their own supply chain. The client’s internal dependencies are harder to see and easier to ignore. They include technical approvals, information security reviews, data protection assessments, estates access, procurement gateways and sponsor availability. In UK public sector work, these can be sequential and slow. In private sector work, they can be informal and equally unpredictable.

The ledger should include a client-side section with the same rigour as the supplier section. If the proposal depends on the client providing a named contact, a decision or a system access, that should be written down. It is not an accusation. It is a shared assumption that both parties can see before the contract is signed.

Review gates, not a single review

The ledger should be revisited at three points. First, before the price is finalised. Second, before the submission is made. Third, before the contract is accepted. At each gate, the question is not whether the dependency is still on the page, but whether its status has changed. A dependency that was expected at bid stage and is still expected at contract stage is a commercial exposure.

The review should be short. Fifteen minutes with the bid lead, the delivery lead and the commercial lead is usually enough. The output is not a revised plan. It is a decision: proceed, qualify, price the risk, or decline.

Writing the qualification without frightening the client

Not every dependency needs to be presented as a caveat. Some can be handled through the proposal’s assumptions section, written in plain language. Others should be discussed directly with the client before submission. The ledger helps the bid team decide which is which.

A useful rule is to reserve formal qualifications for dependencies that could change the price, the date or the scope. Routine confirmations can be managed through the mobilisation plan. Material dependencies should be surfaced early, with a proposed route to resolution. That is not a weakness in the bid. It is evidence of control.

The ledger as a delivery instrument

The one-page register should not be discarded once the bid is won. It becomes the first agenda item at mobilisation. The owners remain the same. The dates become delivery milestones. The assumptions become the first things to test. A bid that arrives with a dependency ledger is easier to hand over, easier to govern and easier to defend when a third party fails to perform.

In a competitive market, the firm that can explain its dependencies clearly is often the firm the client trusts with the work. The ledger does not make the bid more complex. It makes the complexity visible, which is the precondition for managing it.