Projects
The project tracker that updates itself
Open almost any project tracker in a busy team and you find the same thing: a status column where half the rows still say "In progress" for work that finished three weeks ago, and a "% complete" that someone last touched before the summer. The tracker is not lying on purpose. It is just a table, and a table only knows what a human last typed into it.
The difference between a task list and a tracker is a small one, and it is entirely mechanical. A task list stores what you tell it. A tracker works things out for you - it takes the few facts only a human can supply and derives everything else, live, every time you open it.
The three facts a human must supply
You cannot automate judgement, so keep the manual columns to the handful that genuinely need a person:
- The dates. A start and an end (planned, then actual as things land). Almost every useful signal a tracker can produce comes from comparing a date to today.
- Per cent complete. The one honest number the owner has to keep current. Everything downstream reads from it.
- The owner. One name per task, so the tracker can total a workload and so nobody can hide behind "the team".
That is the input. Everything below should be a formula, because everything below is a rule a spreadsheet can apply more reliably than a tired person on a Friday.
Let status compute itself
The single most valuable change you can make is to stop treating status as a dropdown. A dropdown is a promise to remember; a formula is a fact. Derive status from the numbers you already hold:
- Not started when per cent complete is zero.
- Done when it reaches 100.
- Overdue when the end date has passed and the task is not yet done.
- In progress for everything in between.
Now the tracker cannot drift. An overdue task turns overdue the morning its date passes, whether or not anyone touched the file. A finished task reads Done the instant its per cent hits 100. You have removed the most common source of a stale board - the human who forgot to change the label.
Flag the dependency, not just the date
A slipped date is easy to see. A slip hiding behind another slip is the one that sinks projects. Task B is due next week and looks fine, but Task A, which B depends on, is three days overdue - so B is quietly doomed and the board says nothing.
A dependency check fixes this. Point each task at the one it waits on, and let a formula flag any task whose predecessor is not finished. It is a single extra column and it converts your tracker from a record of the past into a warning about the future.
Put a dashboard on top
Once status, overdue and dependencies are formulas, a dashboard is nearly free - it is just a few counts and an average reading off the plan. The numbers a sponsor actually asks for are small in number:
- Overall progress (the average of per cent complete).
- How many tasks are underway right now.
- How many are overdue - the number that ends the meeting quickly.
- What is due in the next fortnight, so the team looks forward, not back.
Give each one a coloured card and the whole project reads in three seconds. The dashboard is not decoration; it is the reason nobody has to scroll a hundred-row table to answer "are we on track?".
A good tracker is one where the only thing you ever change is a date or a per cent - and the status, the flags and the headline numbers all move themselves.
Build it that way once and the weekly ritual of "updating the tracker" mostly disappears. You keep the dates honest, and the tracker keeps everyone else honest.
A project tracker that does the reading for you
Status computes itself (Done / In progress / Overdue / Not started), a dependency check flags any task whose predecessor is not finished, in-cell progress bars on every row, and a live dashboard that opens the moment you download it - with a fully worked example.