From ISO 21502 to 30/60/90: Governance and RACI for Construction

Project governance is the framework that ensures decisions get made by the right people, at the right time, to deliver the outcomes a project was set up to achieve. The single most important early move is to write a governance charter and appoint a senior responsible officer before design work progresses. Skip that step and every later decision, from budget approvals to scope changes, has no clear owner.

TL;DR:

• Smaller projects can often operate with a single control group meeting biweekly, whereas larger or high-risk projects require multiple tiers and an independent assurance layer.
• Key decision thresholds should be based on both dollar value and risk category, with explicit escalation triggers for issues like safety concerns or schedule overruns.
• Incorporating governance expectations into the tender process helps prevent scope creep, ensures clarity on roles, and reduces disputes over contractual commitments.
• Using live, digital tools for risk tracking, decision matrices, and probabilistic forecasts improves decision speed and reduces the chance of outdated or inaccurate reports.
• The governance framework must be scaled to project complexity, involving more oversight and independent review only when justified by risk, size, or stakeholder involvement.

Table of Contents

• What is project governance in construction?
• Building the framework: roles, committees and change control
• Scaling governance to project size and risk
• How does the decision-making process work?
• Setting governance expectations at tender stage
• When should you use independent assurance reviews?
• What should governance dashboards actually measure?
• Building a roles and responsibilities matrix (RACI)
• A 30/60/90-day governance starter checklist
• How Niche Advisory applies governance on real projects
• Stakeholder engagement within project governance
• Tools and software to support project governance in construction
• Adapting governance to project size and complexity
• Roles of clients, consultants and contractors in governance
• Setting up governance? Here’s where to start
• Sources
• FAQ

What is project governance in construction?

Project governance construction frameworks define who decides what, when, and on what evidence. That is distinct from project management, which is the day-to-day work of sequencing tasks, managing the program and coordinating trades, and from contract management, which handles the commercial relationship between parties once a contract is signed. Governance sits above both: it is the structure that gives the project manager their mandate and holds them to account.

A useful test: if a decision changes who is accountable for an outcome, it is a governance matter. If it changes how the work gets done within an existing mandate, it is management. Confusing the two is why so many projects end up with steering committees debating scheduling detail while nobody owns the budget contingency.

Governance needs to exist before a tender goes out, not after a contractor is appointed. AS ISO 21502:2022 recommends governance be adapted to a project’s own site conditions, delivery model and stakeholder mix rather than bolted on generically. In practice, that means governance objectives should cover:

• Accountability — one person or body owns each major decision, with no ambiguity about who signs off.
• Transparency — reporting shows real risks and real numbers, not a sanitised summary.
• Value for money — spending decisions are tested against the business case, not just against budget availability.
• Outcome assurance — the project is judged on what the finished asset delivers operationally, not just on whether it was built on time.

Building the framework: roles, committees and change control

A governance charter is only useful if it actually specifies things, rather than gesturing at good intentions. The components below are the ones that repeatedly show up in mature frameworks, and each one needs to be written down, not assumed.

1. Committee charters. Every governance body, whether it’s a project control group or a full steering committee, needs a one-page charter stating its purpose, membership, meeting cadence and what decisions it can and cannot make.
2. Decision (delegation) matrices. A table mapping decision types (variations, budget releases, program changes) against dollar or risk thresholds and the role authorised to approve each one.
3. Reporting artefacts. Standard templates for status reports, risk registers and dashboards, so committees are comparing the same data month to month instead of reinventing the format each cycle.
4. Risk registers. A live document, not a static appendix, showing ownership of each risk and the trigger for escalation.
5. Change control procedures. A defined path for how a scope, cost or program change gets assessed, approved and then reflected in the baseline.

Role descriptions deserve more care than most charters give them. Each role needs its responsibilities spelt out, the specific delegations it holds (with thresholds), and at least one measurable KPI, whether that is decision turnaround time, budget variance tolerance or reporting timeliness. A steering committee member with no stated delegation limit will either rubber stamp everything or second guess everything, and neither is governance.

Pro Tip: Build your delegations matrix as a living spreadsheet, not a static PDF in the charter appendix. Every time a threshold gets tested in a real decision, log the outcome against it. Within a few months you will have a defensible track record showing the thresholds actually work, which is invaluable if a decision is ever challenged.

Templates matter here because they force specificity. A blank “roles and responsibilities” paragraph in a charter almost always gets skipped over in the rush to start construction; a filled matrix cannot be.

Scaling governance to project size and risk

Not every fit out needs a full steering committee, and not every $200 million build can survive with an informal monthly catch up. The right approach is risk based tiering: match the intensity of oversight to the scale and risk profile of the project, not to a fixed template.

