What is the difference between a project tracker and a task tracker?
project tracker template is a key topic in modern project management and teamwork. A task tracker answers “what are we doing this week”. A project tracker answers “which projects need attention and what decision do they need”. The two are often confused because both are tables with rows, and the confusion is why leadership sees a wall of tasks instead of a portfolio.
| Dimension | Task tracker | Project tracker |
|---|---|---|
| Row represents | One task or story | One project |
| Time horizon | Days to weeks | Weeks to quarters |
| Typical owner | The person doing the work | The person accountable for delivery |
| Update rhythm | Daily, by whoever touches the task | Weekly, by the project owner |
| Main question | What is next? | Where is the risk, and who decides? |
| Failure if missing | Work is forgotten | Money and time are spent before anyone notices |
| Audience | The delivery team | Sponsors, PMO, leadership, clients |
Both are necessary and neither replaces the other. The test is simple: if you cannot answer “how many projects are red and what is the total forecast overrun” from the sheet in under a minute, you are looking at a task tracker.
Which columns belong in a portfolio project tracker?
Fourteen, in this order. The sequence matters because it follows the reader’s eye: identity, timing, progress, money, judgement, next event.
| Column | Example | Why it earns its place |
|---|---|---|
| A — ID | P-05 | A stable identifier that is never reused, so history survives a rename |
| B — Project | Data warehouse rebuild | The name people actually use, not the internal code |
| C — Owner | R. Okafor | One accountable person. Two names means nobody |
| D — Phase | Build | A short fixed list: discovery, design, build, test, launch, close |
| E — Start | 2026-06-01 | A real date, needed for the expected-progress formula |
| F — Target end | 2027-02-27 | The committed date, not the optimistic one |
| G — % complete | 40% | Effort-weighted, calculated from the workstreams |
| H — Expected % | 55% | Where the project should be today, from elapsed time |
| I — Schedule variance | −15 pp | G minus H. Negative means behind |
| J — Budget | 210,000 | Approved budget, not the latest wish |
| K — Actual spend | 96,000 | Committed plus invoiced. One definition, written down |
| L — Forecast at completion | 240,000 | Actual divided by percent complete, adjusted for known costs |
| M — Budget variance | +14.3% | Forecast against budget. Positive means over |
| N — RAG | Red | Calculated from I and M, with a written override column beside it |
| O — Next milestone | Cutover rehearsal | The next date someone outside the team cares about |
| P — Next milestone date | 2026-12-11 | If this is in the past, the project is red regardless of mood |
That is sixteen if you count the milestone and its date separately, and it is still one screen wide. What is deliberately missing matters as much. There is no task count, no percentage of tasks done, no document links, and no free-text summary longer than a line. Each of those invites maintenance without changing a decision.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.
How do you calculate percent complete honestly?
Weight the workstreams by effort and never average percentages. Averaging treats a two-day workstream and a two-month workstream as equals, which is how a project that has finished its easy half reports 50% when it is 20% done.
The formula, with workstream weights in column C and completion in column D:
`=SUMPRODUCT(C2:C6,D2:D6)/SUM(C2:C6)`
A worked case: a CRM migration has four workstreams weighted 40, 25, 20 and 15 points, with completion at 100%, 60%, 25% and 0%.
- Weighted numerator: (40 × 1.00) + (25 × 0.60) + (20 × 0.25) + (15 × 0) = 40 + 15 + 5 + 0 = 60.
- Denominator: 40 + 25 + 20 + 15 = 100.
- Weighted completion: 60%.
The simple average of the four percentages would be 46%, and neither number is right for every purpose. The weighted figure is right for schedule and cost forecasting, because effort is what consumes budget. The simple average is only defensible when the workstreams genuinely cost the same, which is rare.
Two guardrails. First, define completion at the workstream’s definition of done, not at “code written”. Second, never let a workstream reach 100% while its acceptance criteria are open, because that single habit is worth more than any formula in the sheet.
How do you make RAG status objective?
Calculate it from two facts you already have — schedule variance and budget variance — and allow a written override next to it. The colour then becomes a rule, and rules survive a change of project manager.
| Status | Criteria (any one is enough) | What the owner commits to | Who can change it |
|---|---|---|---|
| Green | Within 5 points of expected progress, forecast within budget, no milestone overdue | Update next week with no escalation | Owner |
| Amber | 5 to 10 points behind, or forecast 1% to 5% over budget | A written recovery action with a date, reviewed weekly | Owner, with sponsor informed |
| Red | More than 10 points behind, or forecast more than 5% over, or a milestone already missed | A decision request at the next steering meeting | Sponsor, not the owner alone |
The formula, with percentage complete in G, expected in H, schedule variance in I, budget variance in M and next milestone date in P:
`=IF(G2>=1,”Green”,IF(OR(P2
Two things make this survive contact with real teams. The first is that red triggers a decision, not a confession. A red project needs a choice: extend, cut scope, or spend more. The tracker should name which one is being requested. The second is that overrides are written, never silent. If the owner disagrees with the computed colour, they type the override in a separate column and give a one-line reason. The computed colour stays visible, so the pattern of overrides becomes a signal in itself.
The “red means needs help, not blame” rule is not sentiment. It is a data-quality requirement. A team that is punished for a red row will produce amber rows until the amber row becomes a red project three weeks later.
What does a filled-in portfolio look like?
Here is a six-project register, with forecast at completion calculated as actual spend divided by weighted percent complete. Expected progress assumes a linear spend of the planned timeline, which is crude and adequate for portfolio-level decisions.
| ID | Project | Owner | % complete | Expected % | Schedule variance | Budget | Actual | Forecast | Budget variance | RAG |
|---|---|---|---|---|---|---|---|---|---|---|
| P-01 | Website replatform | A. Meier | 62% | 70% | −8 pp | 120,000 | 81,000 | 130,645 | +8.9% | Red |
| P-02 | CRM migration | J. Silva | 28% | 25% | +3 pp | 45,000 | 12,000 | 42,857 | −4.8% | Green |
| P-03 | Compliance audit | S. Haddad | 88% | 95% | −7 pp | 30,000 | 27,500 | 31,250 | +4.2% | Amber |
| P-04 | Brand refresh | L. Chen | 50% | 50% | 0 pp | 18,000 | 9,000 | 18,000 | 0.0% | Green |
| P-05 | Data warehouse | R. Okafor | 40% | 55% | −15 pp | 210,000 | 96,000 | 240,000 | +14.3% | Red |
| P-06 | Onboarding revamp | M. Duarte | 20% | 18% | +2 pp | 22,000 | 4,400 | 22,000 | 0.0% | Green |
The roll-up row is where the portfolio view earns its keep:
- Total approved budget: 445,000.
- Total actual spend: 229,900, which is 51.7% of budget.
- Total forecast at completion: 484,752, an overrun of 39,752, or 8.9%.
- RAG distribution: 2 red, 1 amber, 3 green.
- Value at risk, counting only the two red projects: 10,645 + 30,000 = 40,645.
Notice what the aggregate hides and the rows reveal. “52% of budget spent” reads like a healthy portfolio until you see that P-05 has consumed 96,000 for 40% of its scope, and that P-01 is already 8.9% over with 38% of its work left. Two projects are creating the entire overrun; the other four are, between them, 893 under budget.
The P-05 arithmetic is worth spelling out because it is the whole argument for tracking forecast rather than spend. Actual spend of 96,000 at 40% complete implies a total of 96,000 divided by 0.40, which is 240,000. Against a 210,000 budget that is 30,000 over, or 14.3%. If you had waited until the project was 80% complete to notice, the forecast would already be locked in and the only remaining decision would be who explains it.
A second arithmetic check catches a different failure. Suppose the same project had reached only 30% complete on the same spend. The forecast would be 96,000 divided by 0.30, or 320,000 — a 52% overrun. The difference between 14% and 52% is one column, updated weekly.
How do you keep the tracker from going stale?
By writing a refresh contract, one paragraph long, that names the owner, the day, the time and the definition of each editable field.
A working contract looks like this. Owners update their own row every Thursday before 16:00. They may edit percent complete, actual spend, next milestone and notes. They may not edit budget, target date or expected progress. The portfolio owner reviews the sheet on Friday morning and flags any project whose variance moved by more than 5 points in a week. Nobody edits the sheet after the review, and history is kept by copying the previous week to a dated tab rather than overwriting it.
That last rule is the cheapest form of audit trail available in a spreadsheet. Ten weekly tabs give you a trend line, and a trend line is what turns a status snapshot into an early-warning system.
The economics of the ritual are worth stating, because “another weekly update” is the objection you will hear. Six projects at twenty minutes each is two hours a week, or 96 hours a year across 48 working weeks. At a loaded rate of 65 per hour, that is about 6,240 in tracked time. Against a single 40,000 forecast overrun caught two months earlier, the ritual is cheap. Against a portfolio where nothing ever goes wrong, it is overhead — but portfolios where nothing ever goes wrong do not exist, they are just not being measured.
What happens in a fifteen-minute portfolio review?
Four questions, in this order, with the sheet on screen and nobody presenting slides. The meeting is a reading exercise followed by decisions, and fifteen minutes is enough if the sheet was filled in properly.
First: what changed since last week? The reviewer reads only the rows where schedule variance or budget variance moved by more than five points. Everything else is silent by design. A week where nothing moved is a two-minute meeting, and that is a feature.
Second: what is red, and what decision does it need? Each red row must state the ask — extend the date, remove scope, or fund the overrun — with the amount. P-05 in the example above needs a decision on 30,000. Without the number, the conversation becomes a discussion about effort, which is the wrong conversation.
Third: what is amber, and when does it become red? Amber is a scheduled future decision. The owner names the date by which the recovery action either works or escalates. An amber row with no date is a red row in disguise.
Fourth: what did we learn that changes the plan for next quarter? One sentence, recorded. If the same forecast error appears in three projects, the estimating method is the problem, not the projects.
Two habits keep the review honest. Nobody presents, because presenting invites narrative and narrative is where the green comes from. And nobody leaves without a written owner and date on every red item, typed into the notes column while the meeting is still running.
What are the most common mistakes?
Five, and each one has a visible symptom you can check for right now.
- Using the tracker as a task board. Symptom: more than 40 rows. Fix: one row per project, and push detail into the project’s own plan.
- Averaging percentages instead of weighting them. Symptom: every project sits between 40% and 60% for months. Fix: weight by effort or by budget.
- Typing RAG by feel. Symptom: no project has been red in two quarters. Fix: calculate the colour and require a written reason for any override.
- Tracking spend without forecast. Symptom: a project at 80% complete and 40% spend that everyone calls healthy. Fix: add forecast at completion and read it weekly.
- Two owners per row. Symptom: the row is not updated. Fix: one name, and a named deputy who updates during leave.
The common thread is that each mistake makes the sheet easier to maintain and less useful to read. A tracker is a compression of reality, and compression always tempts you to drop the part that is uncomfortable.
Can a spreadsheet run a portfolio?
Up to roughly a dozen projects, yes, and it is often the better choice. Above that, the limits arrive quickly and predictably.
The first limit is concurrency. Two people editing the same sheet at 16:00 on Thursday is a conflict, and the conflict is usually resolved by whoever saves last. The second is permissions: a sponsor should see the portfolio without editing it, and a spreadsheet makes that awkward. The third is history, which exists only if someone remembers to copy the tab. The fourth is that formulas are invisible to the person who inherits the sheet, so the definition of “forecast” lives in one person’s memory.
The honest trade-off: a spreadsheet is fast to start, free, and flexible enough to survive a change of method. It is also fragile the moment more than a handful of people depend on it. Move to a tool when the number of projects crosses about a dozen, when external people need read access, or when two people need to update at the same time. Do not move before that, because migrating a portfolio also means migrating the argument about definitions, and that argument is easier to have in a sheet.
How does Doitify handle portfolio tracking?
Doitify is our product, so treat this as disclosure rather than an independent review. Projects, tasks, sub-tasks, checklists, owners and due dates live in one workspace, with Kanban boards, Gantt charts, roadmaps, calendars, workload views, work and performance reports, automations and project documents.
For the specific problem in this article, the useful part is that percent complete, owner and dates are already data rather than typed summaries. Because the project plan and the status live in the same system, a reported percentage comes from work items instead of a weekly estimate, and the forecast column stops depending on someone’s arithmetic at 16:00 on Thursday. Workload views add the one dimension a spreadsheet handles badly: whether the person who owns three red projects physically has the hours to recover them.
The trade-off is real. A six-project portfolio with stable teams needs the sheet, not a platform, and should stay there until the refresh contract breaks. The value of a system arrives when the number of rows or the number of readers outgrows the ritual.
Conclusion
A project tracker template is a compression of nine projects into one screen, and the compression only works if every column changes a decision. Owner, dates, weighted progress, forecast and a calculated colour will do more than forty columns of detail, because they answer the question a sponsor actually asks: which project needs a decision this week.
Build the sheet, write the refresh contract on the same tab, and run it for a month. If the colours are being argued about, the formula is not strict enough. If nothing has been red in a quarter, the criteria are not honest. And if you cannot read the whole portfolio in under a minute, the problem is not the template.
If this post on project tracker template was helpful, you might also enjoy No-Code Project Management Automation: The Complete Guide (2026) and Project Timeline: How to Create One (Step-by-Step Guide).
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.
