3.1 · Progress tracking & remaining work

Level 3 · Steering, risks & communication

3.1Progress tracking & remaining work

Goal: measure real progress through remaining work and update the schedule to steer on facts.
Estimated time: 12 min · self-paced reading · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

  • Steering = measuring the real state and comparing it to the plan: "where do we really stand?".
  • The objectively re-estimated remaining work is more reliable than time spent or a felt percentage.
  • Progress is built on concrete deliverables and a regular tracking ritual that reveals drifts early.

Running case — Bilal steers out of the "90%" trap

Bilal steers an application redesign project for a client in Algiers. At the weekly check-in, every team member has been reporting "I am at 90%" for three weeks, yet nothing is delivered. Bilal changes the question: "how many days do you have left, and on exactly what?". The cumulated remaining work reveals three weeks of hidden delay. He reschedules coldly, makes progress visible and takes control back.

This same case runs through the lesson, the diagram, the script and the 48h challenge — and continues in 3.2, 3.3, 3.4 and 3.5.

1. Steering means looking at reality

Once execution starts, the project manager's role shifts to steering: measuring where the project really stands and comparing it to the plan. Progress tracking answers "where are we really?" — whose honest answer is not "I spent a lot of time" but "here is what remains to be done". Bilal learns that time spent measures consumed effort, not the road left ahead.

Steering on impressions reassures in the short term and costs dearly at the end: drifts grow in the dark. Steering on facts lets you reschedule early, while room for manoeuvre remains.

2. Remaining work

The best indicator is the remaining work: it forces an objective re-estimate of the work left, task by task, instead of hiding behind time already spent. "6 dev days + tests left" predicts the true end date; "I am at 90%" predicts nothing.

Progress is based on concrete items (physical progress: produced deliverables) and the schedule is updated (rescheduling) at each weekly tracking milestone. Steering means facing reality, regularly.

Common misinterpretation: "A felt percentage is enough: 90% means almost done." No. That is the 90% syndrome: a figure based on time spent or an impression, stalling for weeks. Another mistake: confusing time spent with real progress — many hours does not mean much progress.
Measuring real progress Facts, not impressions Remaining work Re-estimatethe work leftDeliverables Progress onconcrete itemsReschedule Do deadlinesstill hold?
Facts, not impressions
Text version of the diagram (SEO / screen readers / translation): 1) Remaining work — Bilal asks everyone for the re-estimated work left, not time spent. 2) Deliverables — he only validates concrete produced items, not felt percentages. 3) Reschedule — he updates the schedule and checks whether deadlines still hold. Lesson: remaining work predicts the true end date and reveals drifts early.

🔎 Concrete example — The 90% syndrome

Why percentages mislead.

"I am at 90%" → stalls for weeks (felt time spent).
Remaining work: "6 dev days + tests left" → objective figure.
→ remaining work predicts the true end date, not the felt percentage.

Outcome: steering on facts.

Reflex: ask for remaining work, not time spent.

Section vocabulary

Progress tracking
Regular measurement of the project's real state (work done, work left) against the plan.

Simple example: Bilal compares actuals to the schedule of his project every week.

What it is not: a general impression that "things are going well" with no figures.

Reflex: at each check-in: "where do we really stand?".

Remaining work
Objective estimate of the work left to do; more reliable than a felt percentage.

Simple example: "6 dev days + tests left" instead of "90%".

What it is not: time already spent brandished as proof of progress.

Reflex: ask for remaining work, never for time spent.

Physical progress
The actually completed share of a task, based on concrete deliverables, not time spent.

Simple example: Bilal only validates screens that are delivered and tested.

What it is not: "I spent 3 days on it so it is two-thirds done".

Reflex: no concrete deliverable = no counted progress.

Rescheduling
Updating the schedule from actual progress and remaining work.

Simple example: Bilal shifts forecasts when cumulated remaining work exceeds the margin.

What it is not: keeping initial dates on principle despite the facts.

Reflex: each check-in ends with "do deadlines still hold?".

Tracking milestone
A regular point (weekly, e.g.) where progress and forecasts are updated.

Simple example: Bilal's weekly point: remaining work, deliverables, cold forecasts.

What it is not: a rare grand review where everyone embellishes.

Reflex: short, frank and regular beats rare and solemn.

In practice — Measuring real progress

  1. For each ongoing task, do not ask “how much time spent?” but “how much remaining work?”.
  2. Base progress on concrete items (produced deliverables), not on a progress impression.
  3. Update the schedule with this data: do deadlines still hold?
  4. Set a regular tracking ritual (weekly) to update progress and forecasts coldly.
You measure real progress through remaining work and update the schedule: you steer on facts.

Ready-to-say script — asking for remaining work at the weekly point (30 s)

"Forget the percentage: tell me what you have left to do, in days, and on exactly what. What is delivered and verifiable today? Let us reset the end date together."

To say to each team member, task by task, with no blame: we look for reality, not a culprit.

Copy-paste template — weekly remaining-work sheet

TASK: _______________ | OWNER: _______________
DELIVERED (concrete, verifiable): _______________
REMAINING WORK (days + content): _______________
INITIAL DEADLINE: _______________ | DOES IT HOLD? (yes / no): _______________
ACTION (reschedule / help / arbitrate): _______________

Very small business / tight budget

A simple table is enough: task, delivered, remaining work in days — reviewed by two people every Friday in 15 minutes.

SME in Algeria

Bilal sets his weekly point outside peak times (travel, outages) and records remaining work in person-days to stay comparable.

Software project

Tie each remaining-work item to a testable deliverable: no “90% coded” without a verifiable screen or API.

Construction / field project

Count laid and accepted quantities (metres, lots), not hours of site presence.

✓ Best practices

  • Think in remaining work, not time spent.
  • Base progress on concrete deliverables.
  • Set a regular, honest tracking ritual.

✗ Common pitfalls

  • Trusting the felt percentage (90% syndrome).
  • Confusing time spent with real progress.
  • Tracking rarely or complacently (problems grow).

Key takeaways

  • Steering = measuring the real state and comparing it to the plan.
  • Remaining work is more reliable than a felt percentage.
  • Progress is based on concrete deliverables, not time spent.
  • A regular tracking ritual reveals drifts early.

48h challenge — apply tomorrow

Ask for the remaining work in days for each ongoing task (template above) and update 1 end date accordingly. 20 minutes is enough.

Section exit checklist
  • I can explain the 90% syndrome without hesitating.
  • I can ask for remaining work instead of time spent.
  • I collected remaining-work figures and reset 1 forecast.
Self-rating 1-5: do I steer on facts?is my tracking regular and honest?

Frequently asked questions

Why is the “progress percentage” misleading?

Because it is often based on time spent or an impression (“I am at 90%”) that then stalls for weeks. That is the 90% syndrome. Remaining work forces an objective re-estimate of the work left, far more reliable for forecasting the real end date: time spent measures consumed effort, not the road left — yet the latter determines when the project will finish.

How often should progress be tracked?

Often enough to react in time, without overloading: a weekly check-in suits many projects. The right pace depends on duration and risk. What matters is regularity and honesty — rare or complacent tracking lets problems grow. Better a short, frank weekly point than a big monthly review where everyone embellishes.

Check your understanding

Bilal has heard “90%” for 3 weeks with no deliverable. What is the right reflex?

Additional resources (optional, to go further)

Level 3 examFresh, harder questions to test what you've learned