What happens when the champion leaves
Most abandoned systems did not break. They lost the one person who owned them. Inside an active build with a family-run distributor, the ownership structure that survives a reorganization has three names on it, not one.
The distributor we are building for now is a family company — a Polish importer of forklifts from a major Asian manufacturer, with a second brand planned for a later phase. The father has the final word on budget. The son runs the project day to day, answers our questions, and pushes when something stalls. And the IT lead, who has owned the company's Comarch ERP for years, sits in on every architecture decision we make. The sales team quotes in Word and Excel; the build runs in two-week sprints; the three of them show up to the demos.
None of that arrangement was designed by us. It took a few sprints to understand that it mattered more than any technical decision in the build.
The systems we get called about
Before this engagement, most of what we knew about ownership came from the other side — from being asked to look at systems that had already died. The pattern across those conversations was consistent enough to be uncomfortable. The system worked. The code ran, the integrations held, the data was intact. Somebody demonstrated it to us without errors. And nobody in the building had opened it in months.
The post-mortems these companies had written for themselves blamed the usual suspects: the model drifted, the integration was fragile, the vendor disappeared. Sometimes true. But in roughly half the cases we have looked at closely — and this is our field observation, not a statistic anyone has published — the actual sequence was organizational. The person who had wanted the system was promoted, or left, or got handed a different priority. The system did not fail. It was orphaned, and an orphaned system drifts out of relevance within a quarter.
Where the single champion breaks
The research on this is thinner than it should be. Project-management literature has measured sponsorship during delivery — PMI's research with BCG found one in three unsuccessful projects failed to meet goals because of poorly engaged executive sponsors — but that measures projects being built, not systems being run. What happens to a working operational system after its owner leaves is close to unstudied; a 2001 case study of a champion departing an expert-systems project is among the few direct treatments in the literature, and it is old enough to vote. That absence explains something practical: no vendor proposal prices ownership continuity, because nobody selling software has a study to point at. The risk lives in the gap between what gets measured and what actually kills systems.
A single enthusiastic champion is genuinely the fastest way to deliver a project. Decisions come from one desk, priorities do not compete, and the vendor always knows who to call. We like working with champions. The trade-off is what happens after go-live: speed during the build is bought with fragility during the years that follow, because everything the company knows about the system — why it exists, what it needs quarterly, who to call — lives in one head that can be promoted out of the room.
What the three roles actually cover
Watching the family structure work, sprint after sprint, made the pattern legible. It is not that three people are better than one because three is more than one. It is that the three roles cover three different ways a system dies.
The father — the financial owner — is budget continuity. The system survives the annual planning conversation because the person who approves spending was in the room when it was justified. The son — the operational champion — is daily ownership: the person who notices that quotes slowed down this week, that a salesperson stopped using the tool, that the new price book has not been loaded. The IT lead is institutional memory on the technical side: he owns the ERP integration, knows why every architectural decision was made, and will still be there if either of the other two changes roles. Each one is a single point of failure that the other two cover.
The operational owner of a system is part of its architecture, not external context. A vendor can write the cleanest code of their career, and it changes nothing about whether anyone opens the application in month nineteen. This is also why the vendor's side of the question — who is on call when the system breaks — is necessary but not sufficient. The on-call rotation answers who fixes the system. It does not answer who wants it, quarter after quarter, inside the building that paid for it.
The question we ask in discovery
Somewhere in every discovery now, we ask a version of: who operates this in eighteen months, if the person running this project is promoted or leaves? The reactions are diagnostic. Some buyers name a second person immediately. Some point at the IT lead. And some go quiet — which is not a reason to walk away, but it is a finding, and it is better found before the build than after.
What a durable answer looks like can be written on one page:
| Role | What they own | What breaks without them |
|---|---|---|
| Financial owner | Budget line, renewal decision | The system loses the planning conversation and the retainer quietly lapses |
| Operational champion | Daily use, adoption, priorities | Nobody notices usage slipping until it has stopped |
| Technical owner | ERP integration, data, vendor access | Every change becomes an archaeology project |
| Vendor | Availability, updates, engineering | Everything above still holds — and the system still dies if the three internal roles are empty |
The test that goes with the table is short: could two people who are not the vendor run one full price-list cycle — load it, review it, approve it — using only the runbook and their own permissions? The update path is specific enough that this is a real test, not a thought experiment. If the answer is no, the system has one owner, whatever the org chart says.
What we know and what we do not
The honest frame on the family engagement: it is an active build, not a shipped case study. There are no production numbers to report, and we will not invent any. Whether this three-role structure survives an actual succession — the day the father hands over the company, or the son takes on a bigger role — has not been tested yet, and we do not know how it will go.
What we do know is what the absence of this structure looks like, because we have seen it from the rescue side more than once. And we no longer treat "the vendor will take care of it" as an answer to who operates the system. The vendor covers the last row of the table. The other three rows are the client's, and naming them costs nothing except one uncomfortable question in discovery.
After enough engagements on both sides of this — the builds with three named owners and the rescues with none — the principle is hard to unsee: what a system costs over five years is set by who maintains the data and who operates it, and this is the ownership half of that number. A quoting platform whose owner is named survives its first reorganization. One whose owner is implied survives until the first one.