Short answer: a good project dashboard in monday.com answers a few questions a specific audience asks every week, using data that is reliable because the underlying boards are kept clean. Start from the questions, decide who the dashboard is for, make sure the boards contain the right columns, and only then pick widgets. Most dashboards fail because they are built the other way around.
If you want the general theory first, read our wiki entry on project dashboards. This article is the practical monday.com version, based on the dashboards we build for clients every week.
Why most project dashboards end up unused
- Nobody trusts the numbers. Widgets read from boards where half the items have no owner or an outdated status, so managers check Excel anyway.
- One dashboard for everyone. The team wants to know what is due this week, management wants to know which projects are at risk. One screen cannot do both well.
- Too many widgets. Twenty charts look impressive and say nothing. People cannot find the one number they came for.
- No routine. If the dashboard is not part of a weekly meeting or a decision, nobody opens it.
Step 1: start from the questions, not the widgets
Write down the five to eight questions your audience asks. For a PMO that might be: which projects are late, where is budget overrun, who is overloaded, what is starting next month. Each question becomes one widget. Questions that nobody asks do not get a widget, however nice the chart would look.
Step 2: make the boards dashboard-ready
A dashboard is a view on boards, so the boards decide the quality. Before building, check:
- One status column with agreed labels, used the same way on every project board the dashboard reads from.
- An owner (people) column that is always filled in.
- Dates or a timeline column for start and deadline, so you can show what is late or coming up.
- Numbers where you need numbers: budget, actual cost, hours, progress. A dashboard cannot sum a text column.
- Consistent structure across boards. If you combine several project boards, they should share the same columns. A template for new projects helps enormously.
If you have dozens of projects, consider a portfolio set-up: one board with a row per project, fed by the project boards, rather than a dashboard that tries to combine fifty boards. It is faster, easier to maintain and it works on smaller plans.
Step 3: one dashboard per audience
| Audience | Questions | Widgets that work |
|---|---|---|
| Project team | What is due this week? What is blocked? Who does what? | Calendar or timeline, items by status, workload per person, a filtered table of overdue items |
| Project manager or PMO | Which projects are late or over budget? Where is capacity tight? | Battery or status overview per project, numbers for budget versus actual, workload, Gantt across projects |
| Management | Are we on track? Where are the risks? What is coming? | A few number widgets (active projects, at risk, budget used), a chart of projects per status, a short list of red flags |
Keep management dashboards especially short. If a director needs to scroll, the dashboard is too long. Viewers are free on paid plans, so stakeholders who only look at dashboards do not need a paid seat.
Step 4: choose widgets that answer one question each
- Numbers for single key figures: active projects, overdue items, budget used.
- Battery for progress per project or phase at a glance.
- Chart for distributions: projects per status, per department, per client.
- Workload to see who is overloaded across projects, based on owner and effort or hours.
- Timeline or Gantt for the sequence of projects and milestones.
- Table with a filter, for the short list people need to act on, such as overdue items without owner.
Give every widget a title phrased as the question it answers, for example "Which projects are late?" instead of "Status chart". It sounds minor, but it makes a dashboard readable for people who did not build it.
Step 5: make it part of a routine
Use the dashboard in the meeting it was built for: the weekly team stand-up, the monthly PMO review, the management meeting. When the dashboard is on screen, people start updating their items before the meeting, and the data quality improves by itself. That is the real reason good dashboards stay in use.
Verel, which builds events and interior fit-outs, rolls out every new project from a fixed template, so all project boards share the same structure. That is exactly what makes reliable overviews across projects possible. Read how in the Verel case.
Five mistakes to avoid
- Building the dashboard before agreeing on status labels.
- Combining boards that do not share the same columns.
- Showing everything to everyone instead of one dashboard per audience.
- Using colours without meaning. Red should mean one thing: action needed.
- Never reviewing the dashboard. Remove widgets nobody looks at every quarter.
