Project Dashboard Template

You do not download this template. It is a contract over nine columns, and a task export carrying them turns into a delivery dashboard the moment it lands: what is open and in which state, who is carrying how much, what is past its due date, and how far your estimates sat from the hours actually logged.

Load the template with sample data

The sample is the fastest way to see whether the layout fits before you go and find your own export, which for most trackers means a trip through an export screen nobody enjoys.

Download the sample CSV and use it as the target shape while you configure your export columns.

The column contract

The exact headers in the sample file. One row is one task. Two date columns is what makes this contract different from the others on the site, and it is what lets the layout produce a timeline rather than only a trend.

Column	What it holds	Role	Required	What breaks without it
`task_id`	The tracker's key for the task, such as T-200.	identifier	Required	Nothing can be counted reliably or traced back to the tracker, and duplicate rows become invisible.
`project`	Which project or workstream the task belongs to.	category	Required	Every panel merges all your work into one pile, which is exactly the view a multi-project team already has and cannot use.
`assignee`	Person the task is assigned to.	category	Optional	Workload distribution is gone, so an overloaded person and an idle one look the same from outside.
`status`	Workflow state: backlog, in progress, review, done.	category	Required	Done and not done cannot be told apart, which breaks the flow panel, the overdue count and the estimate accuracy comparison at once.
`priority`	Urgency band: urgent, high, normal, low.	category	Optional	You cannot tell whether the overdue pile is urgent work or a backlog nobody intended to do.
`start_date`	When work began or was scheduled to begin.	date	Optional	The timeline collapses to points instead of spans, and cycle time cannot be derived at all.
`due_date`	The date the task is committed for.	date	Required	Nothing can be late. The overdue panel disappears and the dashboard becomes a description of activity with no deadline in it.
`estimated_hours`	Effort estimated when the task was planned.	count	Optional	Capacity planning and the estimate accuracy panel both go, leaving task counts as the only measure of size.
`logged_hours`	Effort actually recorded against the task.	count	Optional	There is nothing to compare the estimate against, so the plan is never tested by what happened.

A task count is a poor measure of size and it is often the only one available. If you can supply hours or points, do, because a person with three tasks and a person with thirty may be carrying the same load.

What you get

A delivery KPI strip. Open tasks, completed tasks, tasks past their due date, and total hours logged, with the period the file covers stated underneath.
Status flow. Task counts by status in workflow order rather than sorted by size, because the sequence is the meaning. A bulge sitting in review is the classic finding here.
Workload by assignee. A ranked bar that can show task count or summed estimated hours. The two orderings frequently disagree, and the disagreement is the useful part.
Overdue work by priority. Anything unfinished with a due date in the past, split by priority, so an urgent overdue item never hides inside a total.
Estimated against logged hours. Scoped to completed tasks, grouped by project or by assignee. This is where a team finds out its real multiplier, and it is usually not one.
A project timeline. Bars spanning start_date to due_date, which is the closest thing here to a Gantt view and enough to see the overlaps.

i. Bring these columns

The prep work here is vocabulary rather than arithmetic. Trackers accumulate statuses. A team that has run for two years usually has fifteen of them, several meaning the same thing with different words, and a few that only one person uses. Map them down to five or six before exporting. The same goes for priority, where a numeric scale of P0 to P4 and a word scale of urgent to low often coexist in the same instance.

Decide the scope too. All open tasks gives you a workload view. All tasks in the last quarter gives you a delivery view. Both are useful and they answer different questions, so export the one that matches the meeting you are preparing for.

ii. Drop the file

Drag the CSV in. Both date columns are read as dates, which is what enables the timeline. Estimated and logged hours are read as counts and pair up on a shared axis so the comparison is fair. Task ID is treated as an identifier, so nothing offers to sum it.

The usual first surprise is a status panel with more bars than expected, which means the vocabulary collapse did not fully happen. The second is a large group of tasks with no assignee, which is not a data problem: it is unowned work, and it is worth looking at rather than filtering away.

iii. Adjust what you need

Filter to one project before a standup and the whole board narrows without a second export. Switch the workload panel between count and hours depending on whether the conversation is about volume or capacity. Add a breakdown by priority within status if your problem is triage rather than throughput.

Then export. A weekly status report that is the same four panels every week, generated in two minutes from a fresh export, is worth more than an elaborate report generated once and abandoned.

Getting your export into this shape

Every issue tracker exports a CSV and every one of them exports it slightly wrong for this purpose.

