Deliverable Tracking

This is a register of every deliverable a delivery team owes: who is producing it, which milestone needs it, and where it sits in its lifecycle. It lives inside the Ionic client portal, and it was live four days after the first vision note. This page is about the problem it was built for: a team with five hundred things to do and no way of telling which one comes next.

I run the operational workstream on a transport ticketing programme for a public-sector client. On paper that was four plans: live trials, business process design, service management and partner readiness. In practice it was one plan, with too many moving parts for anyone to hold in their head. The source material was a strawman workbook and a long Word document. Both were comprehensive, and both were impenetrable. Any one person needed a fraction of the rows and a fraction of the columns. A partner could not answer "have you done everything for the trial?", because nobody could say what "everything" was.

So I built a register. I wrote a vision note first and argued with it through four versions in a day (one was drafted from a voice call on the way to the shops). The first live register followed four days later. It has been in daily use by the delivery team since, through about 118 pull requests, and it is maintained as much by conversation with Claude as by hand.

4dfrom vision note to live register

~560deliverables tracked

21MCP tools for reading and updating it

~118pull requests

01What it does

One register

Every deliverable is in one master table, whether it's a business process, a report, a partner ask, a decision or a document. Each has a producer and a custodian, because the person doing the work and the person keeping the record current are often different people.

Hierarchy that can't hide a red

Every deliverable has exactly one parent, and a parent's state is derived from its children. An eighty-per-cent-green parent can't hide one red blocker.

Same three stages for everything

Every deliverable goes through Definition → Implementation → Verification. Different kinds of deliverable interpret the stages differently but can't change them. Any stage or approval can be skipped in one click, which keeps the tool light.

Milestones, not dates

A deliverable is "needed by" one or more milestones and carries no date of its own. Readiness is measured per milestone with drill-down, and "ready" and "proven" are two separate readings.

Sprints and a stand-up board

Work is chopped into fortnightly increments with small, medium and large sizing. The stand-up screen shows each person only their problems: stuck, not started, blocked or overdue.

Views for every audience

These include a filtered register, priority lanes, a board where blocked is a state rather than a column, reports, shareable saved views and a plan-on-a-page.

Maintained by conversation

Through MCP, Claude reads and writes the register. Hand it a meeting transcript and it proposes the updates. "Set every record in this set to X" is a sentence, not a screen.

Everything on the record

An append-only audit trail covers every change, by a person or by AI, with undo.

Cloudflare Workers D1 MCP server Portal zero-trust access TypeScript

02Control of the work, not the people

To be precise about "control of the workload": this is not a capacity tool. Nothing in it holds hours or effort estimates, and that is deliberate. It isn't Jira, and it isn't Microsoft Project. There's no critical-path Gantt and no automation engine. The team had kept momentum by working to "what are we doing next week", and I wasn't going to replace that with a machine for reporting lateness.

What it does control is the body of work. You can see the whole of it, including the gaps, which were previously invisible. You can ask the question that actually matters: not "are we doing everything?" but "what's the minimum we need to get through the next milestone?" And it turns five hundred rows into a Monday morning someone can act on.

You should arrive on a Monday with a list of ten things, not five hundred. That's the whole point of the change.

It is also honest about what it knows:

Contradictions are surfaced, never blocked. The register's job is to record what people said, including when it disagrees with itself.
"Ready" and "complete" are kept as two readings. Both are true, and the gap between them is the workload.
No "Confirmed by" field. I refused to add one, because it would have asserted confirmations nobody had made. The tool shows "last touched by" from the audit log instead.

03The maintenance problem is the whole problem

Every tracker dies the same way: updating it becomes a chore, so people stop, so it lies, so people stop reading it. I said at the outset that this would not be an exercise in team members keeping endless checklists up to date. The answer was to make it so quick to maintain that maintaining it is no burden. The levers are:

class templates
bulk edit
staged import with a preview
AI doing the clerical work

That last lever brings its own risk. AI-generated material with thin human review is a house of cards. The structure is the antidote: the hierarchy, the gap view, the audit trail and the plain refusal to let a summary hide a red.

The build had lessons of its own. Thousands of green tests didn't catch that the whole portal was rendering in browser quirks mode. A two-hundred-line browser harness found four faults the suite couldn't see. Tests prove the logic. Only looking at it proves the page.