Tasmania’s approach is a clear working example. Its project assurance framework mandates independent assurance for projects above $50 million, allows referral for independent review on projects between $10 million and $50 million, and is expanding mandated coverage to projects above $200 million. That tiering logic translates directly to committee design:

• Small to mid projects can run with a single project control group meeting fortnightly, combining sponsor, project manager and key consultants.
• Larger or higher risk projects need a two tier structure: an operational control group handling weekly detail, and a steering committee or board meeting monthly on strategic and budget decisions.
• Complex, multi stakeholder projects benefit from an independent assurance layer sitting outside the delivery team entirely.

Whatever the tier, one principle does not change: there must be a single point of accountability. That is usually the senior responsible officer (SRO), the individual who answers for the project’s outcomes to the sponsor or board. The SRO is not the project manager. The project manager runs delivery; the SRO owns the outcome and has the authority to make or escalate the calls the project manager cannot make alone, such as releasing contingency or approving a material scope change.

How does the decision-making process work?

A governance framework without a clear decision flow just moves disputes from the site office to the boardroom. The fix is a written approvals matrix paired with defined escalation triggers.

1. Set thresholds by dollar value and risk category, not just cost. A $50,000 variation with no safety implication might sit with the project director; a $20,000 change affecting structural certification should escalate regardless of cost.
2. Assign an accountable role to each threshold band, and name a backup for when that person is unavailable, so decisions never stall waiting for one signature.
3. Define escalation triggers explicitly: cost overruns beyond an agreed percentage, schedule slippage past a set number of weeks, any safety concern, and any technical change affecting design intent should all trigger automatic escalation rather than waiting for someone to raise a hand.
4. Use dispute avoidance boards or a quick resolution protocol for contractual disagreements, so a dispute gets a decision within days, not months, before it hardens into a formal claim.

The point of all this structure is speed, not bureaucracy. A well designed matrix should make most decisions faster because nobody has to guess who needs to be in the room.

Setting governance expectations at tender stage

Governance that starts after the contract is signed is already behind. The strongest projects build governance expectations into the tender itself, so bidders know what they are committing to before they price the job.

• Require a draft governance framework in the tender response, including proposed committee structures, reporting cadence and change control procedures.
• Ask for named key personnel with continuity commitments, not just CVs, since losing a project director six months in is one of the most common causes of governance drift.
• Request early commissioning and handover planning as part of the submission, not as an afterthought near practical completion. Engineers Australia’s guidance on outcome-focused governance stresses that boards should judge success on operational outcomes, which means the data needed to measure those outcomes has to be captured from day one, not reconstructed after the fact.

Building these requirements into the tender does two things: it filters out bidders who cannot articulate how they will be governed, and it gives the client a documented baseline to hold the successful contractor against for the life of the project. Disputes over “what was agreed” become far rarer when the governance expectations were priced into the contract from the start.

When should you use independent assurance reviews?

Independent assurance exists because internal reporting, left unchecked, tends to get optimistic. Gateway style reviews, health checks and deep dives are the three common mechanisms, and each serves a different purpose.

• Gateway reviews are scheduled checkpoints at defined project stages (business case, procurement, delivery, close out), giving an external panel the chance to confirm the project is still fit to proceed.
• Health checks are lighter touch, often triggered mid-stream when a committee suspects something is off but wants an independent read before escalating.
• Deep dives are targeted, intensive reviews of a specific risk area, such as a contested cost estimate or a program that has slipped repeatedly.

Infrastructure NSW’s Investor Assurance Framework uses exactly this tiered structure, directing assurance resources toward the highest risk capital projects rather than spreading reviews evenly. Projects should register for independent assurance when they cross a defined cost threshold, when risk ratings jump unexpectedly, or when a steering committee itself flags low confidence in reported figures.

The findings from an assurance review only earn their cost if governance actually changes in response. Treat each review as an input to the next charter revision, not a report to file away.

What should governance dashboards actually measure?

The metrics that matter to a steering committee are rarely the ones that dominate weekly site reports. Boards need a small set of figures they can actually interrogate, not a wall of green traffic lights.

Statistic to watch: Quantitative risk analysis and Monte Carlo simulation let governance bodies report cost and schedule outcomes as a probability range, commonly expressed as P50 (a 50% chance of finishing within budget) and P80 (an 80% chance), rather than a single misleadingly precise number.

A useful dashboard combines estimate at completion (EAC), schedule variance, the top ten live risks by exposure, and those P50/P80 confidence bands, updated on a consistent cycle rather than whenever someone remembers. Outcome measures deserve their own line: occupancy readiness, defect rates at handover, and early operational performance data, so the project is still being judged after practical completion, not just up to it.

None of this works if the board takes the numbers at face value. The ANAO’s review of Snowy 2.0 found that gaps in data assurance and unclear risk ownership let cost and schedule risk build up largely unchallenged. Boards need to ask where a figure came from and who owns the assumption behind it, every single reporting cycle.

