“Portfolio Dashboard Template: Free Download, Sections and How to Use It”

What is a portfolio dashboard template, and who is it for?

A portfolio dashboard template is a pre-built structure that holds one row per project and one column per decision-relevant metric, with a target, an actual, a trend, a RAG status, and a short commentary field. You copy the master, fill it on a fixed cadence, and it answers three questions in under two minutes: which projects are off track, by how much, and what decision is being asked for.

The audience matters more than the fields. A portfolio dashboard is read by people who do not attend project standups: a sponsor, a finance lead, an operations director, a board. They have thirty seconds, no context, and a budget to protect. If a field does not change what they do in that thirty seconds, it should not be in the template.

That distinguishes it from two neighbours it is constantly confused with. A project dashboard shows one project in depth — tasks, owners, burnup, blockers. A status report is prose with an opinion attached. A portfolio dashboard is a comparison surface: it exists so that nine projects can be judged against each other and against the money committed to them.

The other thing a template buys you is consistency over time. Ad-hoc dashboards drift in definition, so the number that was 62% last month becomes 71% this month because someone changed the denominator. A template with a written formula per column makes that drift visible.

What sections belong in a portfolio dashboard template?

Eight sections cover almost every portfolio, from six projects to sixty. The order below is deliberate: it moves from context, to money, to time, to risk, to the decision the reader has to make.

Two rules make the section list survive contact with reality. First, every section needs a named owner for its data, not just a name in a cell. Second, keep the template to one screen per twelve projects. If it needs a scroll of six screens, the reader will read the first one and assume the rest.

How do you calculate a portfolio health score?

Score five dimensions from 1 to 5, weight them, and let written hard triggers override the result. The weights below are a defensible starting point for a delivery portfolio; change them deliberately, in writing, once per year.

Health = 0.30 × Schedule + 0.25 × Cost + 0.20 × Quality + 0.15 × Risk + 0.10 × Confidence

Schedule and cost scores are derived, not typed in. Use earned value:

• SPI = EV ÷ PV (earned value ÷ planned value)
• CPI = EV ÷ AC (earned value ÷ actual cost)
• EAC = BAC ÷ CPI (forecast at completion)

Map SPI to a score: 1.00 or higher scores 5; 0.95 to 0.99 scores 4; 0.90 to 0.94 scores 3; 0.85 to 0.89 scores 2; below 0.85 scores 1. Use the same bands for CPI. Quality scores on acceptance criteria met and rework rate, risk scores inverse to open high-risk exposure, and confidence is the sponsor’s stated probability that the promised benefit lands.

RAG rules, written once and applied mechanically:

The hard triggers are the important half. They stop a project from averaging its way to green: strong quality and a confident sponsor cannot compensate for a forecast that is already 15% over budget.

Worked example 1: one project, three numbers

A billing migration has BAC $600,000, PV $300,000, EV $270,000, and AC $310,000 at the halfway milestone.

• SPI = 270,000 ÷ 300,000 = 0.90, which scores 3
• CPI = 270,000 ÷ 310,000 = 0.87, which scores 2
• EAC = 600,000 ÷ 0.87 = $689,655, a forecast overrun of $89,655, or 14.9%

Add quality 4, risk 3, confidence 4 and the weighted score is (0.30 × 3) + (0.25 × 2) + (0.20 × 4) + (0.15 × 3) + (0.10 × 4) = 0.90 + 0.50 + 0.80 + 0.45 + 0.40 = 3.05. That is Amber on the number. The forecast overrun of 14.9% trips a hard trigger, so the row is Red. Two different answers, one correct one, and the template should print the reason next to the colour.

Worked example 2: why weighting beats averaging

A three-project portfolio: Alpha, $600k budget, health 3.0; Bravo, $1.0M, health 4.4; Charlie, $2.4M, health 2.0.

• Simple average: (3.0 + 4.4 + 2.0) ÷ 3 = 3.13, which reads Amber
• Budget-weighted: (600 × 3.0 + 1,000 × 4.4 + 2,400 × 2.0) ÷ 4,000 = (1,800 + 4,400 + 4,800) ÷ 4,000 = 2.75, which reads Red

Same three projects, two colours. The weighted figure is the honest one: 60% of the money sits in the worst-performing project. Any rollup cell in the template must state its weighting method or it will be misread.

Worked example 3: capacity load

Fourteen projects plan 4,120 hours across 38 delivery people in a four-week window. Available capacity is 38 × 40 × 4 × 0.75 = 4,560 hours after allowing 25% for meetings, support, and leave.

• Load = 4,120 ÷ 4,560 = 90%, which is healthy at portfolio level
• One team, however, plans 660 hours against 500 available, a load of 132%

Portfolio-level capacity is a comfortable lie. Report load per team, and treat any team above 110% as a schedule risk for every project that depends on it.

What does each metric column actually mean?

Ambiguous column definitions cause more dashboard arguments than missing data. Pin each one.

The percent-complete row deserves a warning. Counting tasks is the easiest method and the most misleading, because ten trivial tasks complete faster than two hard ones. Weight by planned effort or by deliverable value, and state which.

