Capital Program Dashboards for the Board: What to Show and How to Set RAG Rules

People seated around a conference table listening to a presenter

A board overseeing a capital program doesn't need twenty project reports stapled together. It needs to know, in a few minutes, whether the program as a whole is on track, which projects aren't, and what decisions it's being asked to make. Most capital reports fail that test. They're written for project managers, then forwarded upward with a cover page.

This guide covers what a board-level capital program dashboard should show, how to set RAG status rules that mean something, how exception reporting works, and the portfolio views that help directors govern rather than just read. Our monthly report template covers the single-project report for executives. This post is about the layer above it.

What a board dashboard is for

A board's job on capital isn't to manage projects. It's to approve funding, set risk appetite, hold management accountable and intervene when something is going wrong. The dashboard should serve those decisions and nothing else.

The U.S. Government Accountability Office's Executive Guide: Leading Practices in Capital Decision-Making describes leading organizations treating their proposed investments and existing assets as a portfolio, and monitoring project cost, schedule and performance against baselines, with status reported to people outside the project team. In private companies, its examples report to boards of directors or executive committees. One university example in the guide produced quarterly reports covering all capital projects, including cash flow, and required the board to be notified of significant changes such as a 10% change in scope or cost.

That's the model: a regular, consistent portfolio report, with clear rules for what gets escalated.

What to show on one page

A board dashboard should fit on one page, with supporting detail behind it. On programs we've supported, the page that worked best had five parts:

  1. Portfolio totals. Approved budget, current forecast, spent to date and contingency remaining, for the whole program. Show the change since last report.
  2. Status summary. How many projects are green, amber and red, and how that has moved since the last meeting.
  3. Exceptions. A short list of the projects that breach tolerance, each with one line on the issue and the decision needed.
  4. Cash flow against the capital budget. Forecast spend this fiscal year compared with the approved annual capital budget. Boards and finance committees care about the year as much as the total.
  5. Key milestones. The next quarter's major milestones, such as openings, turnovers and contract awards, with any that are at risk.
Illustrative one-page capital program dashboard Mock board dashboard for a 12-project program: approved budget 180.0 million, forecast 186.4 million, spent 92.1 million, contingency left 7.2 million. Status: 7 green, 3 amber, 2 red. This fiscal year forecast spend 64.5 million against a 70.0 million capital budget. Three exceptions are listed with the issue and the board decision needed. A one-page board dashboard Approved budget $180.0M Forecast $186.4M +$6.4M vs approved Spent to date $92.1M 51% of approved Contingency left $7.2M Program level Status, 12 projects 7 green 7 green 3 amber 3 amber 2 red 2 red This fiscal year: forecast vs capital budget Forecast spend this year: $64.5M Forecast $64.5M Approved capital budget this year: $70.0M Budget $70.0M Exceptions requiring attention Project Status Issue Board ask Site 07 renovation Red Forecast $2.1M over funding Approve funding or descope Site 11 new build Red Opening at risk by 6 weeks Accept date or accelerate Site 03 fit-out Amber, new Switchgear delivery late None: recovery plan
One page: totals, status mix, the year's cash against budget, and only the exceptions, each with a decision. Figures are illustrative, not from a real program. Diagram by Benjamin R. Consulting.
View the data
ProjectStatusIssueBoard ask
Site 07 renovationRedForecast $2.1M over fundingApprove funding or descope
Site 11 new buildRedOpening at risk by 6 weeksAccept date or accelerate
Site 03 fit-outAmber, newSwitchgear delivery lateNone: recovery plan

What doesn't belong: percent complete for every project, manpower charts, RFI counts, photo pages and long narrative. Those belong in project reports. If a director wants them, they're one click away.

RAG status rules that mean something

Red, amber and green status is only useful if everyone uses the same rules. Without rules, status becomes a negotiation. Project managers report green until they can't hide it any more, and then the project jumps straight to red.

The UK's major projects reporting is a useful reference. Its delivery confidence assessment rates each project on the likelihood of successful delivery on time, budget and quality. Its annual report defines green as delivery appearing highly likely, amber as delivery appearing feasible but with significant issues needing management attention, and red as successful delivery appearing unachievable without re-scoping or reassessment. The UK moved from a five-point scale to these three ratings in June 2021, dropping the in-between amber/green and amber/red ratings.

A word of caution from the same report. At the end of March 2025, 63% of the 213 projects in the UK government's major projects portfolio were rated amber. When most of a portfolio sits in amber, the rating stops helping a board decide where to look. That's an argument for rules tied to specific thresholds and to the board's own authority, not just to confidence.

A practical rule set for a private or institutional owner ties each colour to what has to happen next:

  • Green: forecast within approved budget and key dates held. Report only.
  • Amber: outside tolerance but within management's authority to fix, using contingency, float or approved delegations. Management reports the recovery plan.
  • Red: forecast outside what management can approve, such as funding above the approved amount, a committed date that will be missed, or a scope change beyond delegated authority. The board needs to make a decision.
