Choosing How to Measure Project Progress (Milestones, Tasks, EVM and Friends)
"About eighty percent done" is the most dangerous sentence in delivery, because the last twenty percent contains the integration, the edge cases, and everything everyone postponed. I stopped accepting percent-complete by feel years ago, after a module sat at ninety percent for six straight weeks. Progress needs a measurement method chosen on purpose. Here are the ones I actually use, with the price tag of each.
Milestone tracking: cheap, binary, honest
Break the project into milestones, each with a verifiable exit: contract signed, integration test passed, store live. A milestone is done or not done; there is no eighty percent. This is my default for enterprise integrations, where partner-facing dates are the real skeleton anyway. The strength is that it cannot be gamed by optimism. The weakness is resolution: between milestones the method is silent, so if milestones sit six weeks apart, so does your visibility. Milestones every two to four weeks keep the silence survivable.
Task counting: fine-grained, gameable
Count completed tasks against total. Every tracker gives you this for free, and it updates daily. Two traps. First, tasks are unequal, so 30 of 60 tasks done is not half the work, especially when teams naturally finish the small clear ones first. Second, the denominator moves: scope added mid-flight makes the ratio go backwards, which is honest, but demoralizing if nobody explains it. I use task counts inside the team for weekly rhythm, never as the headline number for sponsors.
Burndown and velocity: the Agile pair
In sprint-based work, the burndown shows remaining work against time and velocity shows the team's sustained pace. Their real value is trend, not snapshot: three sprints of stable velocity is a forecasting instrument, one sprint of anything is noise. The classic failure is treating velocity as a performance metric to push upward, at which point estimates inflate to match and the instrument reads whatever leadership wants. Measure with it, never manage by it.
Earned Value Management: the honest accountant
EVM prices work: planned value, earned value, actual cost, and from them schedule and cost variance. It answers the question the other methods dodge, whether you are getting the work for the money, and answers it in currency. On top of milestone tracking it catches the quiet failure where the schedule looks fine because everyone is burning overtime and budget to keep it looking fine. The price is discipline: EVM needs a baselined plan and real cost data, and half-maintained EVM is worse than none, because it produces precise-looking nonsense. I reserve it for budget-sensitive fixed-scope work, and skip it for exploratory product streams where the baseline would be fiction anyway.
How I actually choose
Three questions pick the method. What shape is the work? Fixed-scope with contractual dates leans milestones, possibly EVM on top; continuous product work leans burndown and velocity. Who consumes the number? Sponsors get milestones and money, teams get tasks and trends; giving a steering committee a velocity chart mostly generates questions you will regret answering. What can I afford to maintain? Every method costs upkeep, and a simple method kept honest beats a sophisticated one kept partially.
Most of my real projects run two layers: milestones for the outward-facing spine, burndown or task flow for the inward-facing weekly truth, and the PM reconciling the two, which is where the actual craft lives. When the inner layer says trouble and the outer layer still says green, that gap is your early warning. I wrote in Why Projects Fail that progress reported in hope is a root cause; the measurement method is the antidote, but only if you pick one whose lies you know how to detect. Every method has a blind spot. The job is knowing yours.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.