Jira. The all-fields export is the trap. It produces a file with dozens of columns and, worse, repeated column names: several columns all headed Comment, several headed Attachment, one per value, because Jira flattens multi-value fields by repeating the header. Use the current-fields export and pick the nine columns you want. Time fields come out in seconds, so Time Spent reading 72000 is twenty hours, and dividing by 3600 is a required step rather than a nicety. Dates arrive with time and a timezone offset, which parses fine. Assignee is a display name unless you export the account ID, and display names change when people marry.

Linear. The cleanest of the three. You get an identifier, title, status, priority, estimate and dates with no ceremony. Priority exports as a number where zero means no priority, which sorts wrongly unless you map it to words. Estimates are points and there is no logged hours concept at all, so the estimate accuracy panel needs a time tracking integration or it simply does not build.

Asana, Trello and Monday. Asana exports sections rather than statuses, so the section name becomes your status column. Trello has lists doing the same job, and a Trello export gives you no estimate unless somebody has been writing hours into the card title, which people do and which you can split out with a text operation. Monday exports whatever columns the board happens to have, which means the contract mapping is entirely board-specific.

One thing every tracker shares: subtasks. A parent task and its five subtasks are six rows, and the parent's estimate often includes the children's. Summing hours then double counts. Either export subtasks only, or export parents only, and never both without checking what the estimate on the parent actually means in your setup.

What this template will not do

It will not draw a burndown. A burndown needs the state of every task on every past day, and a task export is a snapshot of today. One file cannot reconstruct a history it does not contain.
It will not show dependencies. There is no blocked-by column in this contract, so the critical path is not represented. The timeline shows overlap, not causality.
It will not compute cycle time properly. Cycle time needs the moment a task entered and left each status. Start date to due date is a plan, not a measurement.
It will not sync with your tracker. No API, no webhook, no scheduled pull. Every refresh is a new export and a new drop.
It will not judge productivity. Hours logged measure how carefully somebody fills in a time field. Using this to rank people produces a team that logs hours beautifully and delivers no faster.
It will not handle subtask rollups. Parents and children are just rows. Any double counting is yours to prevent at export time.

Frequently Asked Questions

Why a column contract rather than a downloadable project tracker?

Because you already have a tracker and you do not want another one. What is missing is not a place to store tasks, it is a view across them, and a downloadable spreadsheet would just be a third copy of the same tasks going stale in a different folder. The contract keeps the tasks where they live. You export, you drop, you get the view, and next week you export again.

Will this work with a Jira, Linear or Asana export?

All three, after renaming. Jira gives you Issue key, Summary, Assignee, Status, Priority, Created and Due date, plus about forty custom field columns. Linear exports cleanly with an identifier and estimate points rather than hours. Asana gives you a task ID, a section and a due date but no built-in estimate. Map whatever you have onto the contract, leave out the columns you cannot supply, and the panels that depend on them simply do not build.

My team estimates in story points, not hours. Can I still use it?

Yes, and you should relabel rather than convert. Put points in estimated_hours and accept that every panel reading hours is now reading points, or rename both columns to estimated_points and logged_points and let the titles say so. What you must not do is multiply points by some hours-per-point ratio to make the columns look like hours. That invents precision the estimate never had and it will be quoted back at you as a commitment.

How does it decide whether a task is late?

By comparing due_date to today for anything not in a done status. That is the simplest rule that works and it has one blind spot worth naming: a task closed three weeks after its due date is not counted as late, because it is done now. If you care about historical lateness, you need a completion date column and a comparison against that, which is a column most trackers have and most default exports leave out.

What should the status column contain?

A small vocabulary of workflow states: backlog, in progress, review, done, blocked. Five or six values, repeating heavily. If your tracker has twenty statuses because three teams each added their own, map them down to a shared set before exporting. Twenty statuses produce a status panel with a long tail and no shape, and the shape is the entire value of that panel.

Can I see whether we estimate well?

Yes, and it is the most useful panel here. Estimated against logged hours, on completed tasks only, tells you your team's real ratio. Read it per assignee and per priority rather than as one number, because the pattern is usually specific: urgent work overruns most, and one or two people consistently estimate differently from everyone else, which is information about the estimates rather than about the people.

Should incomplete tasks be in the file?

Yes, for the workload and status panels, which are about what is open right now. No, for the estimate accuracy panel, which is meaningless on a task that is half done and has half its hours logged. The dashboard handles this by scoping the accuracy comparison to done tasks. If you filter incomplete work out of the file entirely, you lose the ability to see what is in flight at all.

Does anything leave my machine?

No. The file is parsed, aggregated and drawn in your browser tab and there is no upload endpoint behind this page. Task exports carry summaries and assignee names, and a project export often reveals a roadmap, so a tool that works without sending the file anywhere is easier to justify to whoever owns your security policy.

See it before you fight the export screen

Open the sample task file, look at the six panels, then decide which columns are worth configuring.