Your portfolio is full. Your teams are not the bottleneck.

Every leadership team says it wants focus.

Then the portfolio review starts.

One initiative is strategic. One is nearly finished. One has a board sponsor. One is needed for compliance. One is "small". One already has a team assigned. One is too politically expensive to stop. Nothing dies. Everything stays active.

The team level then gets the blame.

Teams are told to become more predictable, improve estimation, refine better, use Scrum harder, or "be more agile". But the real queue is often sitting above them. Too many initiatives are sharing the same architects, product people, security reviewers, platform specialists, UX people, legal sign-offs, and management attention.

That is portfolio WIP.

And if you do not manage it, the delivery system will manage it for you. Usually through waiting, context switching, stale decisions, half-finished work, and quiet rework.

A portfolio is not a bigger backlog

At team level, most people understand WIP at least in principle. If a team starts ten things at once, flow suffers. Work waits. Feedback arrives late. People switch context. Cycle time stretches.

At portfolio level, the same pattern is harder to see because the unit of work is larger and more political.

An initiative can sit in the portfolio for months while everyone says it is active. The real work may be waiting for one specialist, one architectural decision, one product clarification, or one other initiative that has to land first. On paper, the portfolio is moving. In the system, it is aging.

This is where many prioritization conversations fail. They rank work, but they do not expose the constraint.

The question has to go beyond "which initiative matters most?"

The better question is: Which active initiatives are competing for the same scarce capacity, and which of them should stop, pause, shrink, or finish first?

The evidence points to resource contention and dependencies

Tyson Browning and Ali Yassine studied product-development portfolios under resource constraints. Their 2016 Decision Sciences paper modelled 31 priority rules across 18,480 portfolios containing 55,440 iterative projects. The useful part is not a single magic rule. The useful part is the warning: iterative project portfolios behave differently depending on resource contention, network density, iteration intensity, and whether you optimize single project delay or portfolio delay.

That should make delivery leaders cautious.

A rule that looks sensible for one initiative can be poor for the portfolio. "Give the most important project priority" may starve dependent work. "Finish what is closest to done" may keep strategic renewal work underfed. "Keep every sponsor happy" may saturate the scarce people everyone needs.

The older IT portfolio evidence points in the same direction. de Reyck and colleagues surveyed 34 medium-to-large organizations and found that higher adoption of project portfolio management practices was associated with fewer project-related problems and better perceived project performance. The study is self-reported and correlational, so it should not be oversold. Still, its practical list is useful: explicit resource constraints, prioritization, selection, accountability, governance, risk analysis, and termination decisions.

Termination matters.

Many organizations have a start process. Fewer have a stop process with the same social legitimacy.

Dependencies make "just prioritize" too thin

In IT and software portfolios, initiatives do not merely stand next to each other. They touch.

Bathallath, Smedberg, and Kjellin reviewed project interdependencies in IT/IS portfolios and describe several types: resource, technology, technical, market, and learning-based interdependencies. These dependencies can create benefits. Shared knowledge, shared platforms, and sequencing across related initiatives can help the whole portfolio.

They also create management difficulty.

If one initiative slips, another may wait. If the portfolio goal changes, dependencies may be added, changed, or removed. If several initiatives need the same expert, that expert becomes the invisible portfolio scheduler.

This is why a team can look slow while doing exactly what the system asks from it.

One person is pulled into three priority-one initiatives. One Product Owner has to clarify decisions for four teams. One platform team is asked to support every product bet. One architecture forum meets every second week and becomes the real release cadence.

None of this is fixed by telling the delivery teams to focus.

The portfolio has to focus.

Selection is not enough

Portfolio management often becomes a ranking exercise. Score the initiatives. Compare business value. Add risk. Add effort. Build a table. Move the highest score to the top.

This is useful, but incomplete.

Si, Kavadias, and Loch argue that innovation portfolio management has over-weighted project selection and generic evaluation methods. Their point is sharper than "prioritize better": organizations need portfolio design. They need to shape a set of initiatives that fits the strategy, the constraints, and the learning agenda before they start optimizing a list.

That distinction matters in agile delivery.

If the portfolio is badly designed, better ranking only makes the spreadsheet cleaner. It does not remove the dependency tangle. It does not create capacity. It does not decide which old work should be harvested, which should be ended, and which new work deserves scarce attention.

This is where a simple facilitation structure can help. Ecocycle Planning, from Liberating Structures, asks a group to map activities across birth, maturity, creative destruction, and renewal. It also names two useful traps: the rigidity trap, where old activities stay alive after they stopped helping; and the scarcity trap, where promising new work is underfed.

That is not empirical proof. It is a conversation design.

But it is a good conversation design for a portfolio that keeps pretending every initiative deserves life support.

What I would measure before another prioritization workshop

If I were doing a flow audit on this, I would not start with a maturity model.

I would take the current portfolio and ask for a small, ugly dataset:

• all active initiatives
• start date and latest meaningful value decision
• target outcome, rather than output
• teams involved
• scarce people or groups needed
• dependencies on other initiatives
• blocked days in the last 30 days
• decision wait in the last 30 days
• last shipped increment or validated learning
• explicit stop, pause, or kill condition

Then I would look for four things.

First, shared scarce capacity. Who appears everywhere? Architects, security, UX, platform, Product Owners, legal, data, senior reviewers. If one person or group is in every critical path, the portfolio has a queue. Do not call it a team commitment problem.

Second, old active work. Which initiatives are still open because nobody wants the social cost of ending them? These are often in the rigidity trap. They consume attention even when the work is mostly maintenance of a promise.

Third, starved renewal work. Which important experiments never get enough capacity to learn anything? These are often in the scarcity trap. They are not failing because they are weak ideas. They are failing because the portfolio never gives them a real test.

Fourth, missing stop rules. If an initiative has no kill condition, it is not a bet. It is a subscription.

The leadership move is to make fewer promises

Portfolio WIP is uncomfortable because it exposes a leadership tradeoff.

You cannot protect every initiative, keep every sponsor satisfied, load every scarce expert to 95 percent, and expect predictable delivery. The math will not care how agile the teams are.

Reinertsen's flow logic is useful here: queues grow when demand exceeds service capacity, and high utilization makes waiting time explode. At portfolio level, the queue is often made of decisions, dependencies, and scarce people.

The practical move is boring and hard:

• Stop pretending that "active" means funded.
• Separate work that should finish from work that should pause.
• Make kill decisions normal, not exceptional.
• Reserve real capacity for renewal work.
• Limit how many initiatives can compete for the same scarce group.
• Review portfolio age and decision wait, not milestone status alone.

This protects innovation. It is the precondition for innovation that actually finishes.

A better portfolio review

A useful portfolio review does not ask every initiative to prove it is important. Of course it is important. That is why it survived long enough to enter the room.

Ask harder questions:

Which initiatives are blocked by the same dependency?

Which ones have not produced validated learning or usable value in the last month?

Which ones are alive because stopping them would be awkward?

Which ones need the same person in the same two-week window?

Which ones should be reduced to a smaller bet?

Which ones should be killed today so another can finish?

If this sounds political, good. Portfolio WIP is political. It is where strategy meets scarce capacity.

The job of an Agile Coach or Delivery Manager is not to make this polite. It is to make it visible enough that leaders can make an honest decision.

Teams do not need another speech about focus while the portfolio keeps starting.

They need leadership to stop starting and start finishing.

Sources

• Browning, T. R., & Yassine, A. A. (2016). "Managing a Portfolio of Product Development Projects under Resource Constraints." Decision Sciences.
• de Reyck, B., Grushka-Cockayne, Y., Lockett, M., Calderini, S., Moura, M., & Sloper, A. (2005). "The impact of project portfolio management on information technology projects." International Journal of Project Management.
• Bathallath, S., Smedberg, A., & Kjellin, H. (2022). "Managing project interdependencies in IT/IS project portfolios: a review of managerial issues." International Journal of Information Systems and Project Management.
• Si, H., Kavadias, S., & Loch, C. (2022). "Managing innovation portfolios: From project selection to portfolio design." Production and Operations Management.
• Liberating Structures. "Ecocycle Planning."
• Reinertsen, D. G. (2009). The Principles of Product Development Flow.