Prioritisation under constraint

Prioritisation is the discipline of deciding what not to do. There is always more demand than capacity, and the job is to sequence work so that the most important outcomes happen first and to say no, clearly and early, to the rest. The competency is not a technique for ranking a list; it is the habit of reasoning explicitly about value and cost of delay rather than reacting to whoever asked loudest or most recently, and the nerve to make the resulting trade-off visible to the people who lose by it. It matters because the alternative is not a different set of priorities but the absence of any: everything started, nothing finished, and a team or an organisation that is fully busy and produces little. The examinations test it at every scope because the failure is so recognisable — the yes to everything, the thirty priority-ones, the failing initiative kept alive by its sponsor — and because the defensible answer nearly always surfaces a trade-off that the comfortable answer absorbs.

1. Sequence by value and cost of delay, not by advocacy. The question is what the organisation loses for each week a piece of work is not shipped, compared with the alternatives. Who asked, how loudly, and how recently are not inputs.
2. Say no by surfacing the cost of yes. The strong form of no is never flat refusal; it is trade-off transparency: "we can do this, and that slips — which do you want?" The stakeholder makes an informed choice and the manager has not absorbed the cost silently.
3. Starting less finishes more. Work in progress trades against throughput. The more that is started, the slower everything finishes, and a system loaded to full utilisation has no capacity to absorb the surprise that is always coming. Busy-looking is not effective.
4. Defend focus against churn. Reprioritising so often that nothing ships is a failure of prioritisation, not evidence of responsiveness. A priority that changes weekly is not a priority.
5. Own the trade-off at the level where the conflict lives. When teams compete for a shared bottleneck or resist lending people to an initiative, the manager above them decides against a single ranked view and names what slips. Refereeing is not deciding.
6. A portfolio is small enough to finish. At organisational scale, adding parallel initiatives does not add throughput; it adds the appearance of progress while everything decelerates. Fewer concurrent initiatives, explicitly ranked and sequenced to finish, is the intervention.

The economics of prioritisation rest on queueing theory, which is mathematics; its management application rests on practitioner work with clear provenance, and the unit grades it as practice.

Cost of delay practice

The value lost per unit of time that a piece of work remains unshipped, set out for product development in Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (2009) as the single number that should drive sequencing. Its power is that it converts arguments about importance into arguments about economics: work with a high cost of delay and a short duration goes first, whatever its advocate's seniority. Most delay costs are estimates, and the discipline is to treat them as explicit assumptions to argue about rather than false precision that launders opinion into arithmetic.

Work-in-progress limits and flow practice

From the same source, the queueing insight that a system loaded to full utilisation has unbounded queue times, and its practical corollary: constrain how much is in flight so the most important things finish sooner. Starting less finishes more. The model's limits are operational — a work-in-progress limit needs enforcement at intake or it becomes decoration, and the slack it creates must be defended as capacity rather than harvested as laziness.

Urgent versus important practice

The distinction popularised in Stephen R. Covey, The 7 Habits of Highly Effective People (1989) and attributed to a remark of Dwight Eisenhower's: separate what demands attention now from what matters most, because urgency systematically crowds out importance unless deliberately resisted. It is a lens, not a scheduler. Real work is often both, and the discipline it points at is funding the important-but-quiet work, not labelling quadrants.

Trade-off transparency practice

Not a named model but the practice this standard treats as the core of saying no: state what the request costs in terms of what else moves, and let the person who wants it choose. It converts a refusal into a decision the stakeholder owns, it keeps the manager from silently absorbing demand, and it makes the queue's reasoning visible. Its provenance is ordinary practice; its absence is the most common prioritisation failure the examinations present.

Portfolio governance practice

The organisational form of the same discipline: an explicit, ranked, deliberately small set of concurrent initiatives, reviewed on a cadence against evidence, with the ranking used to settle resource contention by strategy rather than politics. It has no single author; it is what every organisation that finishes things has converged on, and its absence is what "thirty priority-ones" describes.

The ranked queue with reasons

The team's work is held in one ordered list, and beside each item near the top is the reason it is there: the outcome it serves and what it would cost to delay. New requests are placed in the list, not added to it, and the placement is the conversation with the requester. A queue whose order cannot be explained is not prioritised; it is accumulated.

The cost-of-yes conversation

When a stakeholder asks for something new, the manager answers with what moves: "yes, and this slips to next month — is that the trade you want?" The stakeholder decides. The manager records the decision where the next stakeholder will see it, so the queue's history is visible and the trade-offs compound into a record rather than a grievance.

