The Portfolio Dashboard
Executives Actually Open.

After building portfolio reporting tools in Power BI, SAP Analytics Cloud, and Tableau across different organisations and several years, I have watched enough steering committees to be confident about one thing: the dashboards that leadership actually opens before a meeting are not the most technically impressive ones. They are the ones that answer three specific questions, and nothing else.

The sophistication trap.

The typical lifecycle of a portfolio dashboard in a large organisation goes like this. A data or BI team builds an initial version that covers the basics: project status, budget variance, milestone tracking. Leadership uses it for a cycle or two. Then someone, usually with good intentions, decides the dashboard needs to be more comprehensive. More drill-down capability is added. More KPIs are included. A secondary view for dependency mapping is built. An executive summary tab is added on top. The dashboard grows.

At some point, the dashboard stops being used before governance meetings and starts being used only by the people who built it. Leadership has not rejected it; they have quietly found it easier to call the PMO lead and ask for a verbal update. The information is in the dashboard, but getting to it requires effort and interpretation that leadership does not want to supply. The dashboard has become a data warehouse with a front end, rather than a decision support tool.

The irony is that the most sophisticated dashboards are often the ones that get the least use at the governance level. Sophistication is not the same as usefulness. A dashboard that answers one question clearly and instantly is more valuable in a ten-minute pre-meeting review than a dashboard that can answer one hundred questions if you spend thirty minutes with it.

The three questions.

In my experience, three questions reliably come up in every portfolio governance meeting, regardless of the organisation or the specific portfolio. Building a dashboard around these three questions, literally structuring the views to answer them in order, produces the tool that leadership uses.

What is at risk of missing commitments we have made externally? Not all project risk is equally important. Leadership cares most about risk that threatens commitments they have made to the board, to regulators, to customers, or to other parts of the organisation. A dashboard that surfaces this kind of risk explicitly, flagging projects whose delays or failures would cascade into external commitments, is answering the question that is actually in the room, not just showing which projects are amber.

Is the budget going where we decided to put it? This is not the same question as "are we over or under budget?" The more useful version asks: are we spending in proportion to our stated strategic priorities? A portfolio that is overspending on maintenance and underspending on transformation is providing a governance signal that no project-level budget variance report captures. The dashboard view that compares actual spend allocation against strategic priority buckets, even roughly, is the one that generates the most useful governance conversations.

What do we need to decide before the next meeting? This is the hardest view to build because it requires human synthesis, not just data. But a well-designed dashboard can support it by surfacing: decisions that are currently unresolved and time-sensitive, projects that are waiting on a commitment that has not been made, and escalations that are approaching a decision threshold. The PMO needs to curate this view, it cannot be fully automated, but the dashboard provides the data scaffold that makes the curation manageable.

Design principles.

The design principles that follow from this are simple, but they run counter to most BI team instincts. Answer first, data behind: the top of every view should show the answer, not the data that leads to the answer. If there are three projects at risk of missing external commitments, show three project names and the specific commitments at risk, not a table of all projects and their RAG status from which leadership must infer the answer themselves. Drill-down is for people who want to verify the answer, not for people who need to find it.

Minimise the number of views: one view per question, with a drill-down layer if needed. No decorative charts. No views that exist because someone thought the data was interesting. Every element on every view should answer one of the three questions or support someone who is verifying an answer.

Make the time dimension explicit: governance decisions are made in a specific time context. A dashboard that shows current state without surfacing trajectory, whether things are getting better or worse, is missing the most important information for a decision-maker. Trend indicators, cycle-over-cycle comparisons, and forward projections should be visible on the main views, not hidden behind filters.

How to know if your dashboard is working.

There is one reliable test: track how many questions in your governance meeting were answered by the dashboard before anyone asked them. If the answer is most of them, the dashboard is working. If leadership is regularly asking questions that require the PMO lead to dig into a report or make a call to a project manager, the dashboard is not working, regardless of how impressive it looks.

A secondary test is simpler: ask two or three leadership stakeholders what they do with the dashboard in the twenty minutes before a steering meeting. If the answer is "I open it and spend five minutes reviewing the three key views," it is working. If the answer is "I ask my EA to pull a summary," it is not, even if the capability is there. The usability gap is the same problem as the sophistication trap, just seen from the other end.

The tool matters less than people think. Power BI, SAP Analytics Cloud, Tableau: all are capable of building a dashboard that works by these principles. The question is not which tool to use. It is whether the team building the dashboard has spent more time with the governance stakeholders understanding how they use information than they have spent with the data team understanding what information is available. In most organisations, the ratio is the wrong way round.