Skip to content

Lesson 2 — Portfolio, Programme, and Prioritisation

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Explain the difference between project, programme, and portfolio as decisions, not as definitions.
  2. Explain why prioritisation is primarily a capacity decision and only secondarily a value judgement.
  3. Apply weighted scoring, economic ranking, cost-of-delay reasoning, and strategic bucketing to a small set of competing projects, and say what each method assumes.
  4. Build a constraint-aware sequence — dependencies, scarce skills, fixed dates — and show why the ordered list changes when a constraint changes.
  5. Recognise the failure modes of portfolio management: false precision, gaming, sunk-cost commitment, and strategy that changes faster than the portfolio does.
  6. Say what programme governance does that project governance cannot.

Prerequisites

  • Module 01 Lesson 2, for the vocabulary of projects, programmes, and portfolios.
  • Module 07 Lesson 2, because prioritisation depends on estimates that carry a range and a basis.

Introduction

Nothing in the core course prepares you for the moment when the work in front of you cannot all be done. Every single-project technique assumes the project exists; portfolio management is about the prior decision — which projects should exist, in what order, given the organisation's actual capacity.

Three sentences are worth keeping in mind throughout this lesson:

  • If you can do everything on the list, you do not have a portfolio problem; you have a scheduling problem.
  • If the list never changes, you are not prioritising; you are describing.
  • If the order changes every month, either the strategy is genuinely moving or the scoring is noise.

1. Project, programme, portfolio — as decisions

Level The decision it exists to make The failure when it is confused with another level
Project How do we deliver this defined outcome? Managed as a portfolio item: nobody is accountable for the delivery
Programme How do these related projects, delivered together, produce a benefit none would produce alone? Run as separate projects: interfaces, sequencing, and shared benefits are nobody's job
Portfolio Given finite capacity, which of these should we do, in what order, and which should we stop? Run as a set of projects: every project is staffed, so all of them slip

A programme exists when the benefit is joint. If two projects would each deliver their own benefit independently, they are two projects that happen to share staff, and calling them a programme adds meetings without adding coordination. If neither delivers value until both are live — a new customer record system and the migration that populates it, for example — then sequencing, shared design, and a joint benefits case are genuine programme responsibilities.

2. Why prioritisation is a capacity decision

Prioritisation is usually presented as picking the most valuable work. That framing produces a list nobody follows, because value is not the binding constraint — capacity is. Three consequences follow, and they explain most portfolio dysfunction:

  1. An ordered list is a statement about the future allocation of people. If two top-priority items need the same scarce skill, one of them is not actually top priority; it is waiting.
  2. Starting more work reduces throughput. Every additional concurrent project consumes coordination effort, extends the elapsed time to finish each one, and delays the benefit. The effect is the same one that work-in-progress limits address inside a team, applied across a portfolio.
  3. The real question is rarely "what is most valuable?" but "what do we stop?" A portfolio that has never stopped anything is not being managed; it is accumulating.

A capacity-aware prioritisation therefore produces an ordered list with the capacity each item needs and the date it could start, plus an explicit statement of what is not being done in the period.

3. Four prioritisation approaches, and what each assumes

Approach How it works Assumes Fails when
Weighted scoring Criteria with weights, scored per candidate, total orders the list Scores are comparable and weights reflect real strategy Weights are reverse-engineered to justify a decision already taken
Economic ranking Compare expected value with cost: net present value, payback, return Benefits can be estimated in money Soft benefits matter and get valued at zero
Cost of delay Rank by the value lost per unit of delay, not by total value Delay cost can be reasoned about, even roughly Nobody will name a figure, so it collapses to opinion
Strategic buckets Allocate the budget across categories first (regulatory, retention, growth, platform), then rank within each Strategy can be expressed as proportions Buckets become fixed entitlements defended by their owners

Two of these deserve more than a table row.

Cost of delay reframes prioritisation usefully: a small item that loses value very quickly can outrank a large item that loses value slowly. The practical technique of dividing cost of delay by duration to produce a single ranking figure is described in the delivery-flow literature — Donald Reinertsen's Principles of Product Development Flow is the usual citation, and the Scaled Agile Framework calls the resulting measure weighted shortest job first. The caution belongs beside the method: the inputs are judgements, and multiplying two judgements does not make them precise. Its value is that it forces the two questions to be asked explicitly — what does delay cost us? and how long will this take? — which is more than an unranked list of "high priority" items achieves.

Strategic buckets are the honest answer to a common problem: that ranking every candidate on one scale means the platform work, whose benefit is diffuse and slow, always loses to the feature work, whose benefit is visible and immediate. Allocating proportions first — for example a fixed share to regulatory obligations, a share to keeping the platform supported, and the remainder to feature work — makes the trade-off explicit rather than implicit.

4. Constraint-aware sequencing

An ordered list becomes a plan only when it meets capacity, dependencies, and fixed dates.

Constraint What it does to the order What to record
Scarce skill Creates a queue that may outlast the project's window Which skill, how many people, and the queue length
Hard dependency Forces sequence regardless of value The dependency, its owner, and the date it must be resolved
Regulatory or contractual date Becomes the anchor; everything else sequences around it The obligation and its source, not an assumed date
Shared component or platform Makes one item's design decision a constraint on others Interface decisions and who owns them
Benefit timing Can justify doing the second-best value item first The reason, written down

The test of a portfolio sequence is this: name the first item you would drop if a third of the capacity disappeared. If nobody can answer, the list is not ordered by anything that matters.

5. Programme governance and benefits realisation

A programme adds responsibilities that no project manages, and they need an owner:

  • Dependencies between projects — an interface decision on one project that constrains another.
  • Shared resources — the same specialist needed by two projects in the same month.
  • Joint benefits — measured once, after both are live, by someone who is not either project manager.
  • Consistent scope boundaries — the surest way to duplicate work is two projects each assuming the other builds the shared component.

Benefits realisation is the habit most organisations lack. The project delivers an output; the benefit appears later, and only if people use the output differently. Three rules make it more than a phrase:

  1. Name the benefit owner at approval, in the business case, not at closure.
  2. State the measure, baseline, and review date — and accept "baseline not yet established" as an honest entry rather than inventing a number.
  3. Review it after closure, on the benefit owner's calendar, not the project's.

6. Where portfolio management fails

Failure How it presents What actually helps
False precision Scores to two decimal places from inputs nobody believes Ranges and explicit judgements; state which inputs are guesses
Gaming Teams learn that certain criteria score well Rotate the criteria annually, and check whether scores correlate with what was approved anyway
Sunk-cost commitment A failing project survives because of what has been spent Decide on remaining cost against remaining benefit; the spend is gone either way
Strategy drift The strategy changed in March; the portfolio still reflects last year Revisit the ordering at a fixed cadence, not only when something goes wrong
Optimistic capacity Every project is staffed on the assumption that people are 100% available Capacity per skill per period, as in the resource plan
Portfolio theatre A quarterly prioritisation meeting that changes nothing Track whether the order actually changed, and whether anything was stopped

The deepest limitation is that portfolio management depends on estimates made before the work is understood, and on benefits that will be measured years later. Both are uncertain, so a portfolio process can only be as good as its willingness to revisit decisions. A portfolio that reorders on evidence and kills work that is not paying off is worth more than one with a perfect scoring model and no appetite for either.

Key terms

Term Meaning
Portfolio The set of investments an organisation chooses to make, managed as a group for balance and capacity
Programme Related projects whose benefit is joint and which must be coordinated to realise it
Capacity-aware prioritisation Ordering work against the people actually available, per skill and period
Cost of delay The value lost per unit of time that a piece of work is not delivered
Weighted shortest job first A ranking that divides cost of delay by duration to order work
Strategic buckets Allocating budget across categories before ranking within them
Benefits realisation Measuring whether the intended benefit actually occurred, after delivery
Benefit owner The named person accountable for a benefit being achieved and measured
Sunk cost Money already spent, which cannot be recovered and should not influence the next decision

Worked example

Task: prioritise three candidate projects for a department with two full-time developers over one quarter. All figures are invented for teaching.

Step 1 — Write the candidates with their value, cost, and delay characteristics. (A) Online application form for one programme — high visible value, four weeks of one developer, delays cost little because the window is months away. (B) Regulatory reporting change required by an external body — mandatory once in force, three weeks, with a fixed compliance date; delay is not a lost opportunity but a breach. (C) Platform upgrade to the shared authentication component — modest direct value, five weeks, but until it is done every other feature carries ad-hoc security work whose cost grows with each release.

Step 2 — Apply weighted scoring to expose the disagreement before the decision. Criteria: user value (30%), strategic fit (20%), cost of delay (20%), risk reduction (20%), effort (10%). A scores highest on user value and strategic fit; B is unremarkable on value but must be done; C scores highest on risk reduction and lowest on user value. The scores are close, which is itself the finding: weighted scoring rarely produces a decisive answer among real candidates, and the useful output is the profile of strengths and weaknesses rather than the total.

Step 3 — Apply the capacity test, which is decisive here. Two developers, one quarter, roughly 20 working days each after leave and support: about 40 person-days. A is 20, B is 15, C is 25 — total 60 person-days against 40 available. The portfolio is over capacity by 50%, so no ordering makes all three fit. This step is the one that changes the conversation: the question is no longer which is best but which combination fits.

Step 4 — Sequence against the constraint, not the score. B has a fixed compliance date and is not optional: it goes first. A and C cannot both fit in the remaining 25 days (A needs 20, C needs 25), so one is deferred. The deciding argument is not value but the cost of the deferral: deferring A loses the current window for one programme and creates no new cost; deferring C means five more weeks of ad-hoc security work on every release, which will also slow A when A is eventually built. C goes second and A moves to the next quarter — an ordering that the weighted scores did not produce, because the scores did not model the interaction between the items.

Step 5 — Record what is not being done, and why. The decision record states: B, C this quarter; A deferred by one quarter; total demand 60 person-days against 40 available; the reason for choosing C over A; and the trigger that would reopen the decision (if A's window closes permanently, the deferral is no longer acceptable). Without this paragraph, the same argument is rehearsed three weeks later.

Step 6 — Set the benefits and their owners. B's benefit is compliance, owned by the operations manager, measured by the reporting deadline being met. C's benefit is a measurable reduction in ad-hoc security work, owned by the technical lead, measured by the count of such changes in the following quarter. A's benefit is attributed to the quarter in which it is delivered, and the benefit owner is named then. Note that C's baseline either exists or is explicitly marked as not yet established — no invented percentage.

Common misconceptions

“If everything is high priority, prioritise harder”

If everything is high priority, the constraint has not been stated. Ask for the capacity figure and the skill mix first: the list is usually over capacity by a large factor, and the honest output is a shorter list plus a written record of what was deferred.

“A scoring model gives us an objective answer”

It makes criteria explicit and comparable, which is genuinely useful. It does not make the weights or the scores objective, and it cannot model interactions between items — as Step 4 above shows. Treat the score as a way to structure the argument, not as the decision.

“We cannot stop it now, we have spent too much”

That is the sunk-cost error. The only relevant question is whether the remaining cost is worth the remaining benefit. Money already spent is the same whether the project continues or stops.

“Programme management is just managing several projects”

It is not, and the difference is the reason programmes exist. Interfaces, shared resources, sequencing, and joint benefits belong to no individual project, so unless someone owns them they are unowned — which is exactly how two projects end up building the same component.

Practical activity

Prioritise a portfolio you can see — your own organisation's work, or four capstone-scale projects.

  1. List four to six candidates with, for each: the outcome, the capacity it needs (per skill), the earliest it could start, and what delay would cost.
  2. Score them against four weighted criteria. Then answer in one sentence what the scores disagree about — if they do not disagree, the criteria are duplicates.
  3. Write down the capacity available per skill for the next quarter, and total the demand. Compute the ratio.
  4. Produce a sequence that fits capacity. Name the item you would drop first if capacity fell by a third.
  5. Write a one-paragraph decision record: what is being done, what is deferred, the reason, and the trigger that would reopen the decision. Name a benefit owner for each item being done.

What "good" looks like: a demand-to-capacity ratio that is honestly above 1, at least one item explicitly deferred, a sequence that reflects a constraint rather than a score, and a reopen trigger that could actually happen.

Self-assessment

  1. Why is prioritisation better described as a capacity decision than a value judgement?
  2. When does a group of projects deserve to be called a programme, and what does the programme level own?
  3. What does cost of delay add to a ranking, and what is its main weakness?
  4. Two projects need the same specialist in the same month. What are your options, and which is the honest one when the specialist is genuinely unavailable?

  5. Why should a decision to stop a project ignore what has already been spent?

  6. Apply it — prioritisation. A portfolio office publishes a ranked list of fourteen funded projects and asks each team to “deliver in priority order”. Six of the fourteen need the same two integration specialists, and the list does not mention it. Everyone is now told to proceed at once.

    Hint: A strong answer says why the list is unworkable and what has to replace it.

Show answers
  1. Because value does not constrain what you can do — people and time do. Two items of equal high value requiring the same scarce skill cannot both be top priority. Ordering work is therefore a statement about how people will be allocated, and it only becomes actionable when capacity is stated per skill and period.
  2. When the benefit is joint: neither project delivers the intended outcome alone. The programme level then owns interfaces and shared design decisions, sequencing, shared resources, joint benefits, and a consistent boundary between the projects so they do not duplicate work.
  3. It makes speed of value an explicit factor, so a short item whose value decays quickly can outrank a larger item whose value decays slowly. Its weakness is that both inputs are judgements, so dividing one by the other produces a precise-looking number from imprecise reasoning — useful for forcing the two questions to be asked, not for settling the decision mechanically.
  4. Options: resequence one project so the specialist's work falls in different periods; substitute a less specialised person with a review from the specialist; reduce scope so less of the skill is needed; or defer one project. If the specialist is genuinely unavailable, the honest answer is to defer or reduce scope — a plan that assumes the person will somehow be available in both projects is not a plan.
  5. Because the money is already spent in either case: continuing or stopping does not recover it. The decision that matters is whether the remaining cost buys more remaining benefit than the alternatives, which is a forward-looking question. Letting past spend influence it commits good money after bad and delays the point at which capacity is freed for something better.
  6. Prioritisation is first a capacity decision: ordering fourteen projects when six depend on the same two scarce people produces a list that cannot be executed, and instructing everyone to start guarantees that all fourteen are partially done and none is finished. Replace the ranking with a constraint-aware sequence: start from the capacity of the specialists, not from the value ranking, and re-order so no more than the available number of specialist-dependent projects are in flight; then check the other shared constraints (environments, security review, a single product owner, one vendor). Where the value ranking and the capacity sequence disagree, the decision to hold or defer a high-value project is the portfolio's to make explicitly — and the cost of that delay is the number to weigh, not a quiet assumption that teams will find a way. Two failure modes to name: a list nobody follows, and work started to hold a claim on budget.

Summary

  • Project, programme, and portfolio each exist to make a different decision: delivery, joint benefit, and allocation of finite capacity.
  • Prioritisation is principally a capacity decision. Ordering an over-capacity list without stating the capacity produces a list nobody follows.
  • Weighted scoring, economic ranking, cost of delay, and strategic buckets each make different assumptions; scoring structures the argument but does not settle it, and cannot model interactions between items.
  • Constraint-aware sequencing — scarce skills, hard dependencies, fixed dates, shared components — is what makes an ordered list into a plan.
  • Programmes own the things no project does: interfaces, shared resources, sequencing, and joint benefits. Benefits need an owner, a measure, a baseline, and a review date after closure.
  • Portfolio management fails through false precision, gaming, sunk-cost commitment, and strategy drift. Its health is measured by whether the order changes and whether anything is ever stopped.

Further learning

Two verifiable sources for the techniques named above: Donald G. Reinertsen, The Principles of Product Development Flow (2009), for cost of delay and queueing reasoning in product development; and the Scaled Agile Framework's description of weighted shortest job first, which is documented publicly by Scaled Agile, Inc. Both are frameworks with commercial interests, so read them as one view of flow economics rather than as research findings.