The usual way to fund software is to approve a project, assemble a team, build the thing, and disband the team. Then, a few months later, the business asks for changes, and a new project starts with a new team that has to learn everything again. Some organizations are trying a different model: fund a persistent team around a product or value stream, and let the work change while the team stays.
What you gain
The first benefit is retained knowledge. A team that has supported a billing platform for two years knows where the bad data hides and which stakeholders to call. Disbanding it after each release throws that away, and you pay for the relearning every time.
The second is flow. Projects spend real time on startup: staffing, onboarding, and negotiating a budget. A standing team skips that. Work arrives, gets prioritized, and starts.
The third is a better conversation with the business. Instead of debating whether a 200-page requirements document is complete, the product owner and the team decide each cycle what’s the most valuable thing to do next. Scope becomes a tool, not a contract.
What finance and governance must change
This model doesn’t fit neatly into annual project budgets, and finance teams know it. A few things need attention.
- Budgeting. Fund a team’s capacity for a period, such as a year, and review it regularly. You’re funding a stable group of people, not a deliverable list.
- Business cases. Judge the product, not each feature. Ask whether the product is producing enough value to justify the team.
- Capitalization. Accounting rules for software costs were written around projects. Work with your finance group early to agree how persistent teams are treated.
- Governance. Replace stage gates with regular reviews of outcomes, using measures the team and sponsor agreed on.
Picture an insurer that moves its policy-servicing work from 15 yearly projects to three standing teams. The portfolio group no longer approves 15 scopes. It reviews three products, their results, and whether each team should grow, shrink, or stop.
The transition is uncomfortable
Expect pains. Executives lose the comfort of a fixed scope and a delivery date. Project managers wonder where they fit. Some products turn out to be too small to justify a full team, and some teams stay funded longer than their value warrants unless someone is willing to review them honestly.
Start with one product where the work is steady and the business sponsor is engaged. Run it for two or three quarters, keep the measures visible, and adjust. Don’t convert the whole portfolio at once.
Key message: “Stable teams and changing priorities beat changing teams and fixed scope.”
If your organization is considering this shift, begin by listing which of your current projects are the same product in disguise. That list often shows where to start.