Building a roles and responsibilities matrix (RACI)

A RACI matrix (Responsible, Accountable, Consulted, Informed) is the fastest way to stop governance meetings turning into arguments about who was supposed to sign off on something. Build one for every major decision type your governance charter identifies.

1. List every recurring decision your project makes: budget releases, design freezes, variation approvals, risk acceptance, handover sign off.
2. Assign exactly one “Accountable” per decision. This is the single most common failure point: two people marked accountable for the same decision guarantees a delay when it actually needs to be made.
3. Assign “Responsible” to whoever does the work behind the decision, such as preparing the cost analysis, which may be a different person entirely from who approves it.
4. Mark stakeholders who must be consulted before a decision, and separately, who only needs to be informed after. Confusing these two roles is the second most common failure.
5. Test typical assignments against real roles: the sponsor is usually accountable for the business case, the SRO for delivery outcomes, the project director for day-to-day delivery decisions within delegated thresholds, and the asset owner for operational acceptance at handover.

Split accountability and vague delegations are the two mistakes that undo an otherwise well designed matrix. If two names sit in the Accountable column for the same row, fix it before the project starts, not after the first dispute.

A 30/60/90-day governance starter checklist

Setting up governance from scratch does not need to take months. What it needs is a sequence, because trying to stand up every element simultaneously is how charters end up half finished and ignored.

• Governance charter defining purpose, committees and objectives.
• Committee terms of reference for every steering group or control body.
• Approvals (delegation) matrix with thresholds and named accountable roles.
• Risk register with live ownership, not a static list.
• Change control procedure covering scope, cost and program changes.
• Assurance plan setting out review triggers and cadence.

Store these as version-controlled documents, ideally in the same platform the project team already uses for document control, with one named owner responsible for keeping them current. A governance charter that has not been touched since the kickoff meeting is a strong sign that oversight has drifted from reality.

How Niche Advisory applies governance on real projects

On corporate fit out and relocation projects, Nicheadvisory’s project and construction management work maps closely to the framework above: a named accountable lead from day one, a delegation matrix agreed before design freezes, and change control built into the program rather than added after the first variation request. Workplace strategy work upstream, and heads of agreement negotiated early, mean governance expectations are set before a builder is even appointed, not retrofitted once site works begin.

That sequencing matters because it is where most tenant-side projects lose control: governance gets treated as a delivery-phase concern when it should be a pre-contract one.

Stakeholder engagement within project governance

Governance frameworks fail when they treat stakeholders as a communications afterthought rather than a structural input. A steering committee needs to know, at charter stage, who has genuine decision influence (the asset owner, the funding body, the occupying business units) versus who simply needs visibility (adjacent tenants, facilities teams, end users).

Map stakeholders against the same delegation matrix used for internal decisions. If a business unit head has effective veto power over a design decision because they control the budget for fitout fixtures, that needs to be written into the governance charter as a formal consultation point, not left as an informal courtesy. Vague consultation obligations are where projects lose weeks to late-stage objections that could have been raised and resolved months earlier.

Reporting cadence should differ by stakeholder tier too. Funders and the SRO typically need monthly financial and risk detail; occupying business units usually need less frequency but more translation, focused on what a decision means for their space, their move date or their operations. Running one reporting format for every audience is a common governance mistake, and it tends to under serve the people who actually need to act on the information.

Engagement in construction project management also means designing for disagreement. A stakeholder engagement plan that only accounts for consensus will break the first time a design change affects two stakeholder groups differently. Build a documented path for resolving competing stakeholder interests into the governance charter itself, ideally tied to the same escalation triggers already defined for cost and schedule issues.

Tools and software to support project governance in construction

Governance frameworks live or die on whether the reporting behind them is trustworthy, and that increasingly depends on the platforms teams use to capture and surface project data. Document control systems that version governance artefacts (the charter, the delegation matrix, terms of reference) prevent the common failure of committees working from outdated copies during a live dispute.

Program and cost control software that tracks earned value and schedule variance in near real time gives committees something closer to a live picture than a monthly status report ever can. Risk register tools that assign live ownership and automatic escalation flags, rather than static spreadsheets updated manually before each meeting, reduce the lag between a risk emerging and a governance body actually seeing it.

Dashboard and business intelligence tools that can present probabilistic forecasts, the P50/P80 confidence bands discussed earlier, rather than single-point estimates, help boards ask sharper questions instead of accepting a number at face value. None of this software replaces the governance structure itself. A sophisticated dashboard feeding an accountability vacuum just produces better-looking reports about the same underlying confusion. The tool should serve the framework, not substitute for one that was never properly designed.

Adapting governance to project size and complexity

