KPI dashboard examples for project teams: fewer numbers, read more often

Search for KPI dashboard examples and the galleries deliver: fifty industry templates, eighteen screenshots of business intelligence reports, a wall of gauges and donut charts in corporate blue. Most of them are finance or sales dashboards, built on a warehouse, maintained by an analyst, and read by an executive once a month. They look convincing. Almost none of them describe a dashboard a team of eight can keep accurate while also delivering the work.

A project team's dashboard has a different job. It is not there to summarise a quarter for someone who was not in the room. It is there to answer, on a Monday, whether anything has quietly gone wrong since Friday. That changes the number of tiles, the refresh rate, the choice of chart, and who is expected to look at it. The examples below are described by the question each one answers rather than by the industry it belongs to, because the question is what determines the layout.

Why most published examples do not transfer

Three things separate a business intelligence gallery screenshot from a dashboard a delivery team will still be using in three months.

They assume a data pipeline exists. A Power BI or Tableau example implies a modelled dataset behind it. A team of eight running client projects usually has boards, a calendar, a chat history and a spreadsheet. Numbers have to be counted off those surfaces, not queried.

They are sized for a monthly audience. Twenty tiles works when someone reads it once a month and has thirty minutes. The same twenty tiles in a fifteen minute weekly review means nineteen of them are never mentioned, and the ones nobody mentions are the ones that go stale first.

They measure outcomes the team cannot move this week. Revenue, margin, customer acquisition cost and net promoter score are real, but a delivery team watching them learns nothing actionable on a weekly cadence. The team needs the things upstream of those outcomes.

There is a quieter problem too. A gallery example is a screenshot, which means every figure in it is plausible and none of it had to survive a Tuesday when the person who normally runs the export was on leave. The interesting part of a dashboard is never the layout. It is the collection method behind each tile, and screenshots do not show that.

Four dashboards worth copying

These four cover most of what a project team actually needs. Very few teams need all four at once.

The date dashboard

The question is whether the commitments the team has made are still achievable. Four tiles carry it: items open past their due date, items due in the next seven days, items with no date at all, and the count of dates that were moved this week. The last of those is the one most teams leave out, and it is the most informative, because a schedule that holds only because dates keep sliding looks healthy on every other tile.

A Gantt or timeline view is the natural companion here, not as a tile but as the thing you open when a number looks wrong. The dashboard says something is late. The timeline says what it blocks.

The flow dashboard

The question is where work is getting stuck. Tiles: count of items in each column, oldest item in each column, items that have not moved in five days, and items reopened after being marked done. Column counts alone are close to useless. The age of the oldest item in a column is what makes a bottleneck visible, because a review column with six items that all arrived yesterday is fine and a review column with two items from last month is not.

This is the dashboard most worth having if the team already runs a board, because every tile on it can be read off the board itself without an export.

The commitment dashboard

The question is what the client or the sponsor was promised and whether it happened. Tiles: updates promised against updates sent, deliverables accepted this period, open questions waiting on the client, and open questions waiting on the team. Splitting the last two matters more than it looks. A project that appears stalled is often stalled on the other side, and a single blocked count hides that.

The capacity dashboard

The question is whether the team is taking on more than it can finish. Tiles: items started but not finished at week end, number of people with more than three items in progress, and items added to the current cycle after it started. Hours are deliberately absent. Logged hours answer a billing question, not a capacity question, and mixing the two makes both harder to read.

Dashboard	Question it answers	Audience	Read it
Date	Are the commitments still achievable	Team and sponsor	Weekly
Flow	Where is work stuck	Team only	Weekly, or daily in a standup
Commitment	Did the promised things happen	Client or sponsor	Fortnightly or monthly
Capacity	Is the team overloaded	Team lead	Weekly

The temptation is to merge all four into one screen. That produces fourteen tiles, a fifteen minute review that covers four of them, and ten numbers that rot. Separate screens with separate audiences and separate cadences stay accurate for longer.

The tiles worth using and the ones to drop

Dashboard design advice tends to be about visual hierarchy. The more useful distinction is between a tile that changes a decision and a tile that decorates.

Worth keeping. A single large count with last period's figure beside it. A count broken down by one dimension, as a plain bar. Age of the oldest item in a queue. A list of the five items that triggered a red number, so the reader can act without going hunting. That last one is the difference between a dashboard and a report.

Usually not worth keeping. Donut charts of two or three categories, where a sentence would carry the same information. Gauges with arbitrary red and amber bands. Percentage complete on anything a human estimates. Sparklines on a series with six data points. Any tile whose number has never once been discussed.

A useful rule on colour: a tile may only be red if the rule that made it red is written next to it and somebody is expected to say something about it. Colour applied for emphasis rather than for a threshold trains readers to ignore colour, which is expensive, because the one tile that genuinely needs attention then looks the same as the rest.