How do you fill it in without losing a day?

Six steps, ninety minutes, same slot every week. The discipline is the product.

1. Freeze the master. Keep one read-only master template and fill a dated copy. Edits to the master are how definitions drift.
2. Fill the header first. Data cut-off date, currency, and reporting period. A number without a date is a rumour.
3. Update the row, not the story. Each project manager submits five numbers and one sentence: forecast finish, forecast cost, percent complete, open high risks, and the decision they need. Cap it at that.
4. Let formulas assign the score. Type SPI, CPI, and progress; let the sheet compute score, EAC, and status. Manual scoring reintroduces optimism.
5. Apply hard triggers before you look at the colour. The trigger column should compute itself and print the reason string beside the RAG cell.
6. Write the ask. Every red row ends with a decision, an owner, and a date. A red row with no ask is a complaint, not a report.

The 90-minute budget splits roughly as 45 minutes collecting and normalising, 25 minutes reviewing triggers and dependency clashes, and 20 minutes writing commentary for the three or four rows that will be discussed. If your portfolio needs more, you have too many rows for the reader, not too much data.

What does a filled example look like?

Four rows from a real-shaped services portfolio, one currency, one data cut-off.

Read the table as a reader would. In eight seconds the message is: two reds, one of them carrying most of the money, and both need a decision this week. That is the entire purpose of the artefact. The commentary column for the data warehouse row should read something like: vendor integration delivered 26 days late, re-baseline moves go-live to 9 February, forecast $2.55M, sponsor decision required by 20 November.

Who should own the dashboard, and how often should it change?

The portfolio manager owns the rollup; each project manager owns their row; the sponsor owns the decisions. Splitting it any other way produces a dashboard that is accurate and ignored.

Change the rules rarely and the data often. A dashboard whose scoring model changes every quarter teaches readers to distrust the colour, and once they distrust the colour they go back to asking people directly.

What are the trade-offs of a heavier dashboard?

Every added column has a cost, and the cost is almost never the column itself. It is the argument about the definition, the hour spent reconciling two systems, and the reader’s attention, which is a fixed budget.

The practical compromise most portfolios land on: hard triggers for status, a health score for ranking, and a two-sentence commentary for the three rows that will actually be discussed. Precision beyond that is usually theatre.

What are the most common mistakes?

Six failures account for most abandoned dashboards.

• Colour without rules. If green means “the manager feels fine”, the dashboard measures optimism.
• Averaging away a red. Simple averages let five small greens mask one large red, as in the worked example above.
• Reporting activity instead of outcome. Tasks closed is not progress; deliverables accepted is.
• No decision column. A portfolio report that never asks for anything trains readers to skim.
• Stale cost data. A CPI computed on month-old actuals is decoration.
• Too many rows. Above roughly fifteen projects on one screen, group by workstream and report exceptions only.

Each fix is small, and each one removes a reason for the reader to stop reading.

Do you need portfolio software, or is a spreadsheet enough?

A spreadsheet is genuinely sufficient when you have fewer than about fifteen projects, one currency, no external readers, and no need to control who sees cost data. It becomes a liability the moment two of those conditions change.

The first breaking point is permissions: sponsors should see their projects, finance should see all costs, and delivery leads should see capacity but not margin. Spreadsheets do that with file copies, and file copies fork. The second is reconciliation: when cost lives in an accounting system and progress lives in a task tool, someone rebuilds the join every week. The third is history: a spreadsheet shows this week, not the trend, so nobody can see that a project has been amber for eleven consecutive weeks.

Software earns its place when the dashboard is a by-product of the work rather than a separate artefact. If tasks, owners, due dates, and time entries already live in one system, the rollup is a view, not a project.

How does Doitify handle portfolio reporting?

Doitify is our product, so read this as disclosure rather than review. It keeps projects, tasks, sub-tasks, owners, and due dates in one workspace, with Kanban, Gantt, roadmap, calendar, and workload views on top of the same data, plus work and performance reports. For a portfolio, that means the health row is assembled from the work itself: progress from completed and accepted tasks, schedule from baseline dates, workload from assigned hours.

The architectural point is the one that matters for this template: when the metric source and the reporting surface are the same system, the weekly rollup stops being a data-collection exercise and becomes a review. That is not an argument for every portfolio. A six-project programme with one currency and no external readers will run perfectly well on a spreadsheet, and should, until permissions or reconciliation force the move.

Conclusion

A portfolio dashboard template is not a colour-coded spreadsheet. It is a set of written rules about what counts as progress, how status is computed, and who decides when a row turns red. Get the rules right and the artefact takes ninety minutes a week; get them wrong and no amount of design will make anyone trust it.

Start with the eight sections, define five metric families properly, and write the hard triggers before the first report goes out. Then weight the rollup by money, not by row count, and make every red row end in a named decision with a date. Those four choices do more for portfolio control than any dashboard tool you can buy.

If this post on portfolio dashboard template was helpful, you might also enjoy Free RACI Matrix Template and What Is a RAID Log? (Risks, Assumptions, Issues, Decisions).