A governance framework copied wholesale from a $300 million infrastructure program onto a $2 million office fit out will collapse under its own weight, and the reverse mistake, running a major capital works project on an informal weekly call, is worse. The skill is matching structure to genuine complexity, not to habit or convenience.

Start with the risk profile, not the budget alone. A modest-value project involving heritage-listed premises, multiple statutory approvals or a live operating environment can justify more governance rigour than a larger but straightforward vacant-site build. Use the tiering logic already discussed: single control group for low complexity, two-tier structure with an independent assurance layer for anything crossing a defined risk or cost threshold.

Complexity also comes from the number of parties involved, not just dollar value. A project with a single design and build contractor needs far less committee overhead than one juggling a head landlord, a base building contractor, a fitout contractor and multiple direct-appointed specialists. Scale committee membership to the number of interfaces that actually need coordinating, and resist the temptation to add representatives “just in case.” Every additional voice in a decision-making body slows the decision without necessarily improving it.

Revisit the governance structure at defined trigger points, not just at project start. A scope change, a new stakeholder joining, or a shift from design to construction phase are all legitimate moments to ask whether the current committee structure still fits the project’s actual risk and complexity, rather than the one it had six months earlier.

Roles of clients, consultants and contractors in governance

Clear governance depends on every external party understanding exactly what they are accountable for, not just what they are contracted to deliver. The client (or asset owner) typically holds ultimate accountability for the business case and the outcome the project was funded to achieve, even where day-to-day delivery is delegated to a project manager or SRO.

Consultants, including project managers, quantity surveyors and designers, are usually accountable for specific technical decisions within their discipline, but responsible in the RACI sense for producing the analysis that informs bigger governance decisions. A quantity surveyor does not approve a budget variation; they produce the cost data the accountable role uses to decide.

Contractors sit in a different position again: contractually responsible for delivery against a scope, but they should also be expected, per the tender-stage requirements discussed earlier, to participate in governance reporting rather than simply respond to it. A contractor that only shows up to steering committee meetings when there is a problem to escalate is a sign the governance structure was not built into the contract properly.

Independent advisors, whether engaged for tenant advocacy, dispute resolution or assurance reviews, occupy a deliberately separate position: consulted for judgement, not accountable for delivery. Keeping that separation clear, particularly on projects where the same firm might otherwise wear multiple hats, is one of the more overlooked governance safeguards in construction.

Setting up governance? Here’s where to start

Reading a framework is one thing; standing one up on a live project with real deadlines is another. If you are staring down a governance charter that needs writing before your next design freeze, or a steering committee structure that has to be agreed before tender documents go out, Nicheadvisory works alongside project teams as an independent advisor acting solely for tenants and owner-occupiers, never landlords, which keeps governance advice free of the conflicts that creep in when the same firm has interests on both sides of the table.

That independence matters most at the two points covered earlier: setting governance expectations into the tender, and negotiating heads of agreement before contracts are signed. Nicheadvisory’s workplace strategy and project and construction management services are built around exactly this sequencing, aligning governance and delivery with the business outcomes the project is actually meant to achieve.

If you need a governance charter reviewed, a committee structure workshopped, or an assurance plan built before your next stage gate, get in touch through the project and construction management team to scope what that looks like for your project.

Sources

• Project assurance framework | Infrastructure Tasmania
• Infrastructure Investor Assurance Framework (IIAF) — Infrastructure NSW
• Snowy 2.0 governance — Australian National Audit Office

FAQ

What is governance in construction projects?

Governance in construction is the structure that defines who makes which decisions, at what threshold, and how the project reports on progress and risk. It sits above day-to-day project management, focusing on accountability, transparency and outcome assurance rather than task sequencing, and it should be established before tender, per AS ISO 21502:2022.

What are the three pillars of project governance?

Most frameworks build governance around structure (roles, committees and delegations), process (decision-making, reporting and change control), and assurance (independent review and monitoring against outcomes). All three need to be documented in the governance charter, not left as informal practice.

What is a project governance example?

Infrastructure NSW’s IIAF is a practical example: it tiers projects by risk, applies gateway reviews, health checks and deep dives at defined points, and assigns clear responsibility for each assurance activity. Tasmania’s assurance framework, which mandates independent review above $50 million, is another concrete case.

What are the four P’s of governance?

Definitions vary across industries, but a common version used in project contexts refers to people, process, performance and probity, covering who is accountable, how decisions are made, how outcomes are measured, and how integrity in decision-making is protected.

Who should own the governance charter on a construction project?

The senior responsible officer typically owns the governance charter, since they are accountable for the project’s outcome to the sponsor or board. On tenant-side projects, an independent advisor such as Nicheadvisory is often engaged to help draft and maintain it, keeping the document current as decisions and contracts evolve.

Recommended

• Construction
• International Standards