Every client I have worked with wants the same two things, and they can look contradictory.

They want to be in control of a project that carries their money and their reputation. They also have a day job, and cannot spend three days a week chasing consultants, reading programmes and mediating between an architect and a structural engineer.

Governance is how those two things stop being contradictory. It is the structure that separates the decisions that must be yours from the work that should never reach your desk. Get it right and you are more in control with less of your time, rather than less in control with more of it.

The way we describe it is simple. We manage it, you govern it.

What governance actually means on a construction project

Governance is a word that has been diluted by overuse, so it is worth being concrete.

On a construction project, governance is the set of arrangements that answer four questions before the project starts:

  • Who decides what? Which decisions sit with you, which sit with your project manager, and which require both.
  • On what evidence? What information a decision-maker is entitled to have in front of them before they are asked to decide.
  • By when? What the decision deadline is, and what happens to cost and programme if it passes.
  • Recorded how? Where the decision, its rationale and its consequences are written down.

Notice that none of those questions are about construction. They are about how your organisation exercises authority over a large, fast-moving commitment. That is why governance failures show up as commercial failures: an undocumented decision becomes a disputed variation, and a decision made without evidence becomes the change order that follows it.

Which decisions are yours?

The single most useful hour at the start of a project is spent agreeing this table, and then holding to it.

DecisionClient governsProject manager manages
What is being built, and why✓Advises and tests
The budget and its contingency policy✓Builds and monitors it
Procurement route and contract form✓ approvesRecommends
Which consultants are appointed✓ approvesShortlists, runs the process
The programme and its key dates✓ approvesOwns and drives it
Design decisions within the agreed brief and budgetInformed✓
Day to day coordination between consultantsNo involvement✓
Variations above an agreed threshold✓Prepares with options and cost
Variations below that thresholdReported after✓
Accepting a risk, or paying to remove it✓Presents the choice
Chasing, minuting, expediting, following upNo involvement✓

Two rows do most of the work here.

The variation threshold matters because it is the boundary that determines how often you are interrupted. Set it too low and you are approving door ironmongery. Set it too high and you find out about a material commitment after it is made. There is no universal right number; it depends on the project's value and your organisation's appetite. There is a wrong approach, which is never agreeing one.

The risk row matters because it is the decision clients are least often given properly. Risks are not simply reported. Every live risk should reach you as a choice: accept it, mitigate it at a stated cost, or transfer it. A risk register that lists risks without presenting that choice is a document, not a governance tool.

Three colleagues in discussion around a table with documents and a laptop between them

Slow decisions are usually a paper problem

Ask any contractor where client-side delay comes from and they will tell you the client was slow. The research broadly supports the first half of that. A 2023 study in Sustainability, surveying 91 construction professionals on mega infrastructure projects, found client decision-making delay to be a substantial obstacle, with the client bearing greater responsibility for delayed decisions than consultants, contractors or subcontractors.

What is more interesting is the second half of the same study: the leading factors behind those delays were incomplete documentation and evidence, inadequate coordination and communication, poor leadership, and a lack of technical expertise in the decision-making chain.

Read that list again from the client's side. Three of those four are things done to the decision-maker rather than by them. A director who cannot decide because the paper in front of them does not contain the cost, the programme impact or the recommendation is not being slow. They are being asked to guess, and sensible people decline to guess with other people's capital.

That study looked at large infrastructure projects outside the UK, so treat the figures as directional rather than a local benchmark. The mechanism, though, is one I recognise on schemes of every size.

Which means the fix is largely in the reporting.

Four tests for a decision paper

Before anything reaches a client or a board from us, it has to pass four tests. They are not sophisticated, and that is rather the point.

  1. Is the decision stated as a question with options? Not "the cladding package is over budget", but "cladding is £180k over. Option A absorbs it from contingency, Option B changes the specification with these consequences, Option C phases it. We recommend B."
  2. Is the consequence of delay stated? Every decision has a date after which it costs more or removes an option. If the paper does not say what that date is, the recipient cannot prioritise it against everything else on their desk.
  3. Is there a recommendation? A project manager who presents three options without a view is offering the appearance of choice while withholding the expertise the client is paying for. Make the call, show the reasoning, and let the client overrule it.
  4. Can it be found in two minutes? Executive summary, then the detail, then a Decisions Required list. If the reader has to mine a forty-page pack to locate what is being asked of them, the pack has failed regardless of how thorough it is.

That last structure, executive summary plus full report plus a Decisions Required section, is the reporting spine we use on every project. It exists because the alternative, comprehensive reporting with the decisions buried inside it, reliably produces the delay everyone then blames on the client.

A printed project programme chart spread across a desk with handwritten annotations

What good governance feels like from the client's seat

You should know, at any point in the month, what your project's position is on cost, programme and risk, and what you are being asked to decide next.

You should not be chasing anybody. You should not be discovering things in meetings. You should not be the mechanism by which two consultants communicate.

When something goes wrong, and on a construction project something always goes wrong, you should hear about it early, with the options already worked through and a recommendation attached. Problems raised early tend to be cheap. The expensive ones are the problems that were visible for months and reached the client as an announcement.

Good governance is what makes that early conversation possible. It gives the project manager the authority to act inside agreed limits, and gives you a defined and defensible place to stand when the decisions are genuinely yours.