Monitoring Deliverables
Task lists measure activity. Deliverables measure whether the project is producing anything. Those two numbers diverge quietly for months, and by the time they reconcile, the date has already moved.
In short
- Measure deliverables accepted, not tasks closed. Only one of those two survives contact with a deadline.
- Agree a definition of done once, and apply it to everything.
- The distance between “built” and “accepted” is real work — review, test, fix, sign-off — and it is where schedules disappear.
- Statuses should describe the work, not the person. The moment they judge people, they stop being true.
The gap between closed and done
A closed task means somebody stopped working on something. That is genuinely useful information and it is not the same as a result existing. Between the two sit review, testing, fixes, and someone with standing agreeing the thing meets what was asked for — and none of that is captured by the task being closed.
That last observation is the practical payoff. A deliverable board doesn’t just give an honest total; it shows you the gate where work is accumulating. Here it is review and sign-off, which means the constraint is not the people building things — adding another builder would make the pile-up worse. Same insight as a Kanban board with WIP limits, arrived at from a different direction.
Agreeing what “done” means, once
Two different things need defining, and confusing them causes arguments:
| Term | What it covers | Written when |
|---|---|---|
| Definition of done | The standard every item must meet: reviewed, tested, documented, deployed. One list, applies to everything. | Once, at the start of the project |
| Acceptance criteria | What this particular deliverable must do. Specific and observable. | Per deliverable, during planning |
A workable definition of done is short and boring. For a software project it might be: code reviewed by someone else, automated tests pass, deployed to the test environment, documentation updated. Four lines. It takes twenty minutes to agree and it removes the recurring conversation about whether something counts.
The test of whether yours is real: could a person outside the team read it and check an item against it? If it contains words like “properly”, “fully”, or “as required”, it isn’t there yet.
Statuses that carry information
Two states — open and closed — hide the entire middle of a deliverable’s life. A small number of states carries much more:
- To do — agreed, not started.
- In progress — someone is actively working on it right now. Not “assigned to them”.
- Waiting — work has stopped and the reason is outside the person doing it. This is the state most tools lack, and the one that matters most: waiting is invisible in effort terms and enormous in elapsed time.
- In review — built, awaiting someone else’s judgement.
- Done — meets the definition of done. Nothing else qualifies.
Five is usually the right number. Fewer hides the truth; more means people guess, and guessed statuses are worse than absent ones.
One rule worth defending: “In progress” means today. A task that has been in progress for three weeks is either much bigger than estimated or actually waiting, and either answer is useful. If the state is allowed to mean “this is mine at some point”, the board stops showing flow.
Watch the gates, not just the totals
A few things worth checking weekly, all of which are leading indicators rather than confirmations:
How long items sit in review
Rising review age is the earliest visible sign of a project slipping, and it’s almost never in anyone’s status report. Review capacity is a resource; treat it like one.
How many things are waiting
A count of blocked items, with what each is waiting on. Most delay is waiting rather than working, and it is the one category a manager can usually do something about immediately.
Whether anything reached “accepted”
If nothing has been accepted in three weeks, that is a fact regardless of how busy the team was. It usually means items are too big rather than that people are slow.
Whether items reopen
Things marked done and then reopened mean the definition of done isn’t being applied. A rising reopen rate is a quality signal arriving before the quality problem does.
Making it cultural, not clerical
All of this depends on people updating states honestly, which depends entirely on what happens when they do. Three things determine it:
- Marking something blocked produces help. If it produces a question about why you didn’t foresee it, the state stops being used.
- Statuses describe work, never people. The moment a board is read as a productivity ranking, everything on it becomes defensive.
- Nobody is asked for status in a meeting. Asking tells the team the board doesn’t matter, and they will maintain it accordingly.
And one that costs nothing: when someone flags a problem early and it saves the project a week, say so publicly. It is the cheapest way to buy accurate data for the rest of the project.
How this looks in AB
In AB Projects, the gap between “the task is closed” and “the deliverable is done” lives in the task’s status field and progress percentage rather than a single checkbox. Subtasks roll up into the parent, so a “feature complete” status reflects what is actually finished underneath rather than what somebody typed. The Calendar shows what is slipping before anyone has to write a report about it.
Two habits that turn that into the diagram above:
- Create one task per deliverable, not just per activity. The activities become its subtasks. The parent then is the row in the gate chart, and its status is the honest number.
- Make acceptance require someone else. A deliverable task closed by its own author has passed four gates, not five. Requiring a different person to move it to done is a one-line convention that makes the whole board trustworthy.
Terms used on this page
- Deliverable
- A specific, verifiable output the project hands over. Deliverables are nouns; the activities that produce them are verbs. More →
- Definition of done
- The standard every item must meet before it counts as complete — reviewed, tested, documented. Agreed once, applied to everything. More →
- Acceptance criteria
- The observable conditions this particular deliverable must satisfy. If a criterion contains an adjective, it isn’t one yet. More →
- Cycle time
- How long an item takes from being started to being done. A far better predictor of future delivery than an estimate, because it is measured rather than guessed. More →
- Leading indicator
- A measure that moves before the outcome does — review age, blocked count. More useful than one that confirms what already happened. More →
- Blocker
- Anything preventing work continuing that the person doing it cannot resolve alone. Invisible in effort-based reporting, enormous in elapsed time. More →
Related reading
5.2 Kanban Boards
Seeing where work accumulates, and limiting how much can be in flight at once.
3.1 Defining Project Scope
Where acceptance criteria are written, while they still cost a conversation.
6.2 Issue and Change Management
What to do with what you just noticed, so the loop doesn’t stop at observation.