Percent complete measures how much of a plan has been carried out. Progress means movement toward an outcome. Those are different quantities, and a project at 70 percent complete can be at zero percent progress toward the goal that justified funding it.
The number is popular because it is cheap. One field, one figure, one colour on the slide. It rolls up cleanly, compares across projects that have nothing in common, and fits in a cell. Every property that makes it convenient also makes it lossy.
What the number averages away
A percent-complete figure is an average across every task in a project. Averages hide distribution, and in project work the distribution is the whole story.
Consider two projects both reporting 70 percent. In the first, the remaining 30 percent is documentation and a release checklist. In the second, the remaining 30 percent is the integration nobody has started, blocked on a decision that has been open for two weeks. The same number describes a project that is nearly done and a project that has not yet met its real problem.
The average also hides which piece moved. If a project goes from 65 to 70 percent in a week, that could be the critical path advancing or six trivial tickets closing while the critical path sat still. Both produce the same delta. Only one is worth reporting.
And it hides why. The reason a task stalled lives in a comment thread, a Slack message, or something said at the end of a call. None of that travels with a percentage. The status arrives without the context that would make it actionable, which is the same compression problem that afflicts every status report.
The integration that copies one number
Most goal and strategy tools now claim a Jira or Asana integration. In a large share of the category, that integration is a scheduled copy of one field: the project's overall percent-complete, dropped into a progress bar on the goal.
That design inherits every weakness above and adds one more. It assumes a single project is the driver of a goal. In practice, a goal moves because of the intersection of work across several projects and teams, plus decisions taken outside any project tool at all. A goal wired to one project's rollup will look healthy while the work that actually determines the outcome sits somewhere the sync never looks.
The alternative is syncing at task level: each task with its own status, its own history, its own comments, mapped to the goal it serves. That is more work to build and considerably more useful to read, because it preserves the three things the average destroys. Which item moved. When it moved. Why it stopped. This is what deep two-way integrations are for, and the difference between a real integration and a number copy is covered in export vs integration.
Why teams keep the number anyway
Percent complete is not useless. It answers a legitimate question: how much of the agreed plan has been carried out? For a project with a fixed scope and a hard deadline, that is genuinely what a delivery manager needs.
The failure is one of transfer. The number gets lifted out of project management, where it means something specific, and put in front of a leader making a resource decision, where it is asked to answer a question it was never built for. The leader is not asking how much of the plan is done. They are asking whether to keep funding it, and that turns on whether the goal is still live, whether the hard part is behind or ahead, and whether the people are still on it.
What to read instead
For a resource decision, three inputs beat the percentage, and none of them require anyone to write a new status update if the work data is connected:
Pace against the target. A goal running behind pace tells you more than a project running ahead of plan. Pace to plan compares where the number is against where it needed to be by now, which a completion percentage cannot express.
Movement history. A KPI that has drifted for three weeks looks nothing like one that tipped over this morning, and both can show the same current value. History separates them.
The unresolved thread. The blocker raised in a comment two weeks ago, still open. That single item usually predicts the next slip better than any rollup.
The test
Take any project reporting a healthy percentage this week. Ask which specific task moved it, and which goal that task serves. If answering takes more than a minute of clicking, the percentage is doing work it cannot do, and the gap between effort and goal is being papered over by a number that fits neatly in a cell.