Why project governance matters before construction begins.

Governance should exist before mobilisation.

Construction creates visible activity. That visibility can create the impression that delivery begins when the contractor mobilises, the site is handed over or physical work starts. In reality, a project can already be carrying major delivery risk by that point.

A brief may still contain competing priorities. Design packages may be progressing at different levels of maturity. Authority responsibilities may be assumed rather than assigned. Procurement may be moving ahead of technical approval. Commercial decisions may be recorded in emails without a single controlled route back into the budget or programme.

Once construction starts, these unresolved interfaces do not disappear. They become site instructions, requests for information, rework, delayed procurement, commercial disagreement and programme pressure.

The objective is not to slow a project down with procedure. The objective is to make the project capable of moving quickly without losing control.

Start governance with the owner's priorities.

Governance should reflect what the project is trying to protect. A project driven by a fixed opening date may need different escalation thresholds from one driven primarily by capital cost or long-term asset performance. The owner should therefore define the major priorities and the trade-offs it is prepared to make before the team begins resolving them informally.

This gives later decisions a reference point. When programme, cost and design quality compete, the team understands the hierarchy rather than relying on whichever issue is most urgent that day.

Clear decision rights are a delivery tool.

On complex projects, the issue is rarely a complete absence of capable people. More often, several capable parties are working without a sufficiently clear model for who owns which decision.

The client may expect the consultant to resolve an issue that requires a commercial decision. The contractor may seek approval from a party that can review the technical proposal but cannot authorise the cost implication. A specialist may receive direction from more than one source. Each individual action can appear reasonable while the overall decision route remains unclear.

A governance structure should distinguish between recommendation, technical review, commercial review, approval and instruction. Those functions may sit with different parties. Treating them as interchangeable creates ambiguity.

Decision matrices, responsibility schedules and approval thresholds are most useful when they answer real project questions: Who can approve a substitution? Who accepts a programme change? Who confirms a design freeze? Who has authority to instruct work? What value threshold requires escalation? What happens when the required decision is not made by the target date?

Decision routes need time limits.

Knowing who can decide is not enough if decisions remain open indefinitely. Critical decision types should have expected turnaround periods that reflect the programme. Issues affecting near-term work may need an accelerated route and escalation if the target date is missed.

This allows the programme to include decision lead time as a real dependency rather than assuming approvals happen instantly.

Design maturity must be visible.

Design does not become “complete” in a single moment. Different systems, zones and packages mature at different times. A disciplined project therefore needs more than a general statement that design is progressing. It needs visibility over what is approved, what remains coordinated, what is suitable for procurement and what is suitable for construction.

This is particularly important where architecture, structure, MEP systems, specialist packages, interiors and authority requirements intersect. One package can be individually complete and still be unsuitable for release because an interface has not been resolved.

Use design gates for consequential decisions.

Formal gates can help at major transitions such as concept approval, tender release, construction release or procurement of long-lead systems. A gate should confirm not only whether documents have been issued, but whether the important unresolved risks are known and accepted.

For a deeper discussion of design decision-making, see Managing Design Decisions Under Real Project Constraints.

Commercial control begins before the first variation.

Budget control is often discussed as if it starts when invoices, claims or variations arrive. By then, the commercial consequence may already be embedded in an earlier decision.

A revised specification, changed structural solution, accelerated procurement route or altered phasing strategy may create cost implications long before a formal variation is presented. Governance should therefore connect technical decisions to commercial visibility at the time the decision is being considered.

This does not mean every technical conversation requires a full cost exercise. It means the project needs a defined route for identifying decisions with meaningful cost consequences, recording assumptions, obtaining the appropriate review and updating the controlled commercial position.

Distinguish forecast from committed cost.

Management should be able to see approved commitments, likely exposure and unresolved decisions separately. Combining them can hide emerging risk until it becomes contractual. A forecast should reflect what the project currently expects, not only what has already been signed.

Without that connection, the budget becomes a record of consequences rather than a management tool.

Change is normal. Uncontrolled change is not.

Projects change because information improves, client requirements develop, site conditions become known, products become unavailable or opportunities are identified. A rigid system that assumes change can be eliminated is unrealistic.

The stronger approach is to make change visible and traceable. Every significant change should have a reason, an owner, a technical impact, a commercial impact where relevant, a programme implication and a clear approval status.

That structure allows a project team to distinguish between a necessary change, an optimisation, a preference and an instruction that has not yet been properly authorised.

It also prevents a familiar project problem: different teams working from different versions of the same decision.

Control the point of implementation.

A change should not become real on site simply because it has been discussed. The governance process should define when the change is approved for implementation and which documents or instructions must be updated before work proceeds.

This is particularly important for substitutions and value decisions, where technical, commercial and programme approval can move at different speeds.

Site readiness is more than access to the site.

Physical access does not mean a project is ready to execute. Before significant work begins, the team should understand whether the information, decisions, interfaces and resources required for the planned sequence are actually available.

A practical readiness review may consider approved information, permits, temporary works, logistics, long-lead procurement, subcontractor appointments, method statements, inspection requirements, interfaces with existing assets and the status of client decisions that could affect the near-term programme.

The value of a readiness review is not in producing another checklist. It is in exposing dependencies while there is still time to act on them.

Governance should continue after mobilisation.

The governance model established before construction should not disappear once site activity begins. Decision rights, escalation routes, change control and reporting remain necessary throughout execution. What changes is the speed at which they need to operate.

Site governance should therefore be lighter where possible but faster where necessary, keeping management attention on decisions that affect safety, quality, programme, cost and owner priorities.