An organisation funds engineering through annual project business cases: each initiative is approved with a budget, a team assembled for it, and a closure date. The architecture team notices the same four problems in every review. What is the funding model buying, and what is it paying?

What is gained

Project funding is not irrational. It gives finance a defensible allocation, a named sponsor per pound, a decision point at which work can be stopped, and a comparison between initiatives that competes for the same money. In a regulated or capital-intensive business, capitalisation rules often make it the only model the accounting policy supports. Any argument for change that does not acknowledge this loses in the room where the decision is made.

What is paid

The architecture consequences are structural and predictable, which is why the same four problems appear in every review:

• No owner after closure. The team is disbanded on the closure date and the system it built has no funded maintainer. Ownership migrates to whoever touched it last, and the register of unowned systems grows by one per completed project.
• Integration as a project boundary. Each project funds what its business case named, and anything shared sits between two business cases. The seams between projects are where nobody's budget lives, so the integration is built twice, badly, or by whichever project ran last.
• Technical debt as a rational choice. A project judged on delivering scope by a date is correctly indifferent to the cost of maintenance after closure. The debt is not a failure of discipline; it is the incentive working.
• Architecture as negotiation rather than design. A platform capability has no business case of its own, so it must be smuggled into one, which means the estate's shared capabilities are shaped by whichever project could afford them.

Conway's law, from Conway's 1968 paper, describes the structural half: the system mirrors the communication structure, and a funding model that creates temporary teams around temporary scopes produces temporary systems with permanent lifespans. Choose the model by asking whether the thing being funded has a finish line, and expect the arithmetic to be brutal: 20 projects a year closing with no funded owner adds 20 systems to the unowned register annually, against a support function that grows by perhaps 2 people.

When the cost becomes visible

Three to five years in, when the number of systems with no funded owner exceeds the organisation's capacity to support them, and the first urgent cross-estate change — a security patch, a regulatory deadline, a vendor's end of support — has to be delivered through dozens of unfunded conversations. The run-cost line in the budget grows faster than the change budget and nobody can name which projects caused it.

How to keep the option to reverse

You will rarely be allowed to replace the funding model, so change the smallest things that remove the structural effects:

1. Make the closure gate require a named funded owner with a run budget for the following year. One line in the business-case template changes the behaviour of every project without touching the funding model.
2. Fund platform and integration as standing products, even if everything else stays project-funded. These are the capabilities whose benefits appear in other people's cases and therefore never get built on their own.
3. Carry a run-cost estimate in every business case, so the comparison between initiatives includes the liability each creates rather than only the delivery cost.
4. Keep the long-lived teams long-lived. Where a capability is genuinely permanent, assign a persistent team and let projects pass through it. This is the change that does the most and is hardest to get.

When this is the wrong answer

For genuinely finite work — a data-centre exit, a regulatory remediation, a migration with an end state — the project is the correct shape and a standing team would be make-work. The failure is not project funding; it is project funding applied to permanent things. The test is whether the thing being funded has a finish line that someone can describe. If it does not, funding it as a project guarantees an unowned system at the end.