A diagnosis a client cannot argue with

Here is the problem

Overload is normally presented as a behavioral problem: poor prioritization, weak governance, too many sponsors saying yes. Each of those is true enough to be arguable, which is exactly why the recommendation stalls. A client can disagree with a judgment about their discipline. It is much harder to disagree with a number.

So the diagnosis lands, the deck is accepted, and six months later the portfolio looks the same. Not because the advice was wrong, but because it was expressed in a currency the client could negotiate with.

The structural version of the same finding

In any organization where projects share people, throughput stops rising well before the people are fully loaded. Past a certain level of concurrent work, adding another project makes the whole system slower, not faster. Traffic on a motorway behaves the same way, a metaphor Mike Hannan uses: it flows well at moderate density, and average speed collapses once every lane is packed.

That is not a management philosophy. It is a property of systems that share constrained resources, and it holds regardless of how disciplined the client is.

Stated that way, overload stops being a criticism of the client and becomes a description of the system they are operating. That single change makes the conversation possible.

How to put a number on it

Two measures do most of the work, and both come from Stephen Devaux.

Drag cost prices delay. If a deliverable is worth a given amount per week once it lands, every week it does not land is that amount forgone. Applied across a portfolio where lateness is systemic, it converts a qualitative finding into a figure a finance director recognizes.

DIPP prices continuation. Against what remains to be spent, is finishing this project still the best available use of the client's scarcest people? It is forward-looking, which means it produces a decision rather than a judgment about the past. That matters when the sunk cost belongs to the person you are advising.

Take sixteen projects that each look sound in isolation. Examine the teams they share and the picture changes: run everything at once and most finish late, and where value is time-sensitive the portfolio can run at an aggregate loss without any single project being mismanaged. Change nothing but the order and the level of concurrent work, and in a modeled portfolio that position can move from a loss to a substantial profit with the same people and the same budget. The size of that swing depends on how time-sensitive the value is in a given portfolio. The direction does not.

Why this travels well in client work

• It is tool neutral. The argument holds whatever the client already runs, so it does not require displacing an incumbent system to be useful.
• It is testable on the client's own data. The inputs are work, people and value, all of which they have.
• It separates the two recommendations that usually get conflated: a capacity shortage is solved by hiring, a sequencing leak is solved by changing what the scarcest people touch first. Those are opposite problems, and only one of them costs money.