Eleven sprints
Fifty change requests, each with a decision attached
An offline-first enforcement app across two platforms, where the critical dependency was an interface the client was writing themselves. Every scope change got a costing and a recorded decision — which is why the overrun conversation was survivable.
- Each costed and each with a recorded decision and decision-maker
- 50 change requestsEach costed and each with a recorded decision and decision-maker
- Two mobile platforms, offline-first, over six months
- 11 sprintsTwo mobile platforms, offline-first, over six months
- Tracked against a dependency the client owned, not us
- 20+ blockersTracked against a dependency the client owned, not us
The client
A US parking enforcement operator building patrol software for officers working in the field — plate recognition, citation issuing, and a complete offline mode — with the client's own engineer writing the interfaces our app depended on.
The engagement
Eleven two-week sprints across two mobile platforms over six months, running against a client-owned interface on the critical path, with change requests priced individually.
The problem
A long build with an active product owner generates a continuous stream of good ideas, and the critical dependency here — the interfaces the app had to talk to — was being written by the client's own engineer. That combination is where projects lose the ability to explain themselves: scope grows without a paper trail, delays accumulate against a dependency nobody logged, and by the time the date slips there is no shared account of how it happened.
What I did
I made every change and every dependency leave a trace. Each incoming request was costed and carried to a decision — approved, cancelled or on hold — recorded against the meeting and the person who made it, so six months later the conversation was about a register rather than about recollection. The client-side interface work was tracked as a blocker register with the same seriousness as our own backlog, because a dependency you do not log is a dependency you will be blamed for. The schedule risk from unfinished offline interfaces was stated to the client on a call while it was still a risk, not raised as an explanation afterwards. And I kept both an internal report and a client-facing one, because there are legitimate reasons for the two to differ and no legitimate reason for that difference to be accidental.
What was built
A change-control discipline scaled to fifty requests — each costed, each with an approved, cancelled or on-hold decision recorded against the person who made it — alongside a blocker register tracking the client-side interface work our critical path depended on, an earned-value book, and both an internal and a client-facing report so the difference between them was a deliberate choice rather than an accident.
On the table at the end
- Change request register: fifty items, costed, with recorded client decisions
- Blocker register against client-owned interface work
- Earned-value book and profitability tracking
- Internal and client-facing status reports
- Requirements documentation, question register and production test setup
What it changed
Kept scope, money and blame separable across a long build: every change carried a costing and a recorded client decision, every dependency on the client's own engineer was logged against a name, and the schedule risk was stated on a call rather than discovered at the deadline.
How it ran
- 01
Cost every change
Each request estimated before discussion, so the client is choosing between a feature and a number rather than approving in the abstract.
- 02
Record the decision and the decider
Approved, cancelled or on hold, attributed to the meeting and the person — the register becomes the shared memory.
- 03
Log the client's own dependencies
A blocker register for the interface work the client was writing, tracked as rigorously as our own backlog.
- 04
State the risk before it lands
The schedule exposure from unfinished offline interfaces raised on a call while it was still preventable.
- 05
Two reports, deliberately
Internal and client-facing views maintained separately, with the difference between them a considered choice rather than a drift.
Other work
All case studies →- Software services
What the projects actually earned, once someone put cost next to revenue
Margin was assumed to be about half. Reading revenue, cost and hours together showed a spread from a third to three quarters — and one project that had quietly overrun its ceiling without a change request.
- Health tech
Taking a live product off another vendor in two weeks
A care-coordination platform changed hands mid-flight. Two weeks to take the credentials, audit what we had inherited, fix what was broken and stand up an environment we controlled.
- Portfolio management
Earned value that survives an empty project
Portfolio dashboards go green because the data model rewards going green. I built one that measures in hours, sorts by trouble, and refuses to report a number it does not have.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.