From Project Funding To Product Funding

There is a class of transformation problem that cannot be solved at the team level, no matter how competent the team or how skilled the coach. A team cannot adopt a persistent mission if it is funded to exist for nine months. A Product Owner cannot prioritise on value if the scope was fixed in a business case eighteen months before the first line of code. A team cannot respond to what it learns if responding means reopening an approved budget through a committee that meets quarterly.

The funding model sits upstream of structure, which sits upstream of process. Most transformation programmes work on process, occasionally reach structure, and almost never touch funding — partly because funding belongs to finance rather than to technology, and partly because the people running the transformation correctly judge that opening the question will slow everything down. So the programme proceeds, and eighteen months later the organisation has better ceremonies attached to the same annual planning cycle, the same temporary teams and the same fixed-scope business cases. The delivery numbers have not moved, and nobody can say quite why.

This article is about what the funding conversation actually involves, because it is more tractable than it looks. The objections finance raises are usually legitimate, specific and answerable, and they are rarely the objections technology leaders anticipate.

What project funding does to delivery

A project is, by definition, temporary. It has a start, an end, a scope and a budget approved against a forecast of benefits. That structure has real strengths — it forces an explicit case for spending, it creates a point of accountability, and it allows a portfolio to be compared and ranked. In a world of long-lived capital assets and predictable requirements it is an entirely sensible mechanism.

Applied to software, it produces a set of consequences that are structural rather than accidental.

Teams are assembled and disbanded. People are allocated to a project for its duration and reallocated at the end. Every disbandment discards the domain knowledge the team accumulated, which is usually the most valuable thing produced. The next project in the same domain starts by rebuilding it, slowly and incompletely.

Scope is fixed at the point of maximum ignorance. The business case is written before the work begins, which is when least is known. Everything learned afterwards is, in governance terms, a variance to be explained rather than information to be used. This is the mechanism that converts an agile delivery process into water-scrum-fall: iterative build, fixed scope, fixed date.

Success is measured as delivery to plan. Because the benefits accrue after the project closes and the project manager has moved on, the practical measure becomes on-time, on-budget, in-scope. An organisation that measures this will reliably get it, and will get it by delivering things nobody wanted rather than by admitting that the plan was wrong.

Nobody owns the product afterwards. Maintenance falls to a support function or whichever team can be found. Technical debt accumulates because no funded party has an interest in the asset's long-term health, so the next project inherits a worse codebase, costs more, and justifies itself partly on the difficulty created by its predecessor.

Allocation creates dependency. Because people are allocated to projects rather than teams owning systems, most changes require people from several allocations, which manufactures the coordination load described in the-dependency-mathematics-of-scaling.

The business case ritual deserves particular attention, because it is where the organisation's relationship with truth is set. Everyone involved knows the benefit forecast is a bid rather than an estimate — it has to clear a hurdle rate, so it is constructed to clear the hurdle rate — and that the cost estimate contains a negotiation buffer. The document's real function is to secure funding, and its accuracy is rarely revisited after approval. An organisation that runs on this ritual has trained a generation of leaders that forecasts are political instruments, which then makes honest forecasting in delivery almost impossible.

What product funding actually is

The alternative is not "spend without control". It is a different control point.

Under product funding, you fund a persistent team or small group of teams against a domain and a set of outcomes, for a rolling period. The team owns its product continuously — build, run, improve, retire. Money is committed for a horizon, typically annually with quarterly review, and the scope is not part of the commitment. What is committed is the capacity, the mission and the outcome measures.

The governance question changes from "did this project deliver the agreed scope?" to two better questions, asked at intervals: is this product still worth the capacity we are giving it, and is the team demonstrating progress against the outcomes we agreed? Both are answerable. Neither requires anyone to pretend they knew in January what the market would want in October.

	Project funding	Product funding
Unit of funding	Scope of work	Persistent team capacity
Team lifetime	Duration of project	Ongoing, tied to the domain
Commitment	Scope, date and cost	Capacity, mission and outcomes
Decision cadence	Annual approval, exception-based change	Rolling, reviewed quarterly
Success measure	Delivered to plan	Outcome movement and value delivered
Response to learning	Change request	Reprioritisation within the team
Knowledge	Discarded at close	Compounds in the team
Debt and run cost	Externalised to support	Owned by the funded team

The control finance loses is granular scope approval. What it gains is the ability to stop or resize a product quarterly rather than being locked into an eighteen-month commitment made on the worst available information. Framed that way, product funding is the more conservative option, and that framing is not rhetorical — it is the stronger financial argument.

The objections, and how they are actually handled

Three objections come up every time, and technology leaders routinely mishandle them by treating them as obstruction rather than as the real constraints they are.

"We cannot capitalise this." This is the objection that most often stops the conversation, and it is usually the most tractable. Broadly, accounting standards for internally developed software — IAS 38 in IFRS jurisdictions, ASC 350-40 under US GAAP — permit capitalisation of development activity that creates or substantially enhances an asset, and require expensing of research, maintenance and routine operation. Nothing in those standards requires a project structure. What they require is a defensible basis for allocating effort between the two categories, and an auditable record of it.

Organisations solve this in practice by attaching the capitalisation judgement to the work rather than to the funding envelope: classifying backlog items or epics as enhancement versus maintenance, and allocating team cost across those categories by effort. That is a change to how effort is recorded, not to how money is committed. It requires early involvement from finance and from the audit relationship, and it is far less exotic than it sounds — many large technology organisations already do it.