RAG status rules tied to delegated authority Table of status rules. Green: forecast within budget, key dates held, scope as approved, risk within contingency; report only. Amber: over budget but covered by contingency, slip with recovery plan, change within delegated authority, exposure close to contingency; management reports a recovery plan. Red: forecast exceeds approved funding, committed date will be missed, change beyond delegated authority, exposure exceeds contingency; board decision required. Status rules that trigger action Green Amber Red Cost Forecast within approved budget Over budget, covered by contingency Forecast exceeds approved funding Schedule Key dates held Slip with a credible recovery plan Committed date will be missed Scope As approved Change within delegated authority Change beyond delegated authority Risk Exposure within contingency Exposure close to contingency left Exposure exceeds contingency left Action Report only Management reports recovery plan Board decision required
Red is reserved for issues outside management's authority, so every red item arrives with a decision attached. Example rules to adapt to your delegations. Diagram by Benjamin R. Consulting.
View the data
AreaGreenAmberRed
CostForecast within approved budgetOver budget, covered by contingencyForecast exceeds approved funding
ScheduleKey dates heldSlip with a credible recovery planCommitted date will be missed
ScopeAs approvedChange within delegated authorityChange beyond delegated authority
RiskExposure within contingencyExposure close to contingency leftExposure exceeds contingency left
ActionReport onlyManagement reports recovery planBoard decision required

Tying red to delegated authority does two things. It makes red rare enough to matter. And it means every red item arrives with a decision attached, which is what boards are for. Our guide to construction project KPIs covers the project-level indicators that feed these ratings.

Exception reporting

Exception reporting means the board only sees detail on projects that have breached tolerance. Everything else is summarized. It respects directors' time and focuses attention where it's needed.

A good exception page for a red or newly amber project answers five questions:

  • What changed since the last report, in cost, schedule, scope or risk?
  • Why, and was it avoidable? GAO's guide notes the value of separating avoidable overruns from ones that were truly unforeseen. Boards should hold management to account for the first kind and adjust expectations for the second.
  • What are the options, with the cost and schedule effect of each?
  • What does management recommend?
  • What decision is the board being asked to make, and by when?

If an exception page doesn't end with a decision or a clear statement that none is needed, it's a status update, not an exception.

Portfolio views that help

Beyond the one-page summary, a few portfolio views are worth having in the board pack or the online dashboard:

  • Status trend. Each project's status over the last several reports. A project that has been amber for six months is a different conversation from one that just turned amber.
  • Forecast trend. Total program forecast against approved budget over time. A steady upward creep is often more telling than any single project.
  • By stage. Projects grouped by phase, such as planning, design, procurement, construction and closeout. Risk sits in different places at each stage.
  • Cash flow. Portfolio spend by quarter against the capital plan. Our guide to construction cash flow S-curves explains how project curves roll up into this view.
  • Contingency. Contingency remaining across the program compared with quantified risk exposure.

Who prepares it, and how often

The dashboard should be prepared by someone who isn't running any of the projects on it. That's usually a program controls lead, a capital planning function or an owner's representative. Their job is to collect the data, apply the status rules the same way to every project, and challenge any rating that doesn't match the numbers. Project managers should review their own entries before the pack goes out, but they shouldn't set their own colours.

Frequency should follow the board's calendar, not the project's. Many boards meet quarterly, with a capital or audit committee meeting more often. A sensible pattern is a monthly dashboard to the executive team and a quarterly version to the board, built from the same data so the numbers never disagree. Red items shouldn't wait for the next scheduled meeting. If a project crosses the board's authority between meetings, the chair or committee should hear about it within days.

Keep a cut-off date and state it on the page. Directors should know whether they're looking at last month's forecast or last quarter's. And keep every past dashboard. The trend in a program's forecast over two years tells a board more about the reliability of its estimates than any single report.

Common failures

  • Green on the outside, red inside. Status set by the project team with no independent check. The owner's rep or project controls lead should validate status against the rules every period.
  • Too many measures. A dashboard with forty indicators gets read like a phone book.
  • No baseline. If forecasts are compared only with last month, slow drift is invisible. Always compare with the approved baseline as well.
  • Inconsistent data. Each project reporting in its own format and cost structure. Program dashboards depend on a common structure underneath. Our guide to the construction cost breakdown structure covers how to set that up.
  • Reports that arrive too late. A board pack built from data that's six weeks old describes problems that have already grown.

What owners should do

  1. Agree the one-page format with the board or its capital committee, and keep it the same every period.
  2. Write RAG rules down, tied to tolerances and delegated authority, and have them approved before the program starts.
  3. Validate status independently each period rather than accepting self-reported colours.
  4. Use exception pages that end with options, a recommendation and a decision request.
  5. Standardize the data underneath, including cost codes, schedule milestones and reporting dates, so the portfolio view adds up.

The bottom line

A board dashboard is a governance tool, not a project report. It should show the program on one page, apply status rules that everyone understands, bring only the exceptions forward, and make clear what the board needs to decide. Get that right and board meetings spend their time on decisions instead of decoding reports.

Want help designing a capital program dashboard or RAG rules for your board? Book a 30-minute call with Benjamin R. Consulting.

Sources: U.S. GAO, Executive Guide: Leading Practices in Capital Decision-Making (GAO/AIMD-99-32, 1998); GOV.UK, NISTA Annual Report 2024-25 (UK major projects portfolio). The dashboard and RAG rules shown are illustrative. This article is general information, not legal advice.

← All insights

Have a program that's slipping, or about to start?

Book a 30-minute call. We'll tell you where your schedule and budget are exposed, and what an owner's rep would change, before you commit to anything.