Every year executives sign off on the cloud platform budget, and every year the platform becomes harder to change than the year before. That is not an engineering problem. It is a consequence of the cloud platform funding model that approved the platform in the first place.
In Brief
- Cloud platforms violate the structural assumptions of both project-based and BAU funding — neither model has a mechanism for continuous capability investment.
- Project-based funding terminates at delivery, but the cloud platform it produced continues to require investment from the day the project closes.
- BAU funding assumes a known, stable system — a cloud platform's service envelope never stops expanding.
- The CFO and the board own the funding model decision; the CIO can describe the cost curve but cannot fund the response.
- Adding a continuous platform investment envelope alongside initiative funding stops the cost curve from compounding further.
Cloud is not a project
Organisations typically inherit two governance vocabularies — project management with its associated yearly budget funding cycle and operations or BAU management — and then try to stretch one to cover cloud. Project funding moves through investment committees as a stack of named initiatives — the customer portal rebuild, the analytics modernisation, the integration uplift, the API platform refresh — each with a sponsor, a delivery date, a benefits case, and a capex budget that closes the moment the initiative goes live. Other needs are then moved to operational funds, including technical debt and requirements that didn’t make the cut but customers expect. Kersten (2018) named this gap directly: project funding terminates at delivery, while the end-product continues to require investment as soon as the project closes. The structural assumption underlying project funding is that the asset is complete at handover. A cloud platform is never complete at handover — its value depends on continuous evolution after the project closes. That is not a funding shortfall. It is a category mismatch.
Business-as-usual (BAU) or sustainment management fails for a different but equally structural reason. BAU is appropriate for stable, well-understood systems where the objective is to maintain an agreed service level at minimum cost. Its structural assumption is that the system being maintained has a known, stable service envelope. A cloud platform’s service envelope never stops expanding — new provider capabilities arrive continuously, security requirements shift, and new workload types appear from teams that didn’t exist when the platform was built. That is not a maintenance problem. It is a product evolution problem, and BAU has no mechanism for it. Forsgren, Humble, and Kim’s research in Accelerate (2018) makes the consequence clear: organisations that treat technology capability as a sustain-and-maintain problem consistently fall behind those that treat it as a continuous improvement engine.
If neither project funding nor BAU provides the mechanism cloud requires, the question is what model does.
Cloud is a modern digital product that, when managed accordingly, earns value over years, not quarters. It must evolve continuously to retain that earning capacity. The relationship between the cloud product team and the software development teams it serves is explicitly a product relationship: cloud is a product, the development teams are its customers, and the cloud product team’s job is to make its customers more productive. The most common mistake is treating customer demand for cloud as an infrastructure ticket queue. If the cloud product team exists to process requests, it becomes a bottleneck. Its output should be self-service cloud capabilities, not completed requests.
A product model requires product funding — a continuous capital and operational envelope to grow and mature the platform. Fund cloud only as a project or as BAU, and the platform has no committed investment between initiatives. That gap is not neutral. What it costs, and why the cost compounds over time, is where the argument sharpens.
Deferred investment doesn't stand still
Reinertsen (2009) is precise on this, and the precision matters. When investment in a flow-constrained system is deferred, the cost of that deferral does not accumulate at a constant rate. It compounds non-linearly. Each unit of delay raises the cost of the next unit of delay — because the queue of unimproved work grows faster than the team’s capacity to clear it, and because every new initiative is built on top of a platform that is, by design, slightly less ready to receive it than the last one was.
This is not the technical-debt argument executives have heard before. Technical debt language frames the problem as a sloppy ledger that engineering forgot to pay down. Reinertsen’s argument is colder, and more useful. He is describing a cost-of-delay function whose curve bends upward over time. If the platform required three months of remediation work to support last year’s initiative, it will not require three months again. It will require four. Then six. Then nine. The slope is not gentle. By the time the slope becomes visible in the quarterly delivery numbers, the platform is several budget cycles into a curve that was already being drawn.
The cause is the structure of the budget itself. An annual allocation tied to named initiatives, exhausted on delivery, guarantees that the platform never accumulates improvement. Every year resets the clock on platform investment. Every reset starts the compounding curve at a slightly higher base. A companion piece on this site examines the governance side of the same problem — the bodies and committees that decide how cloud platforms are run — and reaches a related conclusion through a different door. Governance tells you who is allowed to invest in the platform; the funding mechanism decides whether the question of investment can even be raised.
The CIO is being held accountable for the wrong problem
The symptoms are visible inside any organisation’s management reports. Integration risk is rising. Cycle time for new initiatives has been lengthening — even on initiatives whose scope is no larger than work delivered two years ago — and maintenance is quietly taking a growing share of the engineering payroll. Those are legitimate signals. The question is whether they belong in the conversation being had with the CIO.
The CIO has been doing exactly what the funding model rewards. Every approved project is released. Every reported benefit is realised. The cloud’s deterioration is invisible inside any single initiative’s business case, because the deterioration is a property of the gaps between initiatives, and the budget has no line for the gaps. Project Management Institute material on enterprise agile budgeting makes the assumption explicit: fixed-scope, time-bound funding is the unit of governance, and the question of how the asset itself accrues capability is treated as out of scope for the funding decision (Project Management Institute, n.d.).
Continuous platforms need continuous funding
A continuously improving platform requires a continuously available investment envelope. What it is called — platform team allocation, product-funded engineering capacity, enduring envelope, or whatever else the CFO peer group will accept — is the secondary question. The primary question is whether the platform has any committed funding that survives the closure of the initiative that created it. In most organisations the answer is no, and the non-linear cost curve is the receipt.
Executives don’t need to dismantle the project-based funding model to address product-based funding. The structural change is a second funding envelope, sized against the cloud platform’s accumulating improvement requirement, that survives initiative closure and sits outside the initiative-level prioritisation conversation. The decision sits with the CFO and board, not with the CIO. The CIO can describe the curve. Under the current rules, the CIO cannot fund the response to it.
What the board needs to ask
In the next quarterly review with technology leadership, one question is worth putting on the table: of the dollars approved for cloud platform investment this year, how many will still be available to the platform team the day after each initiative closes? If the answer is zero — and in most organisations it is — then the platform has no continuity budget, and the cost of that absence is compounding inside numbers that have already been seen but not yet attributed to their actual cause.
That is a conversation for the CFO and the COO to lead. The funding model is a board decision. So is the cost of leaving it unchanged.
References
- Kersten, M. (2018). Project to product: How to survive and thrive in the age of digital disruption with the flow framework. IT Revolution.
- Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK guide) (7th ed.). Project Management Institute.
- Project Management Institute. (n.d.). Agile project management methods enterprise. PMI Learning Library. https://www.pmi.org/learning/library/agile-project-management-methods-enterprise-6200
- Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.
- Gartner. (2025, May 13). Gartner identifies the top trends shaping the future of cloud [Press release]. https://www.gartner.com/en/newsroom/press-releases/2025-05-13-gartner-identifies-top-trends-shaping-the-future-of-cloud
- DORA. (2024). Announcing the 2024 DORA report. Google Cloud. https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
- McKinsey & Company. (2020). Tech debt: Reclaiming tech equity. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity
