159 tracked work items, scoped and sequenced for a database automation program.

The development team understood the target state and could not express it as something the sponsor could fund or track. Requirements lived as conversations, there was no work breakdown, no sequence, and no way to report progress that meant anything to the person approving the budget. That is a common and expensive place for a technical programme to stall: the work is understood by the people who will do it and invisible to the person who has to pay for it.

The engagement decomposed the programme into 159 tracked work items, each with acceptance criteria, and sequenced them into phases with the dependencies between them made explicit. Nothing was built during that exercise. What it produced was a plan a VP could fund in stages and measure against, which is what unblocked the work rather than any particular technical decision.

The sponsor was a VP with limited appetite for technical detail, and the client's database and platform developers owned the technical design and implementation throughout. The value added in the middle was translation: turning a database change-management target into acceptance criteria and a status format the sponsor could read without an interpreter, and turning the sponsor's funding and reporting needs into a structure the developers could work against.

Establishing that reporting cadence up front is what let continued investment be approved phase by phase, on evidence, rather than argued for in a single large ask. A programme that reports in a language its sponsor trusts is one that keeps its funding; one that cannot is where good technical work stalls for reasons that have nothing to do with the technology.

A work item without acceptance criteria is an intention, and intentions cannot be funded or checked off with any confidence. Attaching criteria to each of the 159 items is what turned a shared understanding into something a sponsor could actually buy: for every item there was a stated condition for calling it done, which is the difference between reporting that work is progressing and being able to show that it is.

That same discipline is what made the status format legible to a non-technical VP. Progress reported as items meeting their criteria, phase by phase, is a claim a sponsor can trust without having to evaluate the engineering underneath it. It also protects the developers, because a definition of done agreed in advance is far harder to argue with after the fact than a vague sense that more should have been finished by now. On a programme funded in stages, that clarity is not a nicety; it is the thing that keeps each stage's approval from turning into a renegotiation of the last one.