Two cautions. The specific treatment depends on your jurisdiction, your auditor's interpretation and your own accounting policy, so this is a conversation for your finance function rather than a matter to be settled by a delivery lead with an article. And do not let the capitalisation tail wag the delivery dog: teams that classify work to optimise the accounting rather than to describe reality corrupt both the accounts and the backlog.

"We will lose cost control." The fear is an open-ended commitment. The answer is that product funding is more controllable, because capacity is fixed and visible. The total spend on a product team is knowable to the pound before the year starts, which is more than can be said for a portfolio of projects with change-request tails. What varies is what the team builds, which is the thing you actually want to be able to vary.

Reinforce this with a real stopping mechanism. Quarterly review with the genuine option of resizing or ending a product is the control, and it must be exercised at least occasionally or it will be correctly read as theatre.

"How do we compare investments without business cases?" You still need a portfolio argument; you just need it at a different granularity. Fund domains against strategic priorities, review the allocation quarterly, and require each product to show outcome movement rather than scope completion. Where a genuinely large discrete investment is proposed — entering a new market, replacing a platform — a case is still appropriate. The change is that routine continuous improvement of an existing product stops requiring one, which removes most of the ritual while keeping it where it earns its place.

Running the transition incrementally

A wholesale switch at the start of a financial year is the version that gets proposed and the version that fails, because it requires finance, HR, portfolio governance and delivery to change simultaneously on a date, with no evidence.

The incremental route works better and is more persuasive.

Start with one domain that is obviously persistent. Something that clearly will still exist in three years and is currently funded as a series of projects — a payments capability, a customer platform, a core internal system. Nobody has to argue about whether the domain is permanent, which removes the first objection for free.

Convert the funding in place without changing the accounting. Fund the team as capacity for four quarters. Keep whatever cost classification finance currently uses; change only the commitment shape. This is a much smaller ask than it sounds and can usually be done within existing delegated authority.

Introduce outcome measures alongside the existing reporting. Run both for two quarters, so nobody loses visibility while the outcome reporting builds an evidence base. Do not attempt to kill the old reporting early; it is cheaper to run both than to fight about which is legitimate.

Exercise the stopping mechanism at least once. The first time a product is deliberately resized or paused at a quarterly review, the model becomes credible to finance in a way no presentation achieves. Plan for this rather than hoping for it.

Then generalise, with the capitalisation work done properly. Only once you have a working example is it worth reworking effort classification, time recording and audit evidence across the portfolio. Doing that first, in the abstract, is how these programmes stall.

Expect the hardest resistance not from finance but from the middle of the organisation, where project management and portfolio roles have careers built on the existing mechanism. That resistance carries real information about risks you have not considered, and it deserves to be worked with rather than overridden — see resistance-is-information.

The conversation with a CFO

Technology leaders tend to open this conversation with agility, empowerment and responsiveness, which lands poorly because none of those are financial arguments. There are four that are.

Sunk cost and the option to stop. A project committed for eighteen months cannot be stopped without writing off a budget and a reputation, so it is not stopped. Rolling funding with quarterly review creates a real option to exit, and options have value. This is the strongest argument available and it is a finance argument, not a delivery one.

Cost of delay and time to revenue. The fixed-scope pattern delays all value until the end, because nothing is released until the agreed scope is complete. Incremental delivery brings revenue or saving forward. Do not fabricate a figure; instead, take one recent large project and ask what proportion of its value came from the first third of its scope, and when that third became usable. The shape of that answer usually makes the point on its own.

Total cost of ownership. Project funding externalises run cost and technical debt to a future budget, so the business case understates lifetime cost systematically. Product funding puts build and run in one envelope and makes the true cost visible. A CFO generally prefers a visible larger number to an invisible one, because the invisible one still gets paid.

Forecast credibility. An organisation whose delivery forecasts are demonstrably unreliable is one whose financial planning inherits that unreliability. Product teams with stable capacity forecast from historical throughput and produce ranges rather than single dates — a genuine improvement in the quality of the information finance receives.

Go into the conversation expecting to be asked what control finance gets in exchange for what it gives up, and have a specific answer: quarterly reallocation rights, visible capacity cost per product, outcome reporting with baselines, and a named accountable owner per product. Offer the audit and capitalisation conversation proactively rather than waiting to be challenged on it.

What to do on Monday

Take the last three completed projects in one domain. For each, note the team composition at start and at end, how many of those people are still working in that domain, and how much of the original scope was ultimately used. This takes an afternoon and it is the most persuasive artefact you will produce, because it is specific, internal and not arguable.

Then find the domain that is most obviously permanent and propose one thing only: fund it as capacity for four quarters, with the existing cost treatment unchanged and a quarterly outcome review. Do not propose a portfolio-wide change to the operating model. A small, reversible, accounting-neutral pilot is approvable at a level that a transformation programme is not.

Finally, book the conversation with finance before you need anything from them. Ask how they currently classify development effort, what the auditor expects, and what would have to be true for a persistent team's cost to be treated the same way a project's is today. You will learn either that it is easier than you feared, which is common, or exactly which constraint you have to design around — and either answer is worth more than another quarter of assuming.