I’d like to tell you that room was unusual. It wasn’t. This fall I sat down with portfolio and architecture leaders from dozens of organizations and heard versions of the same story again and again. It’s not an outlier The portfolio leader said it almost in passing. Every year, a fifth or more of the capital the company approves for technology goes unspent. Not cut, not moved. Just unspent.
Someone across the table pushed back. It wasn’t that nobody noticed. The monthly report flags it, and people get called out for it, every month. “We realize we’re not spending,” they said, “but we’re not forcing an action.”
I asked what happens to the money. It sits in contingency. Before anyone can release it, they have to check with the sponsor, and the sponsor’s answer is the same every time: that money is mine. Why isn’t it being spent in the first place? Because the people who would do the work are already fully booked, and nobody can say on what.
So there it was. A number everyone could see. A queue of work waiting for funding. And nobody in the room with the authority, or a shared view of priority, to move a dollar from one to the other. The company wasn’t short of capital. It was short of a way to decide.
. It’s the median.
Strategic portfolio management is the discipline that decides what gets funded, who works on it, and whether it paid off. It runs from the moment a request arrives to the moment someone asks what it delivered: intake, prioritization, funding, capacity, delivery and value. When it works, leadership makes trade-offs with confidence. When it stalls, the trade-offs still get made, just without it.
When a portfolio practice stalls, the conventional answer is to rebuild it: a new partner, a new design, sometimes a new tool. It feels decisive. It’s usually the expensive way to relearn the same lessons.
Most stalled practices aren’t broken. They’re stuck in predictable ways, and the failures pile up in a particular order. That order is the useful part. If failures compound in sequence, they can be unwound in sequence, and recovery becomes a plan with an end date rather than an open-ended repair bill.
A note on the evidence. The patterns come from my own work: years of portfolio engagements across industries, structured assessment workshops with portfolio, finance and IT leaders, and this fall’s conversations. Where published research supports a claim, I cite it. Where no reliable figure exists, I say so, and the claim rests on what I’ve observed.
A stalled portfolio practice rarely fails loudly. It just stops informing decisions, and the cost shows up somewhere else.
It shows up in outcomes. In Gartner’s 2025 survey of more than 3,000 CIOs and technology executives, only 48% of digital initiatives, on average, met or exceeded their business-outcome targets.1 It shows up as waste: organizations in PMI’s 2018 Pulse of the Profession estimated that 9.9% of every dollar invested in projects was lost to poor project performance.2 It shows up in the gap between strategy and execution: 61% of senior executives in a 2013 Economist Intelligence Unit survey said their organizations often struggle to bridge the two.3
None of these numbers isolates stalled portfolio practices, and I won’t pretend it does. But each one describes a symptom I find in nearly every stuck portfolio: work that can’t be tied to outcomes, money that can’t be traced, and reports rebuilt outside the system because nobody trusts it.
Any one of these is survivable. Most stalled practices I’ve seen have three or four.
01 The team that built it knew the platform, not portfolio management. Here’s how you recognize it: the workflow mirrors the old spreadsheet column for column, dashboards were bolted on after go-live, and every portfolio question got answered with a platform feature. Michael Hammer had a name for this in 1990: paving the cow paths.4 The build isn’t broken in a technical sense; it may demo fine. It just doesn’t fit how the organization decides, resources and executes.
02 Over-customization. The old tool gets rebuilt inside the new one. Custom fields duplicate what already ships. Resource and cost tracking get rebuilt outside the platform’s own models, and standard reports come back blank. One large global survey found that organizations that customized off-the-shelf portfolio software reported slightly lower performance and satisfaction than those using it as packaged.5 The bill arrives later: every upgrade and every new capability has to work around what was built.
03 A process too heavy to sustain. PMs update the night before the steering meeting and not between. Everything shows last month’s state, and people keep a private version that’s current. Part of it is weight. Part of it is that current data is exposed data: an honest update turns a project amber in front of everyone, so it stays green until it can’t. Every report runs on stale data, and decisions get made on it anyway.
04 No financial or capacity picture. Actuals may flow in from the finance system every day, and still nobody can see the portfolio’s money. The roll-up gets rebuilt each month by one analyst who adjusts it from memory; when they’re out, it takes someone else days. Internal labor isn’t charged to projects, so internally staffed work looks cheap and gets approved more easily. In one organization, a shared contractor pool was charged to one project until its budget ran out, then to the next. By year-end, three finished projects showed no spend at all. Capacity is worse. Nobody can say who’s available, so staffing comes down to who looks least busy, and planned projects don’t start because people are still finishing last year’s. The portfolio can defend its schedule, but not its budget or its plan.
05 Intake that decides nothing. Requests arrive by email, or get worked out offline, outside the intake process entirely. Or the intake form is so long and cumbersome that nobody wants to use it. Where it is used, submitters guess which request type to file. The review board gets buried in requests and duplicates, and reviews stall. And often the real decision was made before intake ever saw it: anything with a sponsor and a “non-discretionary” label simply goes through. Intake records decisions instead of making them. The portfolio grows by accretion, and capacity is committed before anything is compared.
06 A portfolio that never left IT. The portfolio holds IT projects. Marketing, operations and HR programs run in their own trackers, and the executive view covers only the spend IT controls. That’s a shrinking share: Gartner found that 74% of technology purchases are funded at least partly outside IT.6 Initiatives that compete for the same money and people can’t be compared, because they live in different systems.
Six patterns come down to three causes. The arc matters: it starts with who built it and ends with what the organization never scoped.
Who built it. Broad platform experience without real portfolio and PMO depth. That’s pattern 01, and it makes the rest more likely: a team that doesn’t know what a portfolio is for answers every question with what the platform can do.
How it was built. Configuration ran ahead of any agreed process, governance and capability model, and nobody owned the data model. Patterns 02 and 03 grow here. When nobody has agreed how a decision gets made, the safe move is to model every option. That’s how a system ends up both over-customized and too heavy to use.
What the organization owned. Decision rights nobody defined: who can decline a request, defer a project, stop one, or move money from one to another. Add a process nobody simplified, data nobody fixed at the source, and scope nobody pushed past IT or into finance. Patterns 04, 05 and 06 live here. It’s the cause most rooms recognize last, because it isn’t about the partner. Nobody outside the organization can configure decision rights, a seat for finance or business participation. Those have to be decided inside it.
None of this is a verdict on anyone. Most of these choices were reasonable on the day they were made. They just compound.
Many portfolio leaders say what they’re missing is a clear, actionable roadmap from where they are to where they need to be. It’s hard to write because the failures compound in order, so they have to be unwound in order.
Watch how they feed each other. Nobody decided how intake works, so the build modeled every path. The model got heavy, so people stopped updating it. The data went stale, so leadership stopped trusting it. Each failure is the input to the next.
That’s why the intuitive fixes misfire. Launch an adoption push first and you’re sending people back into a process that’s still too heavy. They’ll stop again within a quarter, and now they’re cynical too. Simplify first and you’ll cut the wrong things, because nobody has decided what the portfolio is supposed to decide. Re-platform first and you migrate the undecided questions into a new tool.
So I unwind it in three steps.
Decide: close the governance gaps that hurt most. These are decisions, not configuration.
Simplify: cut to the high-impact core.
Adopt: rebuild adoption deliberately.
Nobody has run a controlled study of the order in which to unwind a stuck portfolio. But the research on organizational change points the same way: start from the business problem, and formalize systems last.7 What I’ve seen in the field bears that out.
There’s a serious case for starting over, and it deserves a straight answer.
The strongest version: organizations are biased toward rescuing what they’ve already paid for. Between 30% and 40% of information systems projects show some degree of escalation of commitment: more money, more time, same course.8 A recovery proposal is exactly what an escalating organization wants to hear. Sometimes the data model really is beyond saving. And sometimes the tool’s name is so damaged that nothing called by it will be trusted again.
Either way, agree the process redesign before choosing the platform, or you’ll pave the same cow paths somewhere new.
Two things keep the recovery case honest. First, a rebuild is itself a large IT project, and IT projects have fat tails. In one study of 1,471 IT projects, one in six ran an average of 200% over budget.9 Price that in. Second, the causes behind patterns 04, 05 and 06 move with you. A new tool doesn’t decide who can decline a request.
Recovery has to earn its place, too. It needs an end state and a trigger, agreed up front, for switching to a rebuild. Without those, recovery is just escalation with a better name.
If you’re a CIO or platform owner: the question isn’t whether the tool works. It’s whether the practice around it decides anything. Before you fund a replacement, ask for the recovery case, with an end date and a rebuild trigger.
If you lead the PMO or portfolio office: your leverage is in the Decide step, and none of it needs configuration. Get decision rights named, make one gate actually stop something, and put finance in the room.
If you’re a finance leader: you probably hold the portfolio’s real numbers already. The fastest way to a portfolio leadership trusts is one cost model and one number, agreed with the PMO.
If you lead a business unit: if your initiatives aren’t in the portfolio, they aren’t being compared with the ones that are, and they’re competing for the same people. Ask to be the first business group in.
You can run this diagnostic without anyone’s help.
If you answered no to two or more, you’re not looking at a rebuild. You’re looking at a sequence.
1. Gartner (2024). 2025 CIO and Technology Executive Survey, press release, October 22, 2024. 3,186 CIOs and technology executives in 88 countries.
2. Project Management Institute (2018). Pulse of the Profession 2018. Respondents’ own estimates.
3. Economist Intelligence Unit, sponsored by PMI (2013). Why Good Strategies Fail. 587 senior executives.
4. Hammer, M. (1990). “Reengineering Work: Don’t Automate, Obliterate.” Harvard Business Review, July–August, 104–112.
5. PwC (2012). Insights and Trends: Current Portfolio, Programme, and Project Management Practices. Third global survey: 1,524 respondents in 38 countries.
6. Gartner (2022). Survey of 1,120 respondents on business technologists, press release, 2022.
7. Beer, M., Eisenstat, R. A. & Spector, B. (1990). “Why Change Programs Don’t Produce Change.” Harvard Business Review, November–December.
8. Keil, M., Mann, J. & Rai, A. (2000). “Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models.” MIS Quarterly, 24(4).
9. Flyvbjerg, B. & Budzier, A. (2011). “
.svg){kind=icon}
