Most delivery tracking measures activity and calls it progress. Tickets moved, points burned, percentage complete. All of it is real data. Almost none of it answers the question a Delivery Manager is actually accountable for, which is whether this will land, in the shape that was agreed, on the date that was promised.
The gap between those two things is where delivery goes wrong quietly, weeks before it goes wrong loudly.
Why percentage complete lies
A team reports eighty percent. What that usually means is that eighty percent of the identified work is done. The number says nothing about the twenty percent, and the twenty percent is not a random sample. It is systematically the hardest, least understood, most dependent work, because that is the work people defer.
The last twenty percent also contains all the integration, all the edge cases, and all the defects that have not been found yet because the feature has not been exercised end to end. This is why projects sit at ninety percent for a third of their duration.
A completion percentage that has been rising steadily and smoothly. Real delivery is lumpy. A smooth line usually means the estimate is being back-fitted to the schedule rather than measured against reality.
What is actually worth tracking
Four questions, each with an answer that is checkable rather than reported.
- Is the scope still what we agreed? Not whether scope changed, scope always changes, but whether the changes were decided or absorbed. Absorbed scope is the single most common cause of a missed date.
- Is the work covered? Which requirements have tests mapped to their acceptance criteria, and which have none. This is a fact, not an opinion, and it can be checked without asking anyone.
- What is failing, and how badly? Open defects by severity, and specifically whether any sit on the paths that carry money, identity, or data integrity.
- What is blocked, and on whom? With a date attached. A blocker without an owner and a date is a note, not a tracked item.
Notice that three of the four are answerable from artefacts rather than from a status meeting. That is deliberate. Tracking that depends entirely on people self-reporting is tracking the optimism of the team, which is a real signal but not the one you want.
Traceability is the tool, not the paperwork
Traceability has a reputation as compliance overhead, which is fair when it is maintained as a separate document nobody reads. Maintained as a live link between requirement, test, result, and defect, it is the only thing that answers the questions above without a meeting.
When a requirement changes in week six, the traced view tells you immediately which tests are now invalid and which defects were raised against behaviour that no longer applies. Without it, somebody spends two days reconstructing that by hand, and gets it partly wrong.
Key takeaways
- Completion percentage measures identified work, and the remaining work is never a random sample of the whole.
- Absorbed scope, the kind nobody decided on, is the most common cause of a missed date.
- Coverage against acceptance criteria is a fact you can check, unlike a status report.
- A blocker without an owner and a date is a note, not a tracked item.
Escalating early, and what makes it possible
The value of the role is concentrated in a small number of moments: the point where you can still change the outcome. That is almost always earlier than it feels, and the reason people escalate late is rarely courage. It is evidence.
Nobody wants to raise an alarm on a hunch. Give a Delivery Manager a coverage gap on a critical path, a defect trend that has turned, and a scope delta nobody approved, and the conversation stops being a hunch. It becomes a decision the Product Owner can make while options still exist.
Working with the other three roles
Business Analyst: the source of truth on what was agreed. When scope is disputed, the requirement and its acceptance criteria settle it, which is why their quality is a delivery concern rather than a documentation one.
QA Engineer: the source of coverage and risk signal. The useful question is not how many tests passed, but what remains unverified and whether it matters.
Product Owner: the person who decides what happens when something has to give. The Delivery Manager's job is to make sure that decision is made deliberately and early, rather than by default at the deadline.