A portfolio dashboard has one job: let a leader look at every project at once and know, in seconds, which ones need attention. Most fail at that job. They cram in thirty metrics, refresh once a month by hand, and end up as a slide nobody trusts. The dashboards that work are ruthless about what they leave off. This guide covers what actually belongs on a project portfolio dashboard, shows an example layout, and walks through building one in Excel or Power BI without turning it into a second full-time job.
Key takeaways
- A project portfolio dashboard is one view of all active projects, showing status, budget, schedule, risk, and resource load so leaders can decide what needs attention without reading every status report.
- Start from the decisions the dashboard supports, not the metrics you can collect. If a number will not change a decision, leave it off.
- Five to seven columns cover most portfolios: project, owner, RAG status, percent complete, budget variance, key risk, and next milestone.
- Lead with the portfolio-level rollup (how many projects are red, total spend vs budget), then let the reader drill into the project list.
- Build it in Excel for a portfolio under about a dozen projects; move to Power BI or a PPM tool when manual updates start eating half a day.
What is a project portfolio dashboard?
A project portfolio dashboard is a single visual view of every active project in a portfolio, showing each project's status, schedule, budget, risk, and resource demand side by side. Its purpose is not to report on any one project in detail; it is to let a PMO or leadership team scan the whole portfolio and see immediately which projects are on track, which are slipping, and which need a decision this week.
The difference between a portfolio dashboard and a project dashboard matters. A project dashboard drills deep into one project's tasks, milestones, and burndown. A portfolio dashboard stays shallow on purpose: one row per project, a handful of columns, and a rollup at the top. You are trading depth for breadth, because the person reading it is deciding where to spend attention across twenty projects, not managing one.
What should a project portfolio dashboard include?
Start from the decisions the dashboard has to support, then work backward to the metrics. A useful portfolio dashboard answers four questions: Are we on track overall? Which projects are in trouble? Are we within budget? Do we have the people to deliver what is left? Everything on the dashboard should serve one of those questions, and anything that does not gets cut.
For most portfolios, the core project table needs five to seven columns. Here is a practical set with what each column is for.
| Element | What it shows | Why it earns a place |
|---|---|---|
| Project name and owner | What it is and who is accountable | Every red status needs a name to chase, not a project code |
| RAG status | Red, amber, or green health at a glance | The single most-scanned field; drives where attention goes |
| Percent complete | Progress against plan | A project at 20 percent complete and 80 percent through its timeline is a problem the RAG may not yet show |
| Budget vs actual | Committed and actual spend against the approved number | The earliest reliable signal of trouble, often before the schedule slips |
| Key risk or blocker | The one issue most likely to derail it | Turns a red status into something a leader can act on |
| Next milestone and date | The next commitment and when it is due | Makes slippage visible before it becomes a surprise |
| Resource load | Whether the project is adequately staffed | Explains most schedule variances the other columns cannot |
Swipe to see more →
Above that table sits the portfolio rollup: total active projects, the count that are red or amber, total budget vs total spend, and overall resource utilization. That rollup is what a busy executive reads first. The project table is the drill-down for when a number in the rollup looks wrong. Keep the whole thing to one screen. If a reader has to scroll to find the red projects, the dashboard has already failed its five-second test.
Resist the urge to add a column for every stakeholder request. The fastest way to kill a dashboard is to make it comprehensive. A dashboard that shows the seven things that drive decisions beats one that shows forty things nobody reads, and it beats it every review.
The metrics that belong on a portfolio dashboard
Pick three to five headline metrics for the rollup and stop there. The metrics that consistently earn their place track health, money, and delivery. Below are the ones worth showing, and roughly how to read each.
| Metric | What it tells you | Watch for |
|---|---|---|
| RAG status distribution | How many projects are red, amber, green | A rising amber count is the early warning; do not wait for red |
| Budget variance | Total actual and committed spend vs approved budget | Committed cost, not just paid invoices, or you see overruns too late |
| Schedule variance | Whether projects are ahead of or behind plan | Percent complete far below percent of timeline elapsed |
| Resource utilization | How loaded key roles and teams are | Sustained utilization over roughly 85 percent means no slack for slippage |
| Benefit or strategic alignment | Whether the portfolio is funding the right work | Too much spend on low-alignment projects |
Swipe to see more →
If your organization runs formal earned value management, the schedule performance index (SPI) and cost performance index (CPI) belong in the rollup too, since one number each captures schedule and cost health. The health column itself follows the RAG status convention, and it is worth writing the criteria down so the color is calculated rather than negotiated. Most portfolios do not need that rigor, and a plain budget-variance column plus a percent-complete-vs-timeline check tells the same story with far less bookkeeping. Match the metric to the maturity you actually have. These headline numbers are the visible tip of a wider set; the full measurement layer sits in your portfolio KPIs and metrics.
Example project portfolio dashboard layout
A clean layout has three bands stacked top to bottom. The top band is the rollup: four or five big numbers, or simple tiles, that give the whole portfolio in one glance ("14 active projects, 3 red, spend 92% of budget, key roles at 88% utilization"). The middle band is the project table, one row per project, sorted so the red and amber projects float to the top. The bottom band is optional context: a spend-by-quarter bar, a projects-by-strategic-theme split, or an upcoming-milestones strip.
Color does most of the work. Use red, amber, and green consistently and sparingly, and reserve strong color for the status column so the eye lands there first. Everything else stays neutral. A dashboard where six columns are color-coded has no signal left, because when everything is highlighted, nothing is. One well-placed red cell in an otherwise calm table is worth more than a rainbow.
Sort matters more than people expect. If the table is sorted alphabetically, the reader has to scan every row to find trouble. Sort by status, worst first, and the projects that need a decision are always in the top three rows. The dashboard should put the problems in front of the reader, not make the reader hunt for them.
Which visual each portfolio metric actually needs
Most portfolio dashboards are hard to read because the chart type fights the question. Status is categorical, so it wants color and count. Budget variance is a comparison against a fixed reference, so it wants a bar against a line. Trend questions want time on the horizontal axis. Getting this right removes more confusion than adding any metric.
The rule underneath the table below is simple: pick the visual that makes the wrong answer look wrong. If a project running 40 percent over budget does not visibly stand out from one running 4 percent over, the chart has failed regardless of how accurate the number is.
| Metric | The visual that works | Why | The common wrong choice |
|---|---|---|---|
| RAG status across the portfolio | A stacked count bar, or colored cells in the project table | The reader wants the count of reds and which ones, both answered in one glance | A pie chart, which hides small red counts and gives no project names |
| Budget vs actual per project | A horizontal bar with a reference line at the approved figure | Overrun becomes a length past a line, readable without any arithmetic | Two columns of numbers, which force the reader to subtract twenty times |
| Portfolio spend over time | A cumulative line against the planned curve | Divergence between two lines shows up months before a total does | Monthly bars, which hide a steady drift because each month looks fine |
| Schedule progress vs elapsed time | Two bars per project, or a scatter of percent complete against percent elapsed | The gap between the two is the actual signal, and it needs to be visible as a gap | Percent complete alone, which looks healthy right up until the deadline |
| Resource load by team | A bar per team with a capacity line across it | Over-allocation is only meaningful relative to capacity, so the capacity must be drawn | A utilization percentage, which flattens a team at 180 percent into a single cell |
| Portfolio mix by category | A single stacked bar, current against target | Mix is a proportion question, and the target is the only thing that makes it actionable | A donut with no target, which shows a split nobody can judge |
| Milestones due | A dated list, sorted soonest first | There is no visual that beats a short sorted list for "what is due next" | A full timeline chart, which spends most of the screen on dates nobody is deciding about |
Swipe to see more →
One deliberate omission from that list: nothing on it is a gauge or a speedometer. Gauges use a large amount of screen to display one number without context, and portfolio questions are almost always comparisons. A number that needs no comparison is better as text.
What belongs on the first screen, and what belongs one click down
The first screen answers "does anything need me this week?" Everything else is drill-down. That means the top of the dashboard carries the portfolio rollup and the exceptions, and the detail that explains an exception sits one layer below, reachable but not competing for attention.
This is the discipline that keeps a dashboard to one screen as the portfolio grows. The instinct when a new question arrives is to add a panel. The better move is to decide which layer the question belongs to, because a dashboard with three well-ordered layers stays readable at forty projects while a flat one stops working at fifteen.
| Layer | What it holds | The question it answers | Who reads it |
|---|---|---|---|
| 1. Rollup, top of screen | Active project count, red and amber counts, total budget vs spend, overall resource load | Is the portfolio healthy overall? | Executives, in under ten seconds |
| 2. Exceptions, immediately below | Only the red and amber projects, worst first, with owner and the one blocker | What needs a decision this week? | The portfolio review, as its opening agenda item |
| 3. Full project list | Every active project, one row each, sortable | Where does a specific project stand? | The PMO, and anyone looking for their own work |
| 4. Project drill-down | Milestones, risks, spend detail for one project | Why is this project red? | Whoever has been asked to explain it |
| 5. Source data | The underlying export, with dates and owners | Where did this number come from? | Anyone disputing a figure, which happens more than people admit |
Swipe to see more →
Layer five is the one teams skip, and it is worth building even when it is just a link to a spreadsheet. The fastest way for a dashboard to lose its authority is for a project owner to say the number is wrong in a meeting and for nobody to be able to check within the meeting. Being able to open the source in twenty seconds ends that conversation instead of scheduling another one.
How fresh each number on the dashboard can honestly be
Different numbers on the same screen refresh at genuinely different speeds, and pretending otherwise is what makes dashboards untrustworthy. Actual spend is only as current as the last finance close. RAG status is as current as the last time a project manager updated it. Putting both under a single "updated today" banner tells the reader something false.
The fix costs almost nothing: label each block with when its source last changed rather than when the page was generated. A reader who knows the spend figure is three weeks old can still use it. A reader who assumes it is current and later discovers it was not stops trusting the whole screen, including the parts that were accurate.
| Number | Realistic refresh | What limits it | How to label it |
|---|---|---|---|
| RAG status | Weekly | Someone has to make a judgment and record it | Date of the last status submission, per project |
| Actual spend | Monthly | The finance close, which no dashboard can outrun | The close period the figure covers, not today's date |
| Committed spend | Daily or weekly | Purchase order data, usually available faster than actuals | Flag clearly that it is commitment, not spend, or the two get added together |
| Percent complete | Weekly at best | It is an estimate, and re-estimating more often does not make it truer | Show it alongside percent of schedule elapsed so the reader can judge it |
| Resource allocation | Weekly | Assignment changes are recorded late almost everywhere | Say whether it reflects the plan or confirmed availability |
| Milestone dates | On change | Nothing, technically. In practice, whether anyone updates the baseline. | Show the current date and the original, so slippage is visible rather than silent |
Swipe to see more →
Two traps follow from this table. The first is building a daily-refreshing dashboard on top of a monthly number, which produces a screen that looks live and is not. The second is the opposite: throttling the whole dashboard to the slowest input, so a status change made on Monday is invisible until the close. Refresh each block at its own natural speed and label them separately. The wider question of when the underlying numbers get closed and published belongs to the reporting cycle behind the screen.
One screen cannot serve every audience
The most common cause of dashboard bloat is three audiences with different questions being served by one view. An executive wants exceptions. A PMO wants the full list and the data behind it. A delivery lead wants their own projects and the resource picture. Trying to satisfy all three on one screen produces something that satisfies none of them.
The answer is usually not three dashboards, which triples the maintenance and guarantees the numbers diverge. It is one data set with different default views, so everyone is looking at the same figures filtered differently.
| Audience | The question they arrive with | Default view | What to leave out |
|---|---|---|---|
| Executive sponsor or steering group | What needs a decision, and is the money holding? | Rollup plus exceptions only | The full project list, percent complete, anything with no decision attached |
| PMO | What is missing, late, or inconsistent? | Full list, sorted by data age and status | Nothing. This audience needs the source layer. |
| Delivery or functional lead | Where are my projects and my people committed? | Filtered to their projects, with resource load | Portfolio-wide financials that are not theirs to act on |
| Finance | Is committed spend tracking against the approved budget? | Budget, commitment and actuals by project and cost center | RAG status and milestones, which invite a delivery conversation |
Swipe to see more →
Build the executive view first and hold it to the rollup and the exceptions. It is the hardest one to keep clean, because it is the view every stakeholder wants their own metric added to, and each addition is individually reasonable. The defense is to ask what decision the new metric changes, and where the answer is "none, but it is good to know", it belongs in a lower layer. That question is easiest to settle in the forum that actually uses the screen, which is why the dashboard and the meeting where leaders work through the exceptions should be designed together rather than separately.
How to build a project portfolio dashboard in Excel
For a portfolio under roughly a dozen projects, Excel or Google Sheets is genuinely the right tool. Build it in three tabs. The first is a data tab: one row per project with columns for name, owner, status, percent complete, budget, actual spend, next milestone, and a key-risk note. Everyone updates this tab, and only this tab. The second is the dashboard tab, which reads from the data tab and never gets typed into directly. The third is a lookup tab for the RAG rules and any drop-down lists, so status is picked from a list rather than typed freehand.
If you would rather start from a working file than a blank grid, our project portfolio management template is that register and dashboard already built, with the SUMIF and COUNTIF formulas live. This page covers what to put on a dashboard and why; that one hands you the spreadsheet.
On the dashboard tab, use conditional formatting to color the status cells automatically from the data, a few COUNTIF or SUMIF formulas to build the rollup tiles (count of red projects, total budget vs total actual), and a sort on the project table so red rises to the top. Keep formulas simple and visible; a dashboard that only one person understands is a dashboard that breaks the week they are on vacation. If you already keep a resource model, the utilization figure can come straight from your capacity planning template rather than being maintained twice.
How to build one in Power BI or a PPM tool
Move beyond Excel when one of three things happens: manual updates start eating half a day each cycle, the single file forks into competing versions, or you need the dashboard to refresh itself from the systems where the data already lives. Getting there means turning scattered project files into structured, comparable records first, the shift from project documents to portfolio data. Power BI connects to your project, finance, and resource sources and rebuilds the same three bands, rollup, project table, context charts, on a schedule, so the numbers are current without anyone retyping them. That automatic refresh is the real upgrade; the visuals are not much better than a well-built spreadsheet, but the trust that comes from live data is.
A dedicated PPM tool goes further, generating the portfolio dashboard from the same database that runs intake, prioritization, and capacity, so status, spend, and resource load are never out of sync. The tradeoff is cost and setup, and it is only worth it once the portfolio is large enough that keeping several spreadsheets aligned has become the bottleneck. We cover when to make that jump in our guide to PPM software and tools. Whatever tool you land on, the dashboard is only half the job; how you present and narrate it in the review is covered in PMO reporting and portfolio dashboards.
Frequently asked questions
What does a project portfolio dashboard show?
A project portfolio dashboard is a single view of every active project in a portfolio, showing each project's status, schedule, budget, risk, and resource load side by side. Its purpose is to let leaders scan the whole portfolio and see which projects are on track and which need a decision, without reading a separate status report for each one. It stays shallow on every project so it can stay broad across all of them.
Which metrics belong on a project portfolio dashboard?
Include a portfolio rollup at the top (active project count, how many are red or amber, total budget vs spend, resource utilization) and a project table below it with five to seven columns: project and owner, RAG status, percent complete, budget vs actual, key risk, and next milestone. Start from the decisions the dashboard supports and leave off any metric that will not change a decision.
What metrics should be on a portfolio dashboard?
Pick three to five headline metrics: RAG status distribution, budget variance against approved spend, schedule variance or percent complete versus timeline elapsed, and resource utilization of key roles. Portfolios running earned value can add schedule performance index (SPI) and cost performance index (CPI). More than five headline metrics dilutes the signal, so leave off anything that does not drive a decision.
How do you create a project portfolio dashboard in Excel?
Build three tabs: a data tab with one row per project (name, owner, status, percent complete, budget, actual, next milestone, key risk), a dashboard tab that reads from it, and a lookup tab for RAG rules and drop-downs. Use conditional formatting to color status cells automatically, COUNTIF and SUMIF formulas for the rollup tiles, and sort the project table by status so red projects appear first. Never type directly into the dashboard tab.
What is the difference between a project dashboard and a portfolio dashboard?
A project dashboard drills deep into one project's tasks, milestones, and progress, and is used by the team delivering it. A portfolio dashboard stays shallow on every project, one row each, so leaders can compare all active projects and decide where to spend attention. The portfolio view trades depth for breadth, because its reader is allocating focus across many projects rather than managing one.