Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Image
Every transformation I have watched stall began the same hopeful way. A workshop, a good one, where leaders nod along to the difference between projects and products. Projects finish; products live. Projects deliver scope; products deliver outcomes. Everyone agrees by lunch. Then Monday arrives, the annual budget cycle reasserts itself, finance asks which costs can be capitalized, a steering committee schedules its gate review, and within a quarter the same people who nodded are back to staffing temporary teams against fixed scope with a fixed end date. The mindset did not lose the argument. It lost to the machinery that was never on the agenda.That is the part most product transformations get backwards. They treat the project mindset as a belief problem, something you fix with training and a new vocabulary. It is not a belief. It is the rational response to how the organization allocates money, accounts for cost, and grants authority. People think in projects because the entire apparatus around them counts, funds, and rewards projects. Change the mindset without changing the system and the system wins every time, quietly, on a Monday. If I look at a system, I always remember the quote of the late Stafford Beer: 'The purpose of a system is what it does' The Unaccountability Machine.The Mindset Is Downstream of the MoneyStart with the budget, because everything else inherits from it. Most large organizations still fund work once a year, in a fixed lump, tied to a defined scope and a delivery date. That single mechanism manufactures the project mindset whether anyone intends it or not. A team funded for a fixed scope by a fixed date is a project team, no matter what you call it on the org chart. You can rename it a product team, give it a product owner, send it to Scrum training, and it will still behave like a project, because the money it lives on has a start, an end, and a scope baked in.Deloitte's UK consulting team made the case bluntly in February 2026: traditional annual budgeting is now misaligned with how digital businesses actually need to work, and the cost is real. They cite an industry projection that 75 percent of IT investments will fail to deliver tangible business value by 2027 without clearer investment models, and they note that the strongest digital performers are roughly 80 percent more likely to use adaptive, value-stream funding than their slower peers. The annual lump sum delays every response to the market until the next planning round, which in a product world is the same as not responding at all.Mik Kersten built his whole Project to Product argument on this point. Funding has to follow value streams against business results, allocated incrementally as demand and evidence justify it, not handed out once as a fixed initiative with an expiry date. Until the money moves that way, the language of products is decoration on a project budget.The Accounting Quietly Enforces ItUnderneath the budget sits an enforcer almost nobody names in the transformation deck: the accounting treatment of software cost. For decades, project structure made capitalization easy. A project had a discrete beginning and end, so the build phase could be booked as capital expenditure and the later upkeep as operating expense. Clean boundaries, happy auditors.Standing product teams demolish those boundaries. As one SoftwareReviews analysis puts it, the move to true standing teams with continuous delivery "shatters those comfortable boundaries, leaving delivery leaders scrambling to account for CapEx versus OpEx." A team that funds, builds, runs, and improves the same product indefinitely has no clean line where the capital project ends and maintenance begins. Finance, faced with that ambiguity, often defaults to the safe answer and books the work as operating expense, which makes the product team look more expensive on paper than the project it replaced. The CFO who planned to grow technology spend, and Deloitte found 47 percent of them intended to raise it by 10 percent or more in 2025, now has a product model that reports worse economics than the thing it was supposed to improve. Guess which model survives the next budget review.This is why so many transformations die without a single person ever arguing against them. The accounting system, doing exactly what it was designed to do, makes the old way look cheaper. No villain required. Dan Davies has a name for this in The Unaccountability Machine: the accountability sink, a structure where decisions get delegated to rules and procedures so completely that no individual is responsible for the result and the people it harms have no way to push back. The annual budget cycle and the capitalization rules are exactly that kind of sink for a product transformation. They kill it on schedule, and there is no one to argue with.Trust Is the Currency the Project Model Never NeededMarty Cagan's Transformed names the deepest barrier as trust, and that lands harder once you see what project governance actually is. Steering committees, stage gates, detailed upfront plans, and status reports exist precisely so that leaders do not have to trust the team. They are a control apparatus built to substitute process for confidence. That apparatus works fine for projects, where the goal is to deliver an agreed scope on time.The product model asks executives to do the opposite: hand a durable team a problem and the authority to solve it, then judge the result by the outcome rather than adherence to a plan. Most leaders have never operated that way, as Cagan points out, so they keep the control apparatus running alongside the new structure. The team is told it is empowered while every gate, report, and approval signals that it is not. People read the signals, not the slogans. They behave like a project team because the governance still treats them like one.There is a structural cost too. Project teams form, deliver, and disband. That churn is fatal to product thinking, because the knowledge of why a product is shaped the way it is, what was tried, what failed, which customers behave how, walks out the door when the team dissolves. Continuity of ownership is not a nice-to-have in the product model. It is the mechanism by which learning compounds, and it is the first thing the project funding cycle destroys at the end of every initiative.Change One Funding Decision, Not One More MindsetThe practical move is to stop running mindset workshops and change a single funding decision instead. Pick one product. Fund a standing team for it for a year against an outcome the business actually cares about, retention, conversion, cost-to-serve, with the freedom to decide which features serve that outcome. Then do three things that make the new model survive contact with finance.Settle the accounting before the first sprint, not after. Bring finance in to define how work on a standing team gets classified, using backlog-item tagging by work type rather than project phase, so the product team is not quietly punished with worse-looking economics for doing the right thing. Next, remove one layer of the control apparatus for that team, a gate or a recurring status review, and replace it with a quarterly outcome conversation. That is where executives practice the trust the model requires, in one low-risk place rather than across the whole portfolio at once. Finally, protect the team's continuity as a hard rule. When the year ends, the team does not disband and reform around the next initiative; it carries its accumulated knowledge into the next bet on the same product.None of this needs a wholesale overhaul, and Deloitte is right that the change can start small. The reason it has to start with the money rather than the mindset is simple. Beliefs follow incentives, not the other way around. When a team is funded against an outcome, accounted for honestly, trusted with real authority, and kept together long enough to learn, the product mindset stops being something you have to teach. It becomes the only sensible way to behave in a system finally built to support it. The mindset was never the thing standing in the way. The plumbing was.Ralph Jocham is Europe's first Professional Scrum Trainer, co-author of "Professional Product Owner," and contributor to the Scrum Guide Expansion Pack. As an ICF ACC certified coach, he works with organizations to build Product Operating Models where strategic clarity, operational excellence, and adaptive learning create measurable competitive advantage. Learn more at effective agile.References[1] Mestry, K. and Graham, J. (2026) 'Moving beyond budgets: how agile funding is a necessity for tech success', Deloitte UK, 16 February. Available at: https://www.deloitte.com/uk/en/services/consulting/blogs/2026/beyond-budgets-agile-funding-a-necessity-for-tech-success.html[2] Kersten, M. (2018) 'Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework', IT Revolution Press. Available at: https://www.amazon.com/Project-Product-Survive-Disruption-Framework/dp/1942788398[3] SoftwareReviews 'How to Stop Leaving Software CapEx on the Table With Agile and DevOps'. Available at: https://www.softwarereviews.com/research/how-to-stop-leaving-software-capex-on-the-table-with-agile-and-devops[4] Cagan, M., Hickman, L., Jones, C., Idiodi, C. and Moore, J. (2024) 'Transformed: Moving to the Product Operating Model', Wiley / Silicon Valley Product Group. Available at: https://www.amazon.com/Transformed-Becoming-Product-Driven-Company-Silicon/dp/1119697336[5] Davies, D. (2024) 'The Unaccountability Machine: Why Big Systems Make Terrible Decisions and How the World Lost Its Mind', University of Chicago Press. Available at: https://press.uchicago.edu/ucp/books/book/chicago/U/bo252799883.html
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | The New AI Operating Model. Start By Using Scrum | 0 | 6 | 07-07-2026 |
| 2 | Silos are the Bane of Value Delivery | -5 | 7 | 29-06-2026 |
| 3 | Wird Product-Ownership zum Flaschenhals im KI-Zeitalter? Warum viele Product-Owner schlecht priorisieren, warum KI das sichtbar macht und 10 Werkzeuge, um besser zu entscheiden | 0 | 7 | 07-07-2026 |
| 4 | If You Can Write Acceptance Criteria, You Can Write an AI Routing Policy | 0 | 7 | 05-07-2026 |
| 5 | Clean out the Product Backlog | 0 | 5 | 24-06-2026 |
| 6 | Prioritizing Is the Hardest Thing Your Brain Does. Your Calendar Treats It Like the Easiest. | 0 | 5 | 05-07-2026 |
| 7 | From Chaos to Control, Part 5 - Goal | 2 | 6 | 02-07-2026 |
| 8 | Ordering the Product Backlog with RICE: From Opinion to Evidence | 0 | 5 | 09-07-2026 |
| 9 | The AI Definition of Done | 0 | 7 | 21-06-2026 |
| 10 | The Wizard's Rules: A Field Guide to How Your Organization Lies to Itself | -2 | 6 | 18-06-2026 |