Where the numbers should come from

Every tile has a collection method, and the collection method decides whether the dashboard survives. Ranked from most durable to least: read directly off a board or a filtered view, pulled through an API on a schedule, exported and pasted weekly, typed in from memory. The last of those is where most abandoned dashboards die.

This is why it is worth checking what the team's existing tools can count without an export. Boards, dates and the discussion sitting in one place means a flow dashboard is a set of saved filters rather than a data project, and the counts can be pulled on a schedule or asked for directly through an API or an assistant. The features list of whatever tool the team already uses is the right place to start, before anyone builds a spreadsheet.

When two tiles disagree

The most useful thing a dashboard does is contradict itself, and this is the case the gallery screenshots never show. A date dashboard says nothing is overdue. A flow dashboard says the oldest item in the review column has been there eleven days. Both numbers are correct. Together they say the team is keeping dates by moving them, or that review work is not being given a date at all.

A few of these pairings come up often enough to watch for.

Nothing overdue, but dates moved this week is high. The schedule is being maintained by rescheduling. Worth naming openly, because it is sometimes the right call and sometimes a slow slide nobody has decided to have a conversation about.

Throughput looks healthy, but items reopened after being marked done is climbing. Work is being closed before it is finished. The count of closures is the easiest number to improve and the easiest to game, which is why it should never sit on a dashboard without a quality count next to it.

Capacity looks fine, but one person has six items in progress. An average across the team hides the individual who is the actual constraint. This is the argument for showing a count of people above a threshold rather than a mean.

The habit worth building is to read the tiles as a set rather than one at a time, and to treat a disagreement as the most valuable reading on the screen rather than as a data problem to be reconciled.

Refresh rate, and the part nobody designs

A dashboard that updates continuously and is never read is worth less than four numbers read aloud on a Monday. The reading is the mechanism. The screen is just where the numbers are kept.

The pattern that holds up is a fixed slot each week, short, with a named owner for each tile who says the number and last week's number out loud. Two things happen that a screen alone cannot do. A stale figure becomes audible, because the owner has to admit it has not moved since the twelfth. And a number gets a person attached to it, which is what turns a reading into a decision.

Automated refresh is worth having, with one caveat. Automated dashboards drift silently. A field gets renamed, a filter stops matching, a board is archived, and the tile keeps showing a number that is now measuring something else. The cheap defence is to keep the human check at the review: the owner is expected to say whether the figure looks plausible, not just to read it. Teams that automate collection and remove the person are the ones who discover six weeks later that a tile has been reading zero because a column was renamed.

One more piece of the design that usually goes unwritten: what happens to a tile that has been red for a month with no decision recorded. Either the team acts on it, or the tile comes off the dashboard. Leaving it in place teaches everyone that the dashboard does not drive anything, and that lesson spreads to the tiles that were working.

What to change first

Pick the one question the team is actually arguing about, build only that dashboard, and hold it to four or five tiles that can each be read off a board without an export. Put a name and last week's figure against each tile, and book a fifteen minute slot to read them out loud. If the counts currently live in three separate applications, consolidating the boards and the discussion is the change that makes the dashboard survive, and Pinateca is free for up to five people and ten boards while the shape of the dashboard is still being settled.

Q1. How many tiles should a KPI dashboard have?

Four to six for a team dashboard read weekly. The constraint is the review, not the screen: a fifteen minute slot with a named owner per tile does not stretch past six. Executive dashboards read monthly can carry more, because the reader has more time and is not also doing the delivery work.

Q2. Can a KPI dashboard be built in a spreadsheet instead of a dedicated tool?

Yes, and for four or five tiles a spreadsheet is often the faster choice. The thing that decides whether it lasts is not the tool but where the numbers come from. If each tile needs its own export from a different system, the weekly collection cost will kill it regardless of how good the spreadsheet looks.

Q3. What is the difference between a KPI dashboard and a project status report?

A dashboard is a standing set of numbers with a fixed refresh, read to spot change. A status report is a narrative written for a particular audience at a particular moment, and it explains why. Teams that try to make one document do both jobs usually end up with a dashboard full of commentary that nobody updates.

Q4. Which KPIs belong on a dashboard for a small project team?

Counts of things the team can change inside a week: items open past their due date, age of the oldest item in a review column, items started but not finished, dates moved this week, and updates promised against updates sent. Revenue and satisfaction scores matter but move too slowly and for too many reasons to be useful weekly.

Q5. How often should a project KPI dashboard be reviewed?

Weekly for a delivery team, with a client facing view on a fortnightly or monthly rhythm. Daily works only for a flow dashboard used in a standup, where the question is what moved since yesterday. Less than monthly and the numbers stop being trusted, because nobody notices when collection has quietly broken.