Project Dashboard: What Should It Include?

Most project dashboards fail for a boring reason: they show everything. A dashboard that tries to display every metric, chart, and widget the tool offers becomes a wall of color that tells the manager nothing and takes an hour to read. The opposite failure is just as common — a dashboard with two numbers and a status label that answers none of the real questions. This guide answers the question directly: a project dashboard should include the handful of widgets that answer the questions decision-makers actually ask — is this project on schedule, on budget, under control, and on track to deliver. You will learn what a project dashboard is, the seven core widgets worth having, which metrics matter and which are noise, how to design it for different audiences, and what real dashboards in real tools look like.

Quick Answer: What Should a Project Dashboard Include?

A project dashboard should include seven core widgets: overall health, progress (percent complete), task status, schedule position, budget and cost, team workload, and top risks. Together these answer the questions every stakeholder cares about — are we on time, on budget, under control, and going to deliver what we promised.

The nuance: a dashboard is not a report. A report is a static document produced at a point in time; a dashboard is a live view that updates as the underlying data changes. The right widgets for your dashboard depend on who reads it and what they decide.

What Is a Project Dashboard — and How Is It Different from a Report?

A project dashboard is a visual, real-time display that aggregates a project’s key metrics — progress, tasks, schedule, cost, workload, risks — into a single view, updated automatically as the team works. It is the instrument panel of a project: the manager glances at it to understand health without interrogating the raw data.

The difference from a status report matters for how you design it. A weekly status report is a snapshot in time, written for a moment, and it lives in a document. A dashboard is alive: the moment a team member completes a task, the progress number moves. That is its power and its trap. The trap is that a dashboard only reflects the data feeding it. If tasks are not updated, owners not assigned, and statuses not maintained, the dashboard confidently displays wrong answers — beautifully formatted lies.

So the foundational rule: a dashboard is only as good as the underlying task data. Before designing widgets, you design the discipline — every task has an owner, a due date, a status, and an honest percent complete.

The 7 Core Widgets a Project Dashboard Should Include

These seven widgets cover the questions that matter in almost every project. You will rarely need more than these, and you should rarely have fewer.

1. Overall project health. A single high-level indicator — usually a RAG (red, amber, green) score, a health bar, or a small set of sub-health scores for schedule, budget, and scope. This is the “one glance” widget.

2. Progress / percent complete. How much of the project is actually done, against the plan. Displayed as a progress bar or donut chart comparing planned versus actual completion.

3. Task status. The state of the work: how many tasks are not started, in progress, completed, and overdue. This widget tells you where the work is piling up.

4. Schedule position. Planned versus actual dates, ahead-or-behind indicators, and upcoming milestones. The question answered: are we on time?

5. Budget and cost. Planned versus actual spend, cost variance, remaining budget. The question answered: are we on budget?

6. Workload. What each team member has assigned, completed, and overdue. The question answered: who is overloaded and who has capacity?

7. Top risks. The current highest-impact risks and issues, with owner and status. The question answered: what could still hurt us?

The Widget-to-Question Map

Which Metrics Actually Matter — and Which Are Noise?

The difference between a useful dashboard and a decorative one is metric discipline. A useful dashboard metric has three properties: it changes a decision, it is comparable against a baseline, and it can be influenced. Apply those tests and the noise filters itself out.

Useful metrics:

• Percent complete (compared against planned percent) — answers “ahead or behind.”
• Schedule variance in days — answers “how much are we slipping.”
• Cost variance — planned versus actual spend in dollars.
• Overdue task count and ratio — answers “is work piling up.”
• Open high-severity risks and issues — answers “what threatens delivery.”
• Milestones met vs planned — answers “are we hitting the checkpoints.”

Noise metrics (avoid or demote):

• Total number of tasks created — activity is not progress.
• Tasks touched or commented on — busywork is not completion.
• Raw hours logged without a plan comparison — hours are only meaningful against a baseline.
• Dashboard views count — measuring people looking at the dashboard, not the project.
• Any metric nobody can act on — if seeing it go red does not change anyone’s next action, it does not belong on the dashboard.

The rule of thumb: if a widget cannot be red, amber, or green in some defensible way, it is probably decoration. And if you cannot state what the manager will do differently when it changes color, remove it.

How to Design the Dashboard for the Audience

A dashboard that works for the team will fail for the executive, and vice versa. Design per audience, and do not try to make one dashboard serve everyone.

Team dashboard. Detail-rich. Task status, individual workload, upcoming due dates, and blockers. The team needs to see who is doing what and where help is needed today.

Project manager dashboard. The full seven-widget set. The PM needs health, progress, schedule, cost, workload, and risks all at once to run the project.

Executive dashboard. Aggregated and sparse. Portfolio health, top risks, and decisions needed — across projects, not inside one project’s task list. Executives want trends, exceptions, and asks, not task counts.

Client dashboard. Deliverables, milestones, budget position, and anything that affects what they are getting and when. Transparency that serves the relationship.

The practical approach: one source of truth (the live project data), several views. Most tools let you build multiple dashboards or filter one dashboard by role. The design rule is the same at every level — every widget answers a question that reader actually asks.

What Do Real Project Dashboards Look Like?

Different tools interpret the dashboard differently. Knowing the range helps you pick.

