How to Track Project Progress: Methods That Give You a Real Number

Tracking project progress means producing one defensible number: the percentage of planned work actually finished. That number depends on the method used to credit partially finished work, and the choice changes the answer. A project with four of ten tasks done reads 40% under a 0/100 rule and 55% under a 50/50 rule — the same work, fifteen points apart.

Key takeaways

• Percent complete is a method, not a measurement. Pick one, write it down, and apply it to every project.
• Effort is not progress. Hours spent divided by hours budgeted makes a project that is burning time without delivering look on schedule.
• Fixed-formula methods (0/100, 25/75, 50/50) suit short tasks. Weighted milestones suit long phases. Units completed suit repeatable work.
• The method you choose propagates into cost metrics. The same project reads a CPI of 0.83 or 1.14 depending on the percent-complete rule alone.
• Progress, status and performance are three different questions. Mixing them produces reports that answer none of them.

Progress, status and performance are three different things

These three get used interchangeably in meetings, and the confusion is why progress reports often say nothing.

A report that says “on track, no blockers” has given status and skipped progress. A report that says “we’ve spent 60% of the budget” has given neither — that is an input, not a measure of either.

All three belong in a progress review. The rest of this guide is about the first one, because it is the one nobody defines.

How do you calculate percent complete?

Percent complete = credited work ÷ total planned work

The denominator is settled by the plan. The numerator is the decision: how much credit does a task get when it is started but not finished? Seven established methods answer that differently, and the table below adds one row for the remaining fixed-formula variants.

0/100 and the fixed-formula methods

The fixed-formula family removes judgement entirely, which is the point. A task is either not started, started, or done, and the credit follows automatically.

0/100 is the conservative choice and the right default for tasks shorter than one reporting period. If a task starts and finishes inside the same week, crediting it halfway mid-week adds noise without adding information.

50/50 suits work that genuinely spans periods, and its weakness is worth stating: a task credited at 50% on its first day may be 5% done. Across many tasks the errors average out; on a project with few large tasks they do not.

Weighted milestones

For phases measured in months, assign each phase a weight that sums to 100, then credit the weight as milestones pass. This only works where the checkpoints are real, which is why defining project milestones properly has to happen before the first assessment rather than after.

This is the most defensible method for unequal work, and its accuracy lives entirely in the weights. Set them during planning, before anyone has an interest in the answer.

Units completed

Percent complete = units finished ÷ total units

Where work is genuinely repeatable — 400 pages translated, 120 devices installed, 2,000 records migrated — count the units. It is the only method with no judgement in it at all.

The failure mode is unit variance. If 50 of 100 installs are done but the remaining 50 are the difficult sites, the count says 50% and the truth is less.

Level of effort

Some work has no deliverable to measure: project management, support, coordination. Level of effort credits progress with elapsed schedule, so a six-month activity is 50% complete at month three regardless of what happened.

Use it, and understand what it does: a level-of-effort activity is always exactly on plan. It can never show a variance, so it cannot warn you about anything. Keep these activities as a small share of the total, or a project made mostly of them will report perfect health in every period.

Why effort is not progress

The most common way to produce a percent-complete number is also the least reliable: divide hours spent by hours budgeted.

Hours spent ÷ hours budgeted measures consumption, not delivery. It rises whenever anyone works, including when the work produces nothing usable. A project that has burned 60% of its hours and delivered 30% of its scope reports 60% progress, and the shortfall only surfaces when the remaining hours run out.

The failure is structural, not occasional. Effort-based progress cannot report an overrun, because the overrun is in the numerator. Whatever is spent becomes progress.

There is one legitimate use for hours against budget: it is an input to cost metrics, where spend genuinely is the thing being measured — the same hours that feed job costing and every forecast built on it. Keep it there. For progress, measure what has been produced — deliverables accepted, milestones passed, units finished.

The same project, four methods, fifteen points apart

A project of ten tasks of equal weight. Four are complete, three are in progress, three have not started. The team has used 260 of 500 budgeted hours.

Fifteen points of spread, and nothing about the project changed.

That spread does not stay in the progress column. Percent complete is what turns a budget into earned value, so the method choice flows straight into the cost picture. With a $120,000 budget and $58,000 spent:

The same project is over budget or under budget depending only on the percent-complete rule. The gap in reported earned value is $18,000 on identical work.

This is why the method has to be fixed before the project starts and applied unchanged. A method chosen after the first bad report is not a measurement, it is a negotiation.

Which method fits which kind of work?

Mixing methods inside one project is normal and correct. A construction project might use units completed for installs, weighted milestones for design and level of effort for site management. What matters is that each work package has one declared method and keeps it.

How do you set up progress tracking in six steps?

1. Baseline the scope and schedule. Progress is a comparison, and without a baseline there is nothing to compare against. Freeze it, version it, and change it only through an approved change. A baseline is only as good as the project time estimation underneath it.
2. Break the work into packages small enough to assess. A package that takes four months cannot be credited honestly by any method. Aim for packages that finish inside one or two reporting periods.
3. Assign a percent-complete method to each package. Use the table above. Record the method next to the package, not in someone’s memory.
4. Define what “complete” means for each deliverable. Written down, before work starts. “Design done” means the document is approved by a named person, not that the designer stopped working on it.
5. Set the review cadence and the escalation thresholds. Both below.
6. Report progress, status and performance separately. Three questions, three sections. Combining them is what makes reports unreadable.

How often should progress be reviewed?

Percent complete is assessed weekly, not continuously, because it is a judgement and judgements made daily turn into noise. Daily entry applies to the raw inputs — task status and hours — not to the assessment built on them.

Running several projects at once multiplies the cadence problem rather than the work, which is its own subject — managing multiple projects covers what changes when the same review has to cover six.

When should progress trigger escalation?

A review that always concludes “we’ll keep an eye on it” is not a control. Thresholds decide in advance what counts as a problem.

The last two rows catch what the indexes miss. A package whose percent complete has not moved in two periods is stuck whether or not the overall index looks fine. And a 20-point gap between hours consumed and work delivered means the estimate was wrong, which no amount of effort will fix.

Escalate to a named person with a decision to make, not to a wider audience. An escalation without a decision attached is a status update with urgency added.

What do you do when a project stalls?

Four levers exist, and only four. Everything else is a combination of them.

Two things to know before pulling one. Adding people late to a late project usually slows it further, because the existing team spends its time on onboarding instead of delivery — the observation is old enough to have a name, Brooks’s law, and it has outlived every tooling change since. And reducing scope requires the client’s agreement, which takes time, so it is the lever that has to be pulled earliest to work at all.

Whichever lever is chosen, re-baseline afterwards. Progress measured against a plan everyone has abandoned produces numbers that nobody believes, which is how projects lose their reporting entirely.

What goes in a progress report?

One page, five sections, same order every time.

1. Progress. Percent complete against plan, with the method named. One line per work package.
2. Status. Open blockers, overdue items, and what is needed from whom.
3. Performance. Variances against baseline for schedule and cost.
4. Decisions needed. Each with an owner and a date. If this section is empty, say so explicitly.
5. Changes since last report. Scope changes, re-baselines, new risks.

What to leave out: a narrative of activities completed, and any metric with no threshold attached. Both pad the report and neither changes a decision. Where the report is recurring rather than one-off, our guide to measuring your project’s impact covers choosing the handful of measures worth repeating.

See time tracking software

The gap itself is easiest to watch where the two numbers sit side by side — time tracking reports give the consumed half, and the percent-complete assessment gives the other.