01
Related
Where to read next on the same subject.
02
Short answer
An engagement runs on a written split of ownership: the client team owns policy and acceptance decisions, data provisioning, user feedback, and operations after transfer; the delivery team owns architecture, implementation, verification, and incident response during the build. Both teams keep one shared record, updated weekly, and any change to the split is a written decision in a review.
Every stalled project I can remember had the same symptom, and it was never technology. Someone would ask who decides whether the system goes live for the northern region, and the answer would be a shrug wearing a job title. Or the reverse: four people all certain they decide, none of them talking to each other. The engineering was fine in both cases. The ownership was fog.
03
The split, and why each side gets what it gets
The client team owns the decisions that require standing in the business. Whether an exception is acceptable, whether a customer name may appear in a demo, whether the target is still the right target. These calls need context that lives in the business and changes with the quarter, and no delivery team can hold them honestly. The client team also owns data provisioning and access, because the builders should never hold keys to systems they do not operate. And it owns user feedback and the operating of the system after transfer, because the people who will live with the system are the only credible judges of whether it works.
A named product owner with actual time sits above all of this. "Actual time" is the operative phrase. I have watched engagements where the product owner was nominal, a name on a chart who could spare an hour a month, and every decision queued behind them until the calendar drowned the momentum. The split is not real until the name on it has hours attached.
The delivery team owns the engineering calls: architecture choices, implementation, tests, releases, and the response when the build breaks. It owns verification, which means proving the system against the acceptance rules rather than asserting it works. It owns the documentation and runbooks, because the people who built the thing write the best warnings. And it owns a clean transfer, which is the delivery team's final deliverable and the one most often skipped.
04
The shared record holds the middle
Between the two lists sits one document that both teams read and both teams update. Scope, targets, and acceptance rules. Decisions with dates and reasons. Open risks and exception rules. Test and release records. And the most underrated page in the whole file: who is blocked on whom, refreshed every week.
The record earns its place by being boring. More than a project management ceremony, it is where the two teams keep their shared memory, and its test is simple: a person joining either team can read it in twenty minutes and know what is happening and why. When the record goes stale, the split decays with it, and decisions start living in chat threads where they cannot be found when they matter.
Changes to the split are decisions too. If the client team wants to take over releases early, or the delivery team needs a business rule clarified before build continues, that change goes through a review and lands in the record with a date. The alternative is drift, and drift in ownership always settles toward whoever shouted last.
05
The cadence that keeps it honest
Thirty minutes a week, same time, both teams. What moved, what is blocked, which decisions are needed, and the record updated live in the meeting rather than afterward from memory. The discipline of updating in the room matters more than it sounds; the version written afterward is the version that forgets the disagreement, and the disagreement is the valuable part.
Per release, the demo runs against the acceptance rules instead of slides, and the open risks get read aloud before anything ships. Per phase, the acceptance review happens with the signing owner present, and scope changes get priced against the target in the same session. None of this is heavy. All of it is schedulable.
06
When the split bends
Real engagements bend the split, and the honest versions do it in writing. A client team with strong engineers may take over parts of the build early, which is excellent, provided the verification duty transfers with the code. A delivery team may hold operational duties longer than planned when the receiving team is mid-reorganization, which is fine, provided the extension has an end date. The failure mode is never the bending. It is the bending that nobody wrote down.
Watch for the two classic slides. The client team that delegates everything, including the decisions, and then resents a system that answers questions nobody asked. And the delivery team that grabs everything, including the operations, and builds a beautifully engineered system that no internal team knows how to run. Both are ownership failures dressed as enthusiasm.
07
What the split buys
By day 90 the test is quiet: decisions arrive without chasing, the record answers the "why" questions, incidents route to the right desk on the first try, and the transfer at the end is a formality because the ownership was never fuzzy. The split buys that operating state: a system everyone can see, and nobody has to guard.
08
Reading the record in reviews
The record earns its keep at the reviews. A release demo that opens with the acceptance rules, on screen, from the record, cannot drift into a feature tour. The reviewer sees the rule, the measured result, and the delta in one frame. When the number is short, the conversation is about the number, in the open, with both teams looking at the same cell. That framing sounds small and it changes the temperature of every review, because the record makes disagreement specific.
The blocked-on-whom page is the one I check first in any troubled engagement. Ownership fog shows up there before it shows up anywhere else: three items blocked on a decision that has no owner, or a data request waiting on a team that does not know it was asked. The weekly cadence fixes small blocks before they become schedule risks, and the fix is usually one sentence and one name.
Escalation is the record's failure mode handled in advance. When two teams read the same row and draw different conclusions, the dispute moves up one level with the record attached, and the resolution lands back in the row with a date. What never works is resolving it in a side channel and updating the record afterward, because the side channel version and the record version will differ, and the difference is where the next dispute germinates.
The record also protects people, which nobody mentions at kickoff and everybody appreciates by month three. A decision made in a review, with its reasoning and its date, cannot be re-litigated as a surprise. Both teams work better when the "why" has an address, and the address is a page both of them can read.
09
Related
The selection guide shows where the split starts, at the scoring table. The handover guide describes the transfer in detail. The Lenskart case study shows a platform program where the operating teams held their piece of the record from the first month.