ProjectManager. Its project dashboard tracks six core metrics — health, tasks, progress, time, workload, and cost — in live graphs, with the ability to expand tiles, filter, print, or share. Trade-off: it is a paid, purpose-built tool, strongest for PMs who want the numbers without building anything; for small projects it is more capability than needed.

Jira. Dashboards are built from gadgets — sprint health, issue statistics, burndown charts, and filter results. Extremely powerful for software teams and fully customizable. Trade-off: the flexibility is also a tax; you assemble the dashboard yourself, and non-developer stakeholders often find Jira’s default views noisy.

Asana and monday.com. Both provide progress, workload, and portfolio dashboards with an approachable, low-setup feel. They are excellent for teams that want a dashboard fast. Trade-off: cost and risk tracking are lighter than dedicated PM tools, so finance-heavy projects need supplementation.

Smartsheet. Dashboard widgets (sheets, reports, charts) let teams build dashboard views over their existing grid data. Trade-off: it inherits spreadsheet maintenance — the dashboard is only as disciplined as the sheet behind it.

Business intelligence (Power BI, Tableau). When the organization already standardizes on BI, project data can be modeled into sophisticated dashboards. Trade-off: heavy setup and maintenance; overkill for a single project, valuable for enterprise portfolios.

Doitify. A combined project management platform keeps tasks, sub-tasks, checklists, schedules, resources, and reports in one workspace, so the project dashboard draws from the same live data the team updates daily — health, progress, workload, and reports in one place. Doitify is our product, which is why we know its capabilities from the inside. Its fit is strongest for teams that want the plan, the execution, and the visibility unified. Trade-off: for a tiny, single-project team, a lighter tool will do the job.

The choosing principle: pick the tool whose data model your team will actually keep current. The best dashboard engine in the world is worthless if the underlying tasks are not maintained.

Three Realistic Dashboard Scenarios with Numbers

Scenario 1 — Software PM spotting the slip early. A PM runs a 10-week release and checks her dashboard every morning. In week 5, the schedule widget shows 62% complete versus 68% planned, and the workload widget shows one engineer at 130% while another sits at 55%. In 15 minutes she rebalances the sprint — moving three tasks — and the schedule widget returns to 66% against plan by week 6. Without the dashboard, the slip would have surfaced in a weekly report six days later, after the sprint boundary made the rebalance harder.

Scenario 2 — Agency managing a portfolio of clients. An agency runs a portfolio dashboard across four client projects for a monthly executive review. The dashboard’s cost widget shows one project at 88% spend while only 61% complete. The executive flags it in the review, the PM raises the change request with the client the same week, and the project recovers its margin. The number that mattered was cost variance, and it was visible because the dashboard tracked spend against completion rather than spend alone.

Scenario 3 — Construction project health at a glance. A construction PM uses a dashboard with RAG health, progress, and risk widgets for a 9-month build. The health widget turns amber when the masonry subcontractor falls three days behind schedule. The PM escalates immediately, the schedule is re-sequenced, and the project absorbs a two-day slip instead of a three-week one. The dashboard converted a slow schedule drift — invisible in weekly reports — into an immediate, recoverable signal.

Common Mistakes in Project Dashboards

Showing everything the tool offers. Widgets added because they were available, not because they answer a question. The result is a dashboard nobody can scan.

Trusting bad data. A dashboard reflects its inputs. If statuses are stale and percents are guessed, the dashboard is a beautifully designed lie. Data discipline comes first.

One dashboard for everyone. A single dashboard that tries to serve the team, the PM, the executive, and the client serves none of them well.

Using vanity metrics. “Tasks created” and “activity” look alive but tell you nothing about whether the project is on track. Percent complete against plan tells you something.

No variance — just raw numbers. “72% complete” means nothing without “vs 68% planned.” A dashboard without baselines cannot show a problem until it is a crisis.

Ignoring the dashboard. A live view nobody checks is a server bill, not a management tool. The dashboard only works if someone reads it daily and acts on it.

Rebuilding it every month. Changing widgets and visuals constantly means nobody learns to read it. Fix the core seven, review the design quarterly at most.

Know This Before You Choose

Before you pick a dashboard tool or design your own view, answer these questions:

• Who reads this dashboard, and what decision does each reader make from it?
• What is the single question this dashboard must answer — and does every widget serve it?
• Is the underlying task data maintained well enough to feed the dashboard truthfully?
• Do I have baselines to compare against — planned progress, planned cost, planned dates?
• Which of the seven core widgets do I genuinely need, and which are nice-to-have?
• Will this tool let different audiences see different views, or will I be stuck with one dashboard for all?
• How much setup and maintenance is the tool, honestly, over a year?
• If the dashboard showed red tomorrow, would anyone notice and act?

Conclusion

A project dashboard is the instrument panel of the project — a live view that answers whether you are on time, on budget, under control, and on track to deliver. The design is simple in theory and hard in practice: start with the seven core widgets — health, progress, tasks, schedule, cost, workload, and risks — and then be brutal about removing anything that does not change a decision. Build different views for the team, the PM, the executive, and the client, choose a tool whose data model your team will actually maintain, and above all fix the data discipline before you fix the visuals. A dashboard is not a decoration; it is a daily attention device. Design it so that when something turns red, the right person sees it and acts — and the project gets smarter instead of just prettier.