Tracking Project Progress
Almost every late project was reported as on track until quite close to the end. That is not usually dishonesty. It is what happens when a project measures the wrong thing, or measures the right thing and then does nothing with the answer.
In short
- Tracking is a loop: measure, compare, decide, tell. Skip any step and the other three stop being useful.
- Measure finished deliverables, not effort spent or how people feel about it.
- Comparison needs a baseline. Without one, nothing can be behind schedule.
- A project that tracks but never decides is producing accurate status about an unchanged outcome.
Why this is where projects are actually saved
Planning is where a project’s intentions are set, but tracking is where reality gets to argue. Every plan is wrong in some detail by week two; the only question is how long it takes to notice and what happens when you do.
That’s the whole case for this chapter, and it’s worth stating in money. If the cost of a problem grows roughly tenfold each phase it survives — the curve in 1.2 — then the value of tracking is not “visibility” in the abstract. It is the number of weeks by which you shorten discovery, multiplied by how fast the cost was growing.
Which also explains why so much tracking effort produces so little. A weekly report that arrives promptly, reads accurately and changes nothing has shortened discovery by zero.
What thin tracking looks like from inside
The symptoms are specific, and they’re recognisable in a project this week:
- Everything is 90% done for a month. The classic. Percent complete is an estimate of remaining effort, and remaining effort is exactly what nobody can judge while stuck.
- The status is green until it is red. No amber, no gradual drift — a step change, usually about three weeks before the deadline. That’s a measurement problem, not a sudden event.
- Nobody can answer “compared to what?” Progress is being described against last week rather than against the plan, which always sounds like progress.
- The weekly meeting is people reading out what a tool already shows. Step 1 performed by humans, and steps 2 and 3 not performed at all.
- Issues are discussed repeatedly and never closed. The loop reaches step 3 and stops there, every week, with the same item.
- Reports go out and nothing comes back. If no recipient has ever asked a question or made a decision because of a report, it isn’t communication — it’s filing.
Measure things that can’t be argued with
The single highest-value change most projects can make is to add one measure that doesn’t depend on anybody’s judgement. Effort spent is not it — you can burn 100% of the budget and have nothing. Percent complete isn’t it either, for the reason above.
What works is anything an outsider could verify: deliverables accepted, environments live, users migrated, tests passing, invoices generated correctly. It doesn’t need to capture everything. It needs to be one number that only moves when something real happens. 6.1 is about choosing it.
How much tracking is enough?
A two-week project
A shared board, looked at daily by the people doing the work. No report, no meeting, no baseline document. The loop still runs — it just happens in someone’s head in ten seconds.
A three-month project
A weekly comparison against the baseline, a short written update, and an issue list that gets closed. Half an hour a week, and it should mostly be the deciding, not the collecting.
A large programme
Formal variance reporting, a change process with an approving body, and roll-up across workstreams. Expensive, and justified only when the money between review points is large.
The failure at the small end is no baseline and no rhythm. The failure at the large end is a reporting apparatus that consumes the capacity it was built to protect — three people producing status about the work of eight.
How the sections fit together
They’re a sequence, but the useful loops run backwards too:
- Measuring changes what you report. If your one honest measure is “deliverables accepted”, the report writes itself and stops being an assembly job.
- Deciding changes the baseline. A re-plan is a legitimate outcome of step 3, and it means the thing you compare against tomorrow is different from today’s. That’s healthy — provided the change is recorded rather than quiet.
- Reporting changes what gets measured. Not always for the better. If a number is used to judge people, it stops describing the work — which is the strongest argument for keeping tracking about the project rather than about individuals.
How this looks in AB
In AB Projects, most of step 1 happens as a by-product of doing the work: task status and progress roll up to the project dashboard, subtask progress rolls up to the parent, and the Calendar shows what is slipping before anyone writes anything. Step 4 is largely automatic too — Adaptive Cards announce changes into the linked Teams or Slack channel as they happen.
What the tool cannot do for you is steps 2 and 3. Comparing against the baseline requires that a baseline was recorded, and deciding requires a person. A practical habit: write the agreed dates into the project Wiki when planning ends, so that “are we behind?” has an answer six weeks later that doesn’t depend on anyone’s recollection.
What this chapter covers
Monitoring Deliverables
Measuring finished outcomes rather than activity, and agreeing what “done” means before you need it.
Issue and Change Management
Turning what you noticed into a decision — resolving issues and letting scope change on purpose.
Reporting Progress
Telling the right people the right amount, in a form that asks something of them.
Terms used on this page
- Baseline
- The approved version of scope, schedule and cost that progress is measured against. Without one, “behind schedule” has no meaning. More →
- Variance
- The gap between plan and actual, in time, cost or scope. Information, not blame — hiding it is what makes it expensive. More →
- Milestone
- A dated point that marks something meaningful being finished. Useful when it represents an outcome; decorative when it just marks a calendar boundary. More →
- Leading indicator
- A measure that moves before the outcome does — review queue length, blocked task count. More useful than one that confirms what already happened. More →
- Percent complete
- A self-reported estimate of how much of a task remains. Systematically optimistic near the end, which is why it needs a verifiable measure beside it. More →
- Escalation
- Passing a decision to someone with the authority to make it. The fourth of the four things you can do at step 3, and the one used too late. More →
Related reading
2.3 The Execution Phase
Where this loop runs, and what a project manager actually spends the phase doing.
3.2 Creating a Project Schedule
Where the baseline comes from — step 2 of the loop is only possible if this was done.
5.2 Kanban Boards
A view that makes flow and blockage visible without anyone reporting on it.