Limiting what is in flight

The team agrees how many things it will have open at once and holds to it at intake. When the limit is reached, something finishes before something starts. The number is less important than the enforcement; a limit that is exceeded whenever someone senior asks is a suggestion.

One voice to a shared dependency

Where several teams depend on the same bottleneck, their manager sets a single ranked list across the teams and represents it once, ending the internal competition. Each team escalating its own request separately is not three escalations; it is the absence of a decision.

The portfolio review

At organisational scale, a regular, evidence-based review of the initiatives in flight: what each is meant to produce, whether it is producing it, and what the ranking implies for contention. The output is sometimes a stop. An initiative that is clearly failing gets the honest recommendation whatever its sponsorship, because sponsorship is not a reason to keep spending the organisation's capacity.

At team scope the object is the team's queue and the manager sequences it directly, protecting one team's focus against noise. At organisational scope the object becomes competing priorities across several teams and the shared bottleneck they contend for, and the characteristic move is a single ranked view represented with one voice, with work in progress limited across the group and the staffing trade-offs owned rather than refereed. At executive scope the object is the portfolio: which bets the organisation makes, which it declines, and which it stops, with the ranking settling contention for scarce senior people by strategy rather than by whoever shouts. The pattern is in How Judgment Scales; the strategy the portfolio serves is SV-1 Engineering strategy.

• Holds an explicitly reasoned queue and can say why each item near the top is there. team
• Surfaces the cost of yes and lets the stakeholder choose, rather than absorbing the request. team
• Defends the team's focus against the churn of constant reprioritisation. team
• Recognises that a team with ten things in progress and nothing shipped has a prioritisation problem, not a capacity problem.
• Failure mode — loudest-voice prioritisation. team
• Failure mode — saying yes to everything and quietly missing everything. team
• Failure mode — treating every "urgent" as important. team
• Failure mode — reprioritising so often that nothing ships. team
• Sets one ranked view of demand across several teams and represents it to shared dependencies with one voice. org
• Limits work in progress across the group so that the most important things finish. org
• Owns the staffing trade-off for a cross-team initiative — decides against the department's priorities, names what slips — instead of refereeing three managers' reluctance. org
• Fixes intake as a system: one visible front door, stakeholders redirected consistently, engineers backed when they redirect. org
• Failure mode — letting each team fight its own escalation war. org
• Failure mode — measuring health by how busy every team is. org
• Failure mode — punishing engineers for accepting work the intake system failed to catch. org
• Keeps the portfolio small enough to finish, explicitly ranked and sequenced. exec
• Uses the ranking to settle contention for scarce senior people by strategy, once, rather than by sponsor. exec
• Recommends stopping or descoping a failing initiative regardless of its sponsorship. exec
• Leads a crisis reallocation through explicit priorities and through leaders, over-communicating the reasoning. exec
• Failure mode — thirty priority-ones. exec
• Failure mode — measuring the organisation by initiatives started. exec
• Failure mode — letting sponsorship immunise failing work. exec
• Failure mode — personally micromanaging a crisis shuffle instead of leading it. exec

Focus versus responsiveness. A queue that never changes ignores new information; one that changes weekly ships nothing. The judgment is in the size of the change that justifies a re-sequence, and in making re-sequencing an explicit decision with a stated reason rather than a reflex.

Local versus global. Every team maximising its own throughput misaligns the whole; every decision taken centrally slows the parts. The resolution is where the ranking lives: priorities and boundaries set at the level that sees the whole, sequencing within them left to the teams.

Utilisation versus flow. A fully busy team looks efficient and is one surprise from missing everything. Deliberate slack looks like waste and is what lets the important things finish on time. Defending slack against people who read it as idleness is part of the competency.

Sponsorship versus evidence. A failing initiative with a powerful sponsor is politically expensive to stop and organisationally expensive to continue. The honest recommendation is owed whatever the sponsorship, and the judgment is in how it is delivered — with the evidence, with options, and early.

Decisiveness versus consensus. In a crisis, a clean priority call made quickly beats a consensus reached late; in steady state, a ranking imposed without hearing the teams is resisted and gamed. The scope of the situation decides which mode applies, and the failure is using the crisis mode all the time or the consensus mode in a crisis.

A head of engineering inherits an organisation of twelve teams with thirty initiatives in flight, every one of them labelled a top priority by someone. Nothing has finished cleanly in two quarters. Each team is fully allocated, several engineers are on three initiatives at once, and the two most senior engineers in the organisation are being fought over by two strategic programmes whose sponsors are both on the executive team. The previous head of engineering's response had been to add a programme office and a weekly status meeting, which produced a very good dashboard.

The pull is to fix the coordination: better tracking, clearer dependencies, a more senior programme manager. That treats the symptom. Thirty concurrent initiatives across twelve teams is not a coordination problem; it is the absence of prioritisation, and no amount of visibility makes it finish. Adding parallel initiatives at this scale does not add throughput; it adds the appearance of progress while everything slows down.

The head of engineering forces a real ranking. With the executive team, they list the thirty initiatives, attach to each the outcome it serves and the cost of a quarter's delay, and rank them. They then draw a line: the organisation will run the top eight to completion, sequence the next ten behind them, and stop or fold the rest. The stopped initiatives are named, with the reason, to their sponsors and to the organisation, because an initiative that is quietly starved is worse than one that is explicitly stopped. The two senior engineers go to the higher-ranked of the two strategic programmes, and the sponsor of the other hears the reason from the ranking, not from a negotiation.

Two things are done deliberately. The ranking is published, so that the next contention for a scarce person is settled by looking at the list rather than by escalation. And the programme office is kept, but its weekly meeting is repurposed from reporting status to examining evidence against the ranking — whether the top eight are producing what they were meant to, and whether any should stop.

The costs are real. Three sponsors are unhappy, one initiative with a powerful backer is among those stopped, and the organisation spends a month re-sequencing. What the head of engineering does not do is keep thirty things alive to avoid the unhappiness, because that is the choice that produced the two quarters in which nothing finished.

• DE-2 Estimation, planning, and honest commitments — commitments that follow from the sequence, and the honesty about uncertainty they require.
• DE-4 Managing scope, risk, and dependencies across workstreams — the dependencies and shared bottlenecks a ranked view has to account for.
• SV-1 Engineering strategy — the strategy the queue and the portfolio exist to serve.
• SV-3 Roadmapping — roadmapping as the same trade-off between product delivery and platform investment, over a longer horizon.
• PL-1 Delegation, ownership, and decision rights — delegating the sequencing within boundaries the manager sets.

1. Why is "we can do this, and that slips — which do you want?" stronger than a flat no?
   Answer

   Because it converts a refusal into a decision the stakeholder owns, makes the trade-off visible instead of absorbed, and leaves the queue's reasoning on the record. A flat no invites escalation; a visible cost invites a choice.
2. A team has ten things in progress and has shipped nothing in three weeks. Is the problem capacity?
   Answer

   Almost never. Work in progress trades against throughput; starting less finishes more. The intervention is a limit on what is in flight, enforced at intake, not more people.
3. Three of your teams each escalate a competing request to the same platform team. What does strong judgment do that forwarding the escalations does not? org
   Answer

   Sets a single prioritisation across the three teams and represents it to the platform team once, ending the internal competition. Forwarding three escalations is not three decisions; it is the absence of one.
4. Three managers each refuse to lend people to a cross-team initiative. Whose trade-off is it? org
   Answer

   Yours. Decide against the department's priorities, name what slips in consequence, and own that cost. Refereeing the reluctance lets the initiative starve politely.
5. Why does adding parallel initiatives reduce an organisation's throughput, and what does that imply for portfolio size? exec
   Answer

   Because people and shared dependencies are then contended for across more work, queue times grow without bound as utilisation approaches full, and everything decelerates while the appearance of progress rises. The portfolio should be small enough to finish: fewer concurrent initiatives, explicitly ranked and sequenced.
6. An initiative is clearly failing and has a powerful executive sponsor. What is owed? exec
   Answer

   The honest recommendation — stop or descope — with the evidence and options, early. Sponsorship is not a reason to keep spending the organisation's capacity, and the judgment is in the delivery, not in whether to deliver it.
7. What is the difference between leading a crisis reallocation and micromanaging one? exec
   Answer

   Leading is making the priority call cleanly, delegating the execution of the shuffle to leaders, and over-communicating the reasoning. Micromanaging is personally moving people, which stops the executive from running the system that runs everything else.

• Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (2009) — cost of delay; work in progress, utilisation and queue times.
• Stephen R. Covey, The 7 Habits of Highly Effective People (1989) — the urgent-versus-important distinction as popularly framed.