A project tracker that survives contact with a real project

Project trackers do not fail because the model is wrong. They fail because keeping them current is work that benefits the person reading, not the person typing.

So the design goal is not completeness. It is making the tracker the fastest way for the doer to answer their own question: what am I doing next?

The model

Projects — name, client relation, owner, status, start, target end, budget.

Tasks — name, project relation, status, assignee, due date, estimate, actual, and a self-relation for parent/subtask.

People — name, role, weekly capacity in hours.

Assignments — only if people work across many projects with allocations. Links a person to a project with hours per week and a date range. This is a junction table, and it is what makes capacity planning possible.

Milestones — name, project, date, status. Worth separating from tasks because milestones are commitments to other people, and they want their own view.

Time entries — person, task, date, hours. Add this only if you bill by time or genuinely need actuals. It is the highest-friction table in any tracker; do not add it speculatively.

Tasks: the fields that earn their place

The temptation is fifteen fields. Resist it — every field is a tax on the person least motivated to pay it.

One assignee, not many. A task with three owners has none. If genuinely shared, split it into three tasks — which is usually what the work is anyway.

Blocked by is the field most trackers skip and most teams need. A self-relation from task to task gives you a real dependency graph, and therefore the ability to answer "what is actually stopping this?" without a meeting. It also lets you build the most useful view in the system, below.

The views that make it survive

"My week" — tasks assigned to me, not done, due within 14 days, sorted by due date. This is the view that keeps the tracker alive, because it is genuinely faster than reconstructing the same list from memory or chat. If your tracker does not have this view, people will not update it.

Board by status — the standup view, one project at a time.

Timeline / Gantt — tasks with start and end, grouped by project, dependencies drawn. For planning conversations, not for daily work.

Blocked — tasks where Blocked by is not empty and the blocker is not done. Sorted by how many things depend on it, descending. This is your daily unblock list and it is worth more than any burndown chart.

Milestones this quarter — calendar of commitments.

Capacity — people with allocated hours (rollup of assignments) against capacity. Anyone over 100% is a problem you can see before it becomes a slip.

Project health — grid of projects with rollups: tasks total, tasks done, % complete, overdue count, next milestone date.

Percent complete, honestly

Everyone wants a completion percentage. There are three ways to get one and they are not equally honest.

1. Count of tasks done ÷ total tasks. Free, and lies — it treats a two-minute task and a two-week task equally.
2. Sum of estimates done ÷ total estimates. Better, and requires estimates to exist.
3. Someone types a number. Worst. It is a feeling, and it is always 80%.

Use option 2 if you estimate, option 1 if you do not, and never option 3. And show the overdue count next to it — a project at 90% with six overdue tasks is not at 90%.

Recurring work

Most real projects contain repeating work: weekly reports, monthly reviews, sprint ceremonies.

Do not create 52 records by hand. Use a recurring rule that generates the next task when the previous is completed or on a schedule. The important detail: generate one at a time, not the whole year. A year of pre-created tasks makes every "what's due" view useless.

Automations worth having

1. Task marked Done → notify anyone whose task was blocked by it. This is the highest-value automation in project work. The gap between "blocker cleared" and "the blocked person finds out" is usually days.
2. Due date passes and status is not Done → flag it and tell the assignee. Once. Not daily; daily nagging gets muted.
3. All tasks in a milestone done → mark the milestone complete.
4. Project status → Complete → snapshot actuals against estimates. This is how you get better at estimating, and almost nobody does it.

Number 4 is worth the effort. Without a frozen record of what you estimated versus what it took, every project estimates from scratch forever.

Where trackers go wrong

Too many statuses. Not started, In progress, Blocked, In review, Done. Five. If you need "In progress (waiting on client)", that is Blocked with a reason.

Subtasks nested four deep. Two levels. Beyond that nobody can see the work, and rollups become uninterpretable.

Tracking time when you do not bill it. Time entries are the most disliked table in any system. If nothing downstream consumes the number, do not collect it.

Building the executive dashboard first. The dashboard is for someone who does not update the tracker. Build the doer's view first; if that is not fast and useful, the data behind the dashboard will be stale and the dashboard will be fiction.

Estimates as commitments. The moment an estimate is treated as a promise, estimates inflate and stop being useful for planning. Keep estimates and deadlines as separate fields with separate conversations.

Start here

Projects, Tasks, People. One board view, one "my week" view. That is it.

Add Milestones when you need to communicate dates outward. Add Assignments when someone is double-booked and you did not see it coming. Add Time entries only when a client invoice depends on it.

The measure of a project tracker is not how much it models. It is whether the person doing the work opens it on Monday morning by choice — because it is the fastest way to answer "what am I doing?" Build for that, and the reporting takes care of itself.

Two adjacent builds worth pairing with this one: structured intake, so work arrives as records rather than as "quick favour" emails, and a content calendar if the work you schedule is publishing rather than delivery.