team
The request usually arrives as a small one. Someone wants a dashboard. A single screen with the state of the project on it, so the Thursday meeting can be shorter. What follows is rarely small. Two days go into choosing charts, a week into wiring them up, and then the thing that was supposed to remove the weekly scramble becomes the weekly scramble, because somebody has to chase five people for updates before the numbers mean anything. The dashboard was never the problem. The gap between what the board says and what is actually happening was the problem, and a dashboard makes that gap visible rather than smaller.
Before picking any chart, it is worth finding out which of these was meant, because they cannot be served by one screen.
The status report. An audience outside the team wants to know whether the project will land, and roughly what is in the way. They look at it once a fortnight, for about ninety seconds, and they cannot interpret a burndown chart. This audience needs milestone dates, a direction of travel, and a short list of what is blocked.
The team's working view. The people doing the work want to know what to pick up, what is stuck, and who is drowning. They look at it daily. Trends over months are useless here. What matters is this week, in detail, filtered to them.
The portfolio view. Someone running several projects wants them side by side to decide where to move people. This one needs comparable numbers across projects, which means every project has to be tracked the same way, which is a process question long before it is a tooling question.
Most dashboard projects fail because all three were attempted on one screen. The result serves nobody: too abstract for the team, too detailed for the sponsor, and not comparable enough for the portfolio. Pick the audience first and build only their view. The other two are separate screens, and one of them probably does not need building at all.
The temptation is to show everything the tool can count. Resist it. Four measures cover the ground, and each one has a specific way of lying that is worth knowing before it appears on a wall.
Completion. Tasks done over tasks total. The lie is that tasks are not the same size, so a project can sit at 80 percent for six weeks because the remaining 20 percent is the hard part. Counting by estimated hours instead of by task count helps, if the estimates exist and are not two months stale.
Schedule health. How many items are past their due date, and how far past. This one is honest, and it is the number most often left off because it is uncomfortable. A count of overdue items plus the age of the oldest one tells a reader more than any percentage.
Work in progress and its age. How many items are open, and how long each has been open. Age of work in progress is the earliest honest signal a dashboard can carry, because it starts climbing weeks before a deadline is missed, while completion percentage stays reassuring right up to the end.
Load by person. Open items per assignee, or hours if they are tracked. The lie here is that unassigned work is invisible, so a project with twelve unassigned tasks looks comfortable until somebody has to take them.
What to leave off: velocity trends on a team under six people, because the numbers move too much to read; cost, unless somebody is actually authorised to act on it; and anything that requires a person to type a number into a field that exists only to feed the chart. That last category is where dashboards die.
This is the part that gets skipped, and it is the part that decides the outcome. A dashboard does not gather information. It reads what is already recorded and arranges it. If the record is half accurate, the dashboard converts a vague unease into a confident wrong number, which is worse.
Three conditions have to hold before any chart is worth building.
Every piece of work exists as an item. Not in a chat thread, not in somebody's notebook, not as an agreement reached verbally in a meeting. Work discussed in chat and never turned into a card is invisible to every dashboard ever built, and in most teams that category is large.
State changes happen as a side effect of working, not as a separate chore. If a developer has to remember to open a tool and move a card after finishing something, the board lags reality by days, and the lag is worst exactly when the team is busiest. Boards where moving the card is how work gets handed to the next person stay current, because skipping it stops the work.
Dates mean one thing. A due date that sometimes means "target", sometimes "hard deadline" and sometimes "the day work is meant to start" makes the overdue count meaningless. Pick one meaning, write it down, and use a separate field for the others.
Teams that fix these three things often find the dashboard barely necessary afterwards, because a board that is current is already readable. That is not a reason to skip the dashboard. It is a reason to do the three things first, in the order given, before spending a week on charts.
Reporting is a common upsell, and which tier it lands in varies more than most people expect. The following was checked on each vendor's own pricing page on 27 September 2026, and prices exclude tax.
| Tool | Free plan limits | Reporting on the free plan | First tier with dashboards |
|---|---|---|---|
| Jira | Free forever for 10 users, 2 GB storage, 150 automation steps per month | Reports and dashboards are listed on Free | Included on Free |
| Trello | Up to 10 collaborators and 10 boards per Workspace | Dashboard view is listed under Premium | Premium, $10 per user per month billed annually, $12.50 monthly |
| Asana | Personal, up to 2 seats per project and team | Reporting dashboards are listed under Starter | Starter, $10.99 per user per month billed annually, $13.49 monthly |
| ClickUp | Free Forever, 60 MB storage, unlimited members | Unlimited dashboards with advanced cards are listed under Business | Business, $12 per user per month billed yearly, $19 monthly |
| Notion | Free, with charts limited to 1 | One chart on Free, unlimited charts from Plus | Plus |
Two readings of that table matter for a small team. Jira gives away the most reporting on its free tier, and a team of up to ten already inside Atlassian has less reason to build anything custom than it thinks. And where reporting sits two tiers up, as with Trello, the real cost of a dashboard is the price difference across every seat, every month, for as long as the project runs. For a team of eight on Trello, moving from free to Premium to get one view is $80 a month.
The scramble is a symptom with a specific cause. It happens when the dashboard needs data that only lives in people's heads, so a person has to extract it by asking.
The fix is to stop asking for anything the tool can observe. Four questions cover most weekly status chases, and each has an observable substitute.
| The question being asked | What can be observed instead |
|---|---|
| What percentage are you at? | Which items moved this week, and which did not |
| Are you going to hit the date? | Whether the item's due date has been changed, and how many times |
| What is blocking you? | Items sitting in one column past a threshold, with no comment for several days |
| What are you working on next? | The top of that person's assigned list |
None of those substitutes is as rich as a conversation. That is fine. The point is not to replace the conversation but to stop spending it on facts, so the fifteen minutes goes to the two genuinely ambiguous items rather than to reading a list aloud.
The other half of the fix is to put the conversation where the work is. When the discussion about a delayed item happens in a thread attached to that item, the reason for the delay is recorded next to the delay, and the next person to ask does not have to ask. When it happens in a chat channel, it is gone within a day and the same question gets asked again next Thursday. Keeping talk and tasks in the same place is unglamorous compared to a dashboard, and it removes more weekly overhead. Comparisons of how each tool handles this are worth reading before committing to a reporting tier.
Plenty of dashboards are built correctly and then abandoned. The charts are right, the data is current, and the link sits unclicked for a month. That outcome has a cause worth naming, because building a nicer chart does not fix it.
A dashboard gets opened when opening it replaces something. If the Thursday meeting still walks through every item out loud, the dashboard is extra work and it will be skipped. The way to make it stick is to change what the meeting does: start by putting the screen up, spend no time on anything the screen already answers, and use the meeting only for the items that are ambiguous. After two or three weeks of that, people open it beforehand, because arriving without having read it becomes visible.
The second reason dashboards go unread is that they are addressed to nobody. A screen sent to a channel of thirty people belongs to no one. A screen that a named person is expected to have read before a specific meeting gets read. This is the same principle as giving milestones owners, applied to the report.
The third reason is speed. A dashboard that takes eight seconds to load, or that asks for a login every time, loses to a guess. This sounds trivial and it is not. The realistic competition for a dashboard is somebody's memory of last week, and memory loads instantly.
None of these three fixes involve charts. Adoption of a dashboard is decided by what it replaces, who it is addressed to, and how fast it opens, in that order.
A useful test for any dashboard: hand it to someone who was not in the last meeting and say nothing. If they come back with questions about what a chart means, the chart is not ready. If they come back with a question about the project, it is working.
This test kills most decorative choices quickly. Gauges without a target on them fail it. Percentages with no denominator shown fail it. Any chart whose title is a metric name rather than a question fails it, because the reader has to reverse engineer what they are supposed to conclude.
It also forces a decision that is easy to avoid: what should a reader do differently depending on what the dashboard says. A number that leads to the same action whatever its value is not a metric, it is reassurance. Cut it. The screen that survives this trim is usually half the size of the one that was designed, loads faster, and gets opened more often.
Before building any charts, check whether every piece of work in flight exists as an item on a board, and fix that first, because no dashboard survives a board that is missing a third of the work. Then pick one audience, build four numbers for them, and hand it to somebody cold to see whether it reads. If the reporting tier needed for that sits two plans above the current one, it is worth checking what a tool that includes Gantt, calendar and chat on its free plan can already show, and the feature list is the fastest way to see whether Pinateca covers the four numbers without a paid tier.
Four measures cover most projects: completion, how many items are past their due date and by how long, how many items are open and how old they are, and the load per person. Age of open work is the most useful of the four because it starts moving weeks before a deadline is missed, while a completion percentage can look healthy until the final week.
Sometimes. Jira lists reports and dashboards on its free plan for up to 10 users, while Trello puts its Dashboard view on Premium and Asana puts reporting dashboards on Starter. Checking the current plan before designing anything is worth doing first, because the answer changes what is worth building by hand.
Because state changes are being recorded as a separate chore rather than as a side effect of working. When moving a card is how work gets handed to the next person, the board stays current. When it is something to remember afterwards, the board lags by days, and it lags most during the busy weeks when the dashboard matters most.
A status report is a snapshot written for an audience at a moment in time, and it stops being true immediately. A dashboard reads live data, so it is only as accurate as the board underneath it. A report can be edited to add judgement and context, which is why many teams need both rather than one replacing the other.
Four to six, on one screen, with no scrolling. The test is to hand it to someone who missed the last meeting and say nothing: questions about what a chart means mean it is not ready, questions about the project mean it works. Anything that leads to the same action whatever its value can be cut.