---
title: "PortfolioOps"
slug: portfolioops
category: product
term_status: ambiguous
evidence_status: verified
summary: "PortfolioOps is not a standard term. On this page it means running portfolio management as a continuous operation: deciding which change initiatives get money and people, in what order, how many at once, and when to stop them."
audience: [Beginners, PMO and portfolio leads, CFO and CIO staff, Product and engineering executives]
last_verified: 2026-10-23
key_takeaways:
  - "The one-word label has no standard meaning; 'portfolio operations' also names private-equity value creation and fund back-office work. The practice taught here is established as portfolio management (PMI, ISO 21504) and Lean Portfolio Management (SAFe)."
  - "Treat the portfolio as a queue in front of scarce capacity: the decisions that matter are order, the number of initiatives in flight, and when to stop."
  - "Cost of delay makes urgency explicit; dividing it by duration (CD3) minimises total delay cost when independent items are worked one at a time. Additive relative scores can rank the same backlog worse; prerequisite chains must be ranked as units."
  - "Starting everything at once delays every benefit; a WIP limit set from capacity, not from ambition, brings value forward without starving teams."
  - "Decide stop-or-continue on remaining cost, remaining value and the cost of stopping, with the same estimate uplift applied to the queued alternative; money already spent is not an argument."
  - "Judge the function by decisions: stops, reallocations, decision latency and benefits realised against benefits promised."
related: [projectops, agileops, productops, bizops, finops, decisionops]
---

## What PortfolioOps is

### In 30 seconds

As one word, **PortfolioOps** names no recognised discipline or job family. **On this page it means running portfolio management
as a continuous operation**: one front door for proposed change, a price on waiting, a limit on how many initiatives run at once,
and a regular review that continues, re-scopes, stops or re-funds work on current evidence. The practice underneath is
established. PMI publishes *The Standard for Portfolio Management*,[^pmi4] ISO publishes guidance on project and programme portfolio
management,[^iso21504] and the Scaled Agile Framework (SAFe) defines Lean Portfolio Management (LPM) as aligning "strategy and
execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and
governance".[^safelpm]

::: note Four uses of the words "portfolio operations"
1. **Private equity.** Investment firms run "portfolio operations" teams that improve the companies they own; Private Equity
   Wire reported that one firm's team would manage value creation in "strategic planning, talent design and alignment, sales and
   marketing effectiveness, as well as acquisitions and integration".[^pewire]
2. **Asset management.** A job advert for a senior portfolio operations analyst at an asset manager lists trade booking,
   settlement, margin, corporate actions and daily position and cash reconciliations.[^vident]
3. **Portfolios of change in an enterprise.** "Agile portfolio operations" is one of the three areas in SAFe's LPM definition;[^safelpm]
   Salesforce advertised a strategic portfolio operations role in June 2026 whose duties included portfolio planning, intake,
   prioritisation, governance and portfolio data quality.[^sfjob]
4. **A brand or project name.** The one-word form names a personal open-source dashboard[^ghpo] and, in search results, a small
   advisory practice whose pages refused automated access; nothing here is drawn from it.

This page uses meaning 3. Choosing it, and calling it PortfolioOps, is an **editorial decision** of this Atlas, not an industry
definition. English Wikipedia had no article titled "PortfolioOps" or "Portfolio operations" when checked on 2026-10-23.
:::

**For** PMO and portfolio leads, executives who approve investment, leaders who compete for the same people, and beginners who
want to know why "we have too many priorities" is solvable.

### At a glance

| Item | Summary |
|---|---|
| Term status | **Ambiguous.** No body, standard or certification uses the one-word label; four uses (above). The practice is established under other names. |
| Goal | Fewer initiatives in flight, money following strategy, trade-offs visible and recorded. |
| In scope | Intake and triage; cost of delay, WSJF and appraisal; capacity, WIP limits and dependencies; funding models; stop-or-continue reviews; metrics, forums and tools. |
| Out of scope | Controlling one project → [ProjectOps](../projectops/); team cadence and flow → [AgileOps](../agileops/); work inside one product line → [ProductOps](../productops/); company cadence, OKRs and KPI tree → [BizOps](../bizops/); cloud spend → [FinOps](../finops/). |
| Prerequisites | How a project is planned and controlled ([ProjectOps](../projectops/)); reading a budget; percentages. Python 3 for the labs. |
| Key outputs | Portfolio register, intake form, allocation guardrails, ranked queue, WIP limit, review pre-reads, decision log, benefits record. |

### The problem PortfolioOps solves

Organisations start more than their people can finish, decide slowly, and keep funding what they funded last year. Three pieces
of evidence:

- **Queues dominate delivery time.** In the two years to October 2010, Maersk Line's IT pipeline took 150 days on average to deliver
  a requirement and 24% took over a year. One feature needed 82 hours of development and testing but took 46 weeks end to end,
  over 38 of them waiting; 29 were in the "fuzzy front-end", waiting to be prioritised and authorised.[^maersk]
- **Budgets move little.** Hall, Lovallo and Musters studied capital expenditure across the business units of 1,616 US
  multi-business companies from 1990 to 2005. For a third of the companies, each unit's capital in a given year was almost exactly
  the previous year's (a mean correlation of 0.99). The third that reallocated most moved 56% of capital across units over 15 years
  and earned about 30% higher annual shareholder returns than the least active third; over periods shorter than three years, high
  reallocators did worse.[^mck] This is a correlation about capital spending, not proof that reallocation causes returns, and not
  a study of change portfolios.
- **Estimates are optimistic, and selection rewards optimism.** HM Treasury's supplementary Green Book guidance, prepared from
  a 2002 study, opens: "There is a demonstrated, systematic, tendency for project appraisers to be overly optimistic."[^greenbook]
  The 2026 Green Book still requires explicit adjustments for it.[^greenbook2026] Bent Flyvbjerg argues that
  megaprojects are subject to "survival of the unfittest", which he uses to explain "why the worst projects get built instead of the
  best".[^flyv]

| Operating reality | Without a portfolio operation | With one |
|---|---|---|
| Intake | Many doors and sponsors | One front door; triage within a week |
| Priority | Whoever shouts loudest, or "all of them" | A ranked queue with stated cost of delay |
| Work in flight | Everything approved starts | Starts only when capacity frees |
| Budget | Last year's split | Theme allocation, moved quarterly on evidence |
| Bad bets | Continue because money is spent | Stopped or re-scoped; the stop recorded as a result |

### What PortfolioOps is not: naming and boundaries

- **Not financial portfolio management.** ISO 21504 states that it does not cover "other specific types of portfolio management
  (such as financial portfolio management)".[^iso21504] Ideas such as diversification are borrowed from finance, but investments in
  change are not tradeable securities with market prices.
- **Not a PPM tool.** Software records the portfolio; it does not decide it (see [anti-patterns](#anti-patterns-and-myths)).
- **Not a renamed PMO.** A PMO or value management office often runs it, but the decisions belong to a portfolio board.
- **Not project control.** Baselines, earned value and the critical path of one project belong to [ProjectOps](../projectops/).
- **Not the company cadence.** Annual planning, company OKRs and business reviews belong to [BizOps](../bizops/); PortfolioOps
  scores and chooses between investments inside that cadence (an **editorial split** agreed between the two pages).

## Where PortfolioOps comes from and where it sits

### Origins and evolution

The word comes from finance: Harry Markowitz's essay "Portfolio Selection" (1952) founded the theory of choosing investments by
expected return and risk, for which he shared the 1990 economics prize.[^markowitz] Applying the idea to organisational change grew
through public-sector IT control, professional standards and Lean product development:

| When | Milestone | Why it matters here |
|---|---|---|
| 1981 | F. Warren McFarlan, "Portfolio Approach to Information Systems", *Harvard Business Review*[^mcfarlan] | Carries the portfolio idea to information-systems projects |
| 2004 | US GAO publishes version 1.1 of its IT Investment Management (ITIM) framework, after a 2000 exposure draft, on the "select/control/evaluate" approach of the Clinger-Cohen Act of 1996[^gao] | Five maturity stages: an agency moves "from project-centric processes to a portfolio approach", then plans the "de-selection" of obsolete, high-risk or low-value investments |
| 2013 | Arnold and Yüce report cost of delay across a $100 million portfolio at Maersk Line[^maersk] | A documented case for quantified urgency and CD3 |
| 2017 | PMI, *The Standard for Portfolio Management*, fourth edition: "principle-based, making it applicable to a broad range of organizations, regardless of project delivery approach"[^pmi4] | The current PMI standard (October 2026) |
| 2018 | Sriram Narayan, "Products Over Projects"[^fowler] | The case for funding durable teams |
| 2022 | ISO 21504:2022[^iso21504] | International guidance on principles |
| 2025 | UK GovS 002, version 2.1[^govs002] | Expectations for government portfolios |
| 2026 | PMI's ANSI comment period (24 July to 7 September) for the fifth edition[^pmi5] | Not yet published on 2026-10-23 |

SAFe's LPM, the vendor category "strategic portfolio management" (SPM)[^planview] and the MoP (Management of Portfolios) guidance,
which PeopleCert now offers as "PRINCE2 Portfolio Management",[^mop] are other names under which the practice is sold, taught and certified.

### Glossary and mental model

| Term | Meaning on this page | Example |
|---|---|---|
| Portfolio | Change initiatives competing for one pool of money and people | All change in a bank's digital division |
| Initiative (epic) | Change large enough to need a portfolio decision | "Self-service mortgage renewal" |
| Cost of delay (CoD) | Value lost per unit of time by not having the outcome yet; Black Swan Farming calls it "the partial derivative of the total expected value with respect to time"[^bsfcod] | $30,000 per week |
| Delay cost | CoD accumulated over a period of waiting | 10 weeks × $30,000 = $300,000 |
| CD3 | Cost of delay divided by duration; a sequencing score[^maersk] | $30,000 ÷ 6 weeks = 5,000 |
| WSJF | Weighted shortest job first; in SAFe, "the relative cost of delay divided by the relative job duration"[^safewsjf] | (8 + 5 + 3) ÷ 5 = 3.2 |
| Guardrail | A standing rule that bounds spending decisions | "At most 15% on exploratory bets" |
| WIP limit | Maximum initiatives in implementation at once | 2 |
| Uplift | Multiplier on estimates from past actual-to-estimate ratios | Remaining cost × 1.4 |
| Benefits realisation ratio | Actual benefits ÷ projected benefits, as Narayan proposes tracking[^fowler] | 0.6 |

**Mental model: the portfolio is a queue in front of scarce capacity.** Every approved initiative waits for people, and value starts
only on delivery. The portfolio's job is not to rank a wish list once a year but to decide continuously what enters the queue, what
order it runs in, how many items run at once and which ones leave early. Little's law, proved by John Little in 1961, ties these
together: the average number of items in a system equals their average arrival rate multiplied by their average time in the
system.[^little] At a fixed delivery rate, more initiatives in flight means each one takes longer.

### How PortfolioOps relates to other Ops

::: figure What PortfolioOps receives from and hands to its neighbours
```mermaid
flowchart TB
  BZ["BizOps: strategy, OKRs, annual envelope"]
  FN["Finance: actuals, capitalisation rules"]
  P["PortfolioOps: rank, limit WIP, fund, stop"]
  PR["ProductOps: works inside stream budgets"]
  PJ["ProjectOps: delivers a funded mandate"]
  AG["AgileOps: team flow and capacity"]
  BZ <-->|"themes, money / results"| P
  FN -->|"actuals"| P
  AG -->|"capacity, flow data"| P
  P <-->|"budgets, guardrails / outcomes, epics"| PR
  P <-->|"mandate, stop criteria / forecasts"| PJ
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class P core
  class BZ,FN,PR,PJ,AG neutral
```
Text equivalent: BizOps passes strategic themes and the annual money envelope to PortfolioOps, and finance supplies actuals.
PortfolioOps ranks initiatives, limits work in progress, funds and stops. It gives ProductOps stream budgets and guardrails and
receives outcomes and cross-stream epics to rank; it gives ProjectOps a funded mandate with tolerances and stop criteria and
receives remaining cost and forecasts. AgileOps supplies team capacity and flow data, and reallocation results go back to BizOps.
:::

| Neighbour | Shared scope | This page's focus | Choose the neighbour when |
|---|---|---|---|
| [BizOps](../bizops/) | Planning cycles, reallocation | Scoring and choosing between investments | The question is the company's operating rhythm or KPI tree |
| [ProductOps](../productops/) | Roadmaps, prioritisation | Choices across product lines | The choice is inside one product's roadmap |
| [ProjectOps](../projectops/) | Business cases, stage gates, the PMO | Which projects exist and continue | The question is controlling one project to its baseline |
| [AgileOps](../agileops/) | WIP limits, flow, Kanban | WIP at the level of funded initiatives | The question is a team's cadence or flow metrics |
| [FinOps](../finops/) | Budgets, allocation, unit economics | Investment in change | The money is variable cloud spend |
| [DecisionOps](../decisionops/) | Recording and auditing decisions | Human investment decisions | The decision is automated and runs in software |

## Principles and operating model

### A proposed charter and principles

There is no published PortfolioOps manifesto; this charter is **this Atlas's proposal**, drawn from the sources cited.

**Mission:** spend the organisation's capacity for change on the work that is worth most now, and stop spending it on work that no
longer is.

1. **Plan on the capacity you have,** not the demand list. Black Swan Farming calls the "equity model" (fixed annual budget shares by department, stakeholder or large project) "largely blind to value".[^bsfprio]
2. **Limit work in progress.** SAFe's portfolio Kanban visualises and limits initiatives in progress;[^safelpm] Little's law says
   why it shortens time to value.[^little]
3. **Make urgency explicit.** Estimate cost of delay, even roughly; a ranking without it optimises for something else, typically cost
   and dates.[^bsfcod]
4. **Ignore sunk cost.** Decide on remaining cost and remaining value. GAO's mature stages plan the "de-selection" of low-value
   investments.[^gao]
5. **Correct for optimism with evidence, on every option.** Apply uplifts from your own history to new and in-flight cases alike;
   the Green Book asks for explicit adjustments to costs, durations and benefits,[^greenbook2026] based on data from past or similar
   projects.[^greenbook]
6. **Fund durable work durably.** Long-lived products get team funding; genuine bets get staged funding (Narayan: "A team gets
   funded").[^fowler]
7. **Write decisions down.** Each decision records its reasons, and a stop is reported as a result, not a failure.

**Non-goals:** approving every change centrally; precise scores; one tool for everyone.

### Building blocks

| Block | Minimum viable version |
|---|---|
| Portfolio register (owner, theme, stage, costs, remaining estimate, CoD, decisions) | A shared spreadsheet with a weekly data check |
| Themes and guardrails (allocation ranges, approval thresholds) | One page agreed by the board |
| Intake form (the lean business case) | The template in [Reference implementation](#reference-implementation-intake-guardrails-and-register) |
| Triage, portfolio Kanban and capacity model | 30 minutes a week; a five-column board; teams × weeks minus run-the-business work |
| Review cadence and benefits record | Monthly sync, quarterly review; three numbers per initiative at 3 and 12 months |

### Roles, ownership and RACI

- **Portfolio board.** Sets themes and guardrails and makes the continue, stop and reallocate decisions. SAFe describes portfolio leadership as "generally a team of people across business,
  technology, and finance".[^safelpm]
- **Portfolio office (PMO, VMO or portfolio operations).** Runs intake, the register, the cadence and the analysis; owns data
  quality. In SAFe the Value Management Office "is accountable for the portfolio's governance and day-to-day operations".[^safelpm]
  The Salesforce advert listed tooling, data quality, dashboards, time-tracking compliance and resource data.[^sfjob]
- **Initiative owner (epic owner, senior responsible owner).** Writes the case, estimates CoD with finance, reports indicators,
  proposes re-scopes.
- **Finance business partner.** Supplies actuals; challenges benefit estimates.
- **Delivery leads and value-stream owners.** Own capacity; say what fits.
- **Enterprise architect.** Maps dependencies and shared platform work.

| Activity | Board | Portfolio office | Initiative owner | Finance | Delivery leads |
|---|---|---|---|---|---|
| Set themes and guardrails | A | R | C | C | C |
| Triage intake | I | A/R | C | I | C |
| Estimate CoD and size | I | C | A/R | C | R |
| Set the WIP limit | A | R | I | I | C |
| Stop-or-continue decision | A/R | R | C | C | C |
| Benefits measurement | I | A | R | C | C |

R = responsible, A = accountable, C = consulted, I = informed. One A per row.

### Lifecycle of an initiative

::: figure The life of one initiative, including the stop path
```mermaid
stateDiagram-v2
  [*] --> Funnel
  Funnel --> Reviewing: triaged within a week
  Funnel --> Declined: duplicate or out of scope
  Reviewing --> Analysing: analysis slot free
  Reviewing --> Declined: low cost of delay
  Analysing --> Ready: lean case approved
  Analysing --> Declined: hypothesis too weak
  Ready --> Implementing: WIP slot free
  Implementing --> Done: outcome measured
  Implementing --> Rescoped: review says re-scope
  Rescoped --> Ready
  Implementing --> Stopped: review says stop
  Done --> [*]
  Stopped --> [*]
  Declined --> [*]
```
Text equivalent: Triage within a week declines duplicates and out-of-scope requests; review declines low cost of delay or pulls
the item into analysis when a slot is free; analysis ends in an approved lean case (ready) or a decline. Ready work starts only
into a free WIP slot. A review can stop it or return it to ready with a smaller scope; otherwise it ends when its outcome is
measured.
:::

The stages follow SAFe's portfolio Kanban, which removes work that does not advance the strategy.[^safelpm] Two rules make it
operational: nothing starts without a free WIP slot, and stopped is a normal exit, reported like any other.

### Operating model and governance cadence

| Forum | Cadence | Inputs | Decisions |
|---|---|---|---|
| Triage | Weekly | New requests | Decline, merge, park, analyse |
| Portfolio sync | Monthly | Register, Kanban, KPIs, dependencies | Unblock; pull ready work into free slots |
| Strategic portfolio review | Quarterly | Leading indicators, actuals, remaining estimates, queue | Continue, re-scope, stop; move allocation between themes |
| Allocation | Annually, revisited quarterly | Strategy, capacity plan | Theme ranges, WIP limits, approval thresholds |

SAFe describes the same rhythm: a strategic portfolio review "typically held on a quarterly cadence" and a portfolio sync "generally
held monthly".[^safelpm] **Escalation:** an initiative whose remaining cost or duration grows beyond an agreed tolerance (say 20%)
goes to the next review automatically, whatever its colour.

## Architecture and workflow

### Reference architecture: the portfolio operating system

For a business function, the architecture is decisions, records and feedback loops: standing rules, one front door, a queue with a
limit, and a review that feeds back into both the rules and the queue.

::: figure Reference architecture of a portfolio operation
```mermaid
flowchart TB
  S["Strategy and strategic themes"] --> G["Guardrails: allocation by theme, WIP limit, approval thresholds"]
  G --> I["Intake: one front door, lean case"]
  I --> T["Triage: cost of delay, size, fit"]
  T --> K["Portfolio Kanban: queue with WIP limit"]
  K --> D["Delivery: value streams, product teams, projects"]
  D --> B["Benefits and leading indicators"]
  B --> R{"Quarterly review"}
  F["Finance actuals and envelopes"] --> R
  R -->|"continue, re-scope, stop"| K
  R -->|"move allocation"| G
  R -->|"strategy no longer holds"| S
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class G,I,T,K core
  class R decision
  class S,D,B,F neutral
```
Text equivalent: Strategy sets themes; guardrails turn them into allocation ranges, a WIP limit and approval thresholds. Requests
enter one intake, are triaged on cost of delay, size and fit, and queue in a portfolio Kanban before delivery. Benefits, leading
indicators and finance actuals feed a quarterly review whose decisions return to the queue (continue, re-scope, stop), the
guardrails (move allocation) or strategy.
:::

| Component | Responsibility | Typical failure |
|---|---|---|
| Guardrails | Bound decisions without a meeting | Ranges so wide they constrain nothing |
| Intake and triage | Keep the funnel honest and fast | Side doors for senior sponsors |
| Portfolio Kanban | Make queue and WIP visible | Everything "in progress" |
| Review | Turn evidence into decisions | Status reading instead of deciding |
| Register | Single record per initiative | Stale or contested numbers |

**Alternatives.** A *centralised* model sends everything above a small threshold to the board: consistent but slow. A *federated*
model gives each value stream a budget and queue and leaves the board cross-cutting epics: faster, but needs mature stream leads.

### End-to-end workflow: from idea to stop-or-continue

**Happy path.** (1) A product director submits an intake form on Monday. (2) Thursday's triage: no duplicate, theme "customer
self-service", cost of delay $40,000 a week (a run-rate of about $2 million a year once launched and adopted, lost for each week of
delay), about 12 team-weeks; on to analysis. (3) Within two weeks the owner writes the lean case with a minimum viable release.
(4) At the monthly sync a WIP slot is free; it starts. (5) At the quarterly review the leading indicator is on track: continue.
(6) Benefits are recorded at three and twelve months after launch, and the uplift history is updated.

**Exception paths.** A late *regulatory deadline* item has zero cost of delay until its last responsible start date, then a very
high one (the external-deadline urgency profile[^bsfurg]): it enters the queue with a start date, not a jump to the top. An *overrun* breaches tolerance: it goes to the next review automatically, where remaining cost and value are re-estimated
([Lab 3](#lab-3-advanced-a-stop-or-continue-review)).

::: figure Quarterly review handoffs, from request for updates to capacity moves
```mermaid
sequenceDiagram
  participant O as Initiative owners
  participant P as Portfolio office
  participant B as Portfolio board
  participant T as Delivery teams
  P->>O: Request remaining cost, time, indicators
  O->>P: Updates with evidence
  Note over P: Merge finance actuals, apply uplift
  P->>B: Pre-read with proposals
  Note over B: Decide continue, re-scope, stop
  B->>P: Decisions and reasons
  P->>O: Decisions, reasons, next checkpoint
  B->>T: Capacity released or moved
```
Text equivalent: The portfolio office asks owners for remaining cost, time and indicators, merges finance actuals, applies the
uplift and sends the board a pre-read. The board decides continue, re-scope or stop and returns reasons; the office passes them to
owners with the next checkpoint, and the board releases or moves capacity with the delivery teams.
:::

## Practices, frameworks and tools

### Core practices and playbooks

| Practice | Trigger | Owner | Output | Verification |
|---|---|---|---|---|
| One front door | Any request above the team-level threshold | Portfolio office | Register entry | No team work without an entry |
| Weekly triage | New requests | Portfolio office | Decline, merge, park, analyse | Median days to triage ≤ 7 |
| Cost of delay estimate | Entry to analysis | Owner with finance | CoD per week, urgency profile, assumptions | Assumptions visible at review |
| WIP limit | Every start | Board, run by office | Starts only into a free slot | Active count never above the limit |
| Allocation by theme | Annual, reviewed quarterly | Board | Theme ranges | Spend by theme within range |
| Stop-or-continue review | Quarterly, or tolerance breach | Board | Decision with reasons | Stop rate not zero |
| Benefits check | 3 and 12 months after launch | Initiative owner | Realised versus promised | Realisation ratio tracked |

Maersk's teams aimed to triage all incoming requirements in less than a week, then held them in a dynamic priority list sorted by
CD3.[^maersk] The playbook for a new portfolio is to do the same before buying any tool.

### Prioritisation methods compared

| Method | How it ranks | Strengths | Weaknesses |
|---|---|---|---|
| CD3 (cost of delay ÷ duration) | Money per week of delay, divided by weeks | Units are explicit; minimises total delay cost under stated conditions (below; Lab 1) | Needs a value estimate; people resist putting numbers on value |
| WSJF as SAFe defines it | (user and business value + time criticality + risk reduction/opportunity enablement) ÷ job size, on relative scales[^safewsjf] | Fast, relative, workshop-friendly; ignores sunk cost | Adds value and urgency, which Black Swan Farming says "are NOT additive";[^bsfqual] size is only a proxy for duration |
| Weighted scoring model | Sum of criteria scores × weights | Captures non-financial criteria | Weights invite gaming; scores lack units; optimism wins |
| MoSCoW | Must, should, could, won't | Simple | Most items become "must"[^bsfprio] |
| Equity (fixed shares) | Each department, stakeholder or large project gets its share | Perceived as fair | "Largely blind to value"[^bsfprio] |

**WSJF and CD3 are not the same calculation.** Reinertsen's original WSJF, as SAFe's 2016 article summarises his 2009 book, divides cost of delay by duration; SAFe's version
divides the *sum* of three relative scores by relative *job size*. SAFe's 2016 article said "In systems with fixed resources, job
size is a good proxy for duration", and warned that when more people can be put on a larger job, duration should be used
instead.[^safewsjf2016] In Lab 1, with invented committee scores, the additive scores put a low-value, urgent-feeling item first
and cost about 9% more delay than CD3; other scores could rank well. Use WSJF as a conversation aid, and put money and duration
on the top candidates when the decision is expensive.

**Biases to design against.** Optimism (correct with uplifts[^greenbook]); strategic misrepresentation by sponsors competing for
funds (Flyvbjerg's "survival of the unfittest"[^flyv]); the highest-paid person's opinion ("HiPPO"[^bsfprio]); and anchoring on the
first estimate. Counters: finance challenges benefit estimates, assumptions are published next to scores, and each case is
compared with similar past outcomes.

### Financial appraisal, dependencies and portfolio balance

**NPV and cost of delay answer different questions.** Net present value (NPV) discounts expected cash flows to today and
subtracts the cost; a positive NPV at the organisation's discount rate says an initiative is worth doing at all. The UK Green Book,
for example, discounts public appraisals at 3.5% a year in real terms for the first 30 years.[^greenbook2026] Payback period, the
time until cumulative benefits repay the cost, is a cruder cash-and-risk screen that ignores everything after payback. Cost of
delay is the same expected-value model seen through time: value lost per week of slip.[^bsfcod] Use NPV or a benefit-cost ratio
for go/no-go and CD3 to order the work that passed; Lab 3 can discount long benefit streams.

**When CD3 is optimal, and when dependencies break it.** CD3 is Smith's ratio rule from scheduling theory (1956): if items are
ready now, independent, have a constant cost of delay and are worked one at a time, ordering by cost of delay ÷ duration minimises
total delay cost, and interrupting work cannot improve on it.[^eos] If B needs platform work A first, a plain ranking may put B
first or leave A last. For simple chains, when A must precede B and B scores higher, some optimal order runs B straight after A:
rank the pair as one item with combined cost of delay ÷ combined duration.[^eos] Record dependencies at intake and give enabling
work the cost of delay of what it unblocks, never zero.

**Balance is a choice the guardrails make.** Markowitz's theory is about efficient diversification: choosing a set of holdings by
expected return and risk, not the best single ones.[^markowitz] Initiatives that rely on the same platform, supplier or market
assumption succeed or fail together, so a list of attractive bets can be one concentrated bet. Theme ranges set the risk and
horizon mix deliberately instead of leaving it to the ranking.

### Funding models: projects versus value streams

| Question | Project funding | Value-stream (product) funding |
|---|---|---|
| What gets funded? | A defined scope, through a business case | A durable team or value stream, for a period, with periodic review[^fowler] |
| Who decides the next piece of work? | The portfolio board, case by case | The product owner within guardrails; the board decides cross-cutting epics |
| When is the case tested? | Mostly before approval; often no check after delivery[^fowler] | Continuously, through releases and measured outcomes |
| Portfolio's main levers | Approve, gate, stop projects | Size team budgets, set guardrails, run the epic Kanban, move budget between streams |
| Fits | Bounded change with fixed scope (a regulated migration, a contract) | Long-lived products and platforms |

SAFe's LPM replaces "project-based funding" with budgets allocated to value streams and governed by guardrails.[^safelpm] Narayan
lists a "halfway approach of project-mode funding and product-mode organization" among several "less-than-ideal variations".[^fowler] Either way, keep an explicit
queue for cross-stream work and a review that can stop it. Whether software spend can be capitalised depends on the accounting
framework and company policy: agree the rules with finance before changing the funding model.

### Standards and frameworks

| Source | Type | What it gives you | Binding? |
|---|---|---|---|
| PMI standard (4th ed., 2017; 5th in development)[^pmi4][^pmi5] | Professional standard (ANSI) | Principles and vocabulary | Only if adopted by contract or policy |
| ISO 21504:2022[^iso21504] | International guidance | Principles for project and programme portfolios | No |
| MoP, now PRINCE2 Portfolio Management (PeopleCert)[^mop] | Method and certification | Prioritisation, risk, benefits, governance, planning and delivery | No |
| SAFe Lean Portfolio Management[^safelpm] | Proprietary framework | LPM roles, portfolio Kanban, lean budgets, review events | No (licensed content) |
| US GAO ITIM (2004)[^gao] | Assessment framework | Five maturity stages for IT investment management | Used by GAO to assess US federal agencies |
| UK GovS 002, version 2.1 (2025)[^govs002] | Government functional standard | Expectations for portfolios, programmes and projects | For UK government bodies in scope |

### Tooling landscape

Start with the process and a shared register; buy software when data load, integrations or audit needs outgrow a spreadsheet.

| Category | Examples (as of October 2026) | Use when | Watch for |
|---|---|---|---|
| Register and BI | Spreadsheet or database plus a BI tool | Up to a few dozen initiatives; proving the process | Manual updates; version conflicts |
| Work-management portfolio views | Microsoft Planner premium features (portfolios, baselines, dependencies; Planner and Project Plan 3 licence);[^msmc] Atlassian Align (Jira Align)[^atlalign] | Delivery data already lives in that tool | Roll-ups that count tickets, not value |
| Strategic portfolio management suites | Planview;[^planview] Broadcom Clarity (ValueOps);[^valueops] Atlassian Focus[^atlfocus] | Many portfolios, financial integration, audit trails | Cost, configuration effort, lock-in |

**Lock-in is real.** Microsoft retired Project Online on 30 September 2026, after which its data is no longer accessible in the
service[^msproj] (the migration lesson is on [ProjectOps](../projectops/)). For a portfolio, test a full export of the register
and the decision history before signing, and again every year.

### Automation and AI

Automation earns its place on data, not decisions: duplicate detection at intake, reminders when an initiative's data is stale,
roll-ups of actuals from finance, and alerts when an initiative breaches tolerance. NISTA's AI early-warning tool, which flags
major projects at risk of a red rating, is covered on [ProjectOps](../projectops/).[^nista] Vendors advertise AI that drafts plans and surfaces risks;[^atlfocus] treat such features as
assistants to the portfolio office. Do not let a model rank investments: the inputs (benefit estimates) are the weakest data in the
system, and a confident ranking hides that.

## PortfolioOps in practice

### Reference implementation: intake, guardrails and register

A minimal, tool-neutral implementation for 20 to 60 initiatives: the intake form is the lean business case and the guardrails file
the board's standing policy, in plain YAML for version control or any tool.

_Example status: syntax-checked by the validator, not executed (operating artefacts, not code)._

```yaml
# intake.yaml - one per proposed initiative (lean business case)
id: INIT-2026-031
title: Self-service mortgage renewal
owner: product.director@example.com
theme: customer-self-service          # must match a theme in guardrails.yaml
problem: >-
  Renewals need a branch call; 30% of customers start renewing elsewhere.
outcome_hypothesis: >-
  If eligible customers can renew online, retention at renewal rises
  from 70% to 78% within two quarters of launch.
leading_indicators: [online renewal starts, completion rate]
cost_of_delay:
  per_week: 40000                     # currency units; arithmetic below
  urgency_profile: long-life-peak-unaffected
  assumptions: >-
    0.08 retention x 26,000 renewals a year x 1,000 margin per renewal
    = 2,080,000 a year / 52 = 40,000 a week, at full run-rate after
    launch and adoption; finance partner reviewed 2026-10-20.
size:
  team_weeks: 12
  confidence: low                     # low | medium | high
mvp: Online renewal for fixed-rate products only
dependencies: [core-banking-api-v3]
stop_criteria: Completion rate below 40% after 8 weeks live
```

```yaml
# guardrails.yaml - portfolio board policy, reviewed quarterly
portfolio: digital-division
capacity_team_weeks_per_quarter: 156  # 12 teams x 13 weeks
run_the_business_reserve: 0.30        # protected for operations and fixes
themes:                               # shares of change capacity (after reserve)
  customer-self-service: {min: 0.30, max: 0.45}
  cost-to-serve: {min: 0.20, max: 0.35}
  regulatory: {min: 0.10, max: 0.25}
  exploratory-bets: {min: 0.05, max: 0.15}
max_teams_per_initiative: 4
wip_limit_initiatives: 2              # (12 teams x 0.70) / 4 = 2.1, rounded down
approval_thresholds:
  value_stream_lead: "up to 6 team-weeks inside the stream's budget"
  portfolio_board: "above 6 team-weeks, or work across streams"
review:
  sync: monthly
  strategic_review: quarterly
  tolerance_for_auto_review: 0.20     # remaining cost or time growth
estimate_uplift:                      # from our own history, refreshed yearly
  cost: 1.4
  duration: 1.3
```

The register holds one row per initiative: id, title, owner, theme, stage, entry date, cost to date, remaining cost and weeks,
cost of delay, dependencies, last decision and date, next review, promised and measured benefit. A column with no owner goes.

### Hands-on labs

Python 3 standard library only; invented numbers; no cost or live system. Each lab takes 20–40 minutes in a new, empty folder.
The scripts were tested only with Python 3.8.10 (end of life; the only interpreter available) on 2026-10-23, and the outputs shown
are the actual outputs. They use no version-specific features, so a current Python 3 release should give the same results.

#### Lab 1 (beginner): sequence a backlog by cost of delay

**Objective:** compare sequencing rules by the delay cost they cause. **Prerequisites:** Python 3.

1. Save the script as `sequence.py`, the first JSON as `maersk.json` and the second as `backlog.json`.
2. Run `python3 sequence.py maersk.json`, then `python3 sequence.py backlog.json`.
3. Change P4's `tc` and `rr` scores to 2 and run again.

_Example status: verified by execution (Python 3.8.10, 2026-10-23)._

```python
"""Compare sequencing rules by the delay cost they incur.

Usage: python3 sequence.py backlog.json
Each item: cod (cost of delay, money per week), weeks (duration when
the whole capacity works on it), and committee scores (ubv, tc, rr,
size) on a 1-20 relative scale for the SAFe-style WSJF variant.
One item is worked at a time; delay cost accrues for every item not
yet delivered, so total = sum over items of cod x finish week.
"""
import itertools
import json
import sys


def delay_cost(order):
    week, total = 0, 0
    for item in order:
        week += item["weeks"]
        total += item["cod"] * week
    return total


def main(path):
    with open(path) as f:
        items = json.load(f)
    rules = {
        "FIFO (as listed)": list(items),
        "Highest CoD first": sorted(items, key=lambda i: -i["cod"]),
        "Shortest first": sorted(items, key=lambda i: i["weeks"]),
        "CD3 (CoD / weeks)": sorted(items, key=lambda i: -i["cod"] / i["weeks"]),
        "WSJF (scores / size)": sorted(
            items, key=lambda i: -(i["ubv"] + i["tc"] + i["rr"]) / i["size"]),
    }
    best = min(itertools.permutations(items), key=delay_cost)
    for name, order in rules.items():
        seq = " ".join(i["id"] for i in order)
        print(f"{name:<22}{seq:<12}{delay_cost(order):>10,.0f}")
    seq = " ".join(i["id"] for i in best)
    print(f"{'Best of all orders':<22}{seq:<12}{delay_cost(best):>10,.0f}")


if __name__ == "__main__":
    main(sys.argv[1])
```

```json
[
  {"id": "A", "cod": 1, "weeks": 5, "ubv": 1, "tc": 1, "rr": 1, "size": 5},
  {"id": "B", "cod": 4, "weeks": 1, "ubv": 4, "tc": 1, "rr": 1, "size": 1},
  {"id": "C", "cod": 5, "weeks": 2, "ubv": 5, "tc": 1, "rr": 1, "size": 2}
]
```

```json
[
  {"id": "P1", "cod": 40000, "weeks": 12, "ubv": 13, "tc": 8, "rr": 13, "size": 13},
  {"id": "P2", "cod": 15000, "weeks": 3, "ubv": 5, "tc": 3, "rr": 2, "size": 3},
  {"id": "P3", "cod": 90000, "weeks": 8, "ubv": 20, "tc": 13, "rr": 5, "size": 8},
  {"id": "P4", "cod": 5000, "weeks": 2, "ubv": 3, "tc": 8, "rr": 8, "size": 2},
  {"id": "P5", "cod": 25000, "weeks": 4, "ubv": 8, "tc": 5, "rr": 3, "size": 5}
]
```

**Expected output:**

```text
FIFO (as listed)      A B C               69
Highest CoD first     C B A               30
Shortest first        B C A               27
CD3 (CoD / weeks)     B C A               27
WSJF (scores / size)  B C A               27
Best of all orders    B C A               27

FIFO (as listed)      P1 P2 P3 P4 P5 3,625,000
Highest CoD first     P3 P1 P5 P2 P4 2,670,000
Shortest first        P4 P2 P5 P3 P1 3,000,000
CD3 (CoD / weeks)     P3 P5 P2 P1 P4 2,470,000
WSJF (scores / size)  P4 P3 P2 P5 P1 2,690,000
Best of all orders    P3 P5 P2 P1 P4 2,470,000
```

**Validation:** the first table reproduces the published Maersk example, in which first-in-first-out costs $69 and CD3 $27, a 60%
reduction.[^maersk] In the second, CD3 matches the best of all 120 orders; the additive WSJF scores put P4 (low value, scored urgent and
risk-reducing) first and cost 2,690,000 against 2,470,000. After step 3, WSJF moves P4 to second place and its delay
cost falls to 2,550,000, still above CD3. **Troubleshooting:** `KeyError` means an item lacks a field; a `ZeroDivisionError` means
a zero `weeks` or `size`. **Limits:** one item at a time, independent items and constant cost of delay; real portfolios run several
items in parallel, which Lab 2 covers. **Teardown:** delete the folder.

#### Lab 2 (intermediate): what a WIP limit does to time-to-value

**Objective:** see why starting everything delays everything, and why a limit set too low wastes capacity. **Prerequisites:** Lab 1.

1. Save the script as `wip.py` and run `python3 wip.py`, then `python3 wip.py 1 4`.
2. Change `MAX_TEAMS` to 6 and repeat.

_Example status: verified by execution (Python 3.8.10, 2026-10-23)._

```python
"""Start everything, or limit initiatives in progress?

Usage: python3 wip.py [wip_limit ...]
Model (deliberately simple): TEAMS teams; each initiative needs a fixed
number of team-weeks and can use at most MAX_TEAMS teams at once. Up to
`limit` initiatives run at a time and share the teams equally; a queued
one starts when another finishes. Value starts only on delivery, so
delay cost = cost of delay per week x finish week. All six are
requested at week 0. No switching cost is modelled; real switching
costs make high WIP worse.
"""
import sys

TEAMS, MAX_TEAMS = 12, 4
INITIATIVES = [  # (name, team-weeks of work, cost of delay per week)
    ("I1", 48, 30000), ("I2", 48, 30000), ("I3", 48, 30000),
    ("I4", 48, 30000), ("I5", 48, 30000), ("I6", 48, 30000),
]


def simulate(limit):
    left = {n: w for n, w, _ in INITIATIVES}
    cod = {n: c for n, _, c in INITIATIVES}
    queue = [n for n, _, _ in INITIATIVES]
    active, start, finish, week, wip_weeks = [], {}, {}, 0, 0
    while queue or active:
        while queue and len(active) < limit:
            start[queue[0]] = week
            active.append(queue.pop(0))
        share = min(MAX_TEAMS, TEAMS / len(active))
        week += 1
        wip_weeks += len(active)
        for n in list(active):
            left[n] -= share
            if left[n] <= 1e-9:
                active.remove(n)
                finish[n] = week
    delay = sum(cod[n] * w for n, w in finish.items())
    in_progress = sum(finish[n] - start[n] for n in finish) / len(finish)
    lead = sum(finish.values()) / len(finish)  # all requested at week 0
    return finish, delay, wip_weeks / week, len(finish) / week, in_progress, lead


def main(limits):
    print(f"{'WIP':>3}{'finish weeks':>20}{'delay cost':>12}"
          f"{'L':>6}{'lambda':>7}{'W':>6}{'L=lW':>6}{'lead':>6}")
    for limit in limits:
        finish, delay, L, lam, W, lead = simulate(limit)
        weeks = " ".join(str(finish[n]) for n, _, _ in INITIATIVES)
        print(f"{limit:>3}{weeks:>20}{delay:>12,.0f}{L:>6.2f}"
              f"{lam:>7.3f}{W:>6.1f}{lam * W:>6.2f}{lead:>6.1f}")


if __name__ == "__main__":
    main([int(a) for a in sys.argv[1:]] or [6, 3, 2])
```

**Expected output:**

```text
WIP        finish weeks  delay cost     L lambda     W  L=lW  lead
  6   24 24 24 24 24 24   4,320,000  6.00  0.250  24.0  6.00  24.0
  3   12 12 12 24 24 24   3,240,000  3.00  0.250  12.0  3.00  18.0
  2   12 12 24 24 36 36   4,320,000  2.00  0.167  12.0  2.00  24.0
WIP        finish weeks  delay cost     L lambda     W  L=lW  lead
  1   12 24 36 48 60 72   7,560,000  1.00  0.083  12.0  1.00  42.0
  4   16 16 16 16 28 28   3,600,000  3.14  0.214  14.7  3.14  20.0
```

**Validation:** with WIP 6, every initiative finishes in week 24 and nothing pays before then. With WIP 3, three pay from week 12
and delay cost falls by 25% with the same teams and work. With WIP 2, only 8 of 12 teams can be used
(each initiative absorbs at most 4), throughput falls and delay cost rises again. The `L=lW` column equals `L` in every row: Little's
law holds for time in progress.[^little] **Troubleshooting:** a run that never ends means an initiative with zero work or zero
capacity. **Lesson:** set the limit from the capacity available for change, here 12 teams ÷ 4 useful teams per initiative = 3;
after step 2 (6 per initiative) WIP 2 becomes the best of the limits shown. With a 30% run-the-business reserve, as in
`guardrails.yaml`, about 8 teams remain and the same rule gives 2. **Teardown:** delete the folder.

#### Lab 3 (advanced): a stop-or-continue review

**Objective:** apply uplifts from estimate history to every estimate, ignore sunk cost, count the cost of stopping, and compare each
in-flight initiative with the best queued option (the hurdle) adjusted the same way. **Prerequisites:** Labs 1–2; your own
actual-to-estimate history if you have it.

1. Save the script as `review.py` and the JSON as `inflight.json`; run `python3 review.py inflight.json`.
2. Set F1's `sunk` to 0 and run again: the decision must not change.
3. Set `uplift_cost` and `uplift_weeks` to 1.0 and run again: note how the hurdle moves with the in-flight figures.
4. Restore the uplifts; set F1's `stop_cost` to 1500000 (a supplier contract payable either way) and run again.
5. Restore F1; set `discount_rate_per_year` to 0.08 and run again.

_Example status: verified by execution (Python 3.8.10, 2026-10-23)._

```python
"""Stop-or-continue review for in-flight initiatives.

Usage: python3 review.py inflight.json
Every estimate, in flight or queued, gets the same treatment: cost and
weeks are uplifted by the portfolio's own history (actual / estimated),
and value is expected benefit from launch to the horizon, optionally
discounted (costs are not discounted: they are spent first). The hurdle
is the best queued option's value per unit of money after the same
uplift. Continuing commits the remaining cost minus what stopping costs
anyway (stop_cost) and adds value minus what stopping keeps (salvage).
Money already spent ("sunk") is printed but never used in the test.
"""
import json
import math
import sys


def appraise(item, cfg):
    cost = item["remaining_cost"] * cfg["uplift_cost"]
    weeks = item["remaining_weeks"] * cfg["uplift_weeks"]
    horizon = cfg["horizon_weeks"]
    if weeks >= horizon:
        return cost, 0.0
    rate = math.log(1 + cfg["discount_rate_per_year"]) / 52
    if rate:  # benefit weeks, discounted continuously to today
        live = (math.exp(-rate * weeks) - math.exp(-rate * horizon)) / rate
    else:
        live = horizon - weeks
    return cost, item["p_success"] * item["benefit_per_week"] * live


def main(path):
    with open(path) as f:
        cfg = json.load(f)
    hurdle, best = max((v / c, q["id"]) for q in cfg["queued"]
                       for c, v in [appraise(q, cfg)])
    print(f"{'id':<4}{'sunk':>10}{'remaining':>11}{'E[value]':>11}"
          f"{'net':>6}  decision")
    for i in cfg["inflight"]:
        cost, value = appraise(i, cfg)
        commit = cost - i.get("stop_cost", 0)
        gain = value - i.get("salvage", 0)
        net = gain / commit if commit > 0 else math.inf
        if net >= hurdle:
            decision = "continue"
        elif i.get("smaller_scope"):
            decision = "re-scope: test " + i["smaller_scope"]
        else:
            decision = "stop and release capacity"
        print(f"{i['id']:<4}{i['sunk']:>10,.0f}{cost:>11,.0f}"
              f"{value:>11,.0f}{net:>6.2f}  {decision}")
    print(f"hurdle: {hurdle:.2f} per unit of money ({best}, same uplift)")


if __name__ == "__main__":
    main(sys.argv[1])
```

```json
{
  "uplift_cost": 1.4,
  "uplift_weeks": 1.3,
  "horizon_weeks": 104,
  "discount_rate_per_year": 0.0,
  "queued": [
    {"id": "Q1", "remaining_cost": 1000000, "remaining_weeks": 16,
     "p_success": 0.7, "benefit_per_week": 30000},
    {"id": "Q2", "remaining_cost": 500000, "remaining_weeks": 8,
     "p_success": 0.6, "benefit_per_week": 12000}
  ],
  "inflight": [
    {"id": "F1", "sunk": 4200000, "remaining_cost": 1500000,
     "remaining_weeks": 30, "p_success": 0.5, "benefit_per_week": 60000,
     "stop_cost": 300000, "salvage": 200000,
     "smaller_scope": "the EU-only release"},
    {"id": "F2", "sunk": 300000, "remaining_cost": 600000,
     "remaining_weeks": 10, "p_success": 0.8, "benefit_per_week": 25000,
     "stop_cost": 50000, "salvage": 0},
    {"id": "F3", "sunk": 900000, "remaining_cost": 800000,
     "remaining_weeks": 40, "p_success": 0.6, "benefit_per_week": 15000,
     "stop_cost": 100000, "salvage": 50000}
  ]
}
```

**Expected output:**

```text
id        sunk  remaining   E[value]   net  decision
F1   4,200,000  2,100,000  1,950,000  0.97  re-scope: test the EU-only release
F2     300,000    840,000  1,820,000  2.30  continue
F3     900,000  1,120,000    468,000  0.41  stop and release capacity
hurdle: 1.25 per unit of money (Q1, same uplift)
```

**Validation:** `net` is (expected value − salvage) ÷ (uplifted remaining cost − stop cost): what continuing adds per unit of
money it really commits. Step 2 changes nothing: sunk spend never enters the test. Step 3 raises the hurdle to 1.85 and F1 to
1.68; nothing flips, but setting the uplifted 0.97 against an unadjusted 1.85 would overstate the case for stopping. In step 4 F1
reaches 2.92 and continues: when stopping costs most of what finishing would, finishing can be the better use of money. In step 5
values fall (hurdle 1.14, F1 0.86); nothing flips. **Troubleshooting:** a value of zero means remaining weeks exceed the horizon.
**Caveats:** the hurdle is per unit of money; it ranks like value per team-week only if cost tracks team time. If people,
not budget, are the constraint, divide by uplifted team-weeks (this Atlas's note). Apply any benefits haircut to both sides. The [judgement call](#a-judgement-call-finish-the-flagship-or-stop-it) uses F1. **Teardown:** delete the folder.

### Use cases and scenarios

**1. Cost of delay across a $100 million IT portfolio (sourced practitioner report).** At Maersk Line, Arnold and Yüce combined
quantified cost of delay and CD3 with other "Starter Pack" practices. One system's cycle time fell from an average of 208 to 108
days (104 in the paper's conclusion) and another's lead time from 168 to 60 days, results they attribute to the whole set of
changes. Value was highly skewed: the top quarter of one priority list was worth three orders of magnitude more than the bottom
quarter. The head of the business process owner team summed it up as "less yelling and screaming, data-driven, more
visible".[^maersk] The authors were the consultants who led the work: read it as an experience report, not an independent study.

**2. A government's major projects portfolio (sourced public data).** The UK Government Major Projects Portfolio had 189 projects
with a whole-life cost of £924.2 billion at the end of March 2026: 29 rated green, 109 amber, 34 red and 17 exempt. Owners report a
delivery confidence rating each quarter; where NISTA reviewed or supported a project in the past six months, its independent
rating is published instead. Of 42 projects that left during the year, 26 reported delivering their objectives and seven
were brought to early closure; in April 2026 the portfolio was refocused to about 80 projects. NISTA stresses that "A red rating
does not mean failure".[^nista] Lessons: independent ratings beside self-reported ones, a counted exit route that includes early
closure, and a portfolio kept small enough to support.

**3. From project to hybrid funding in a software company (illustrative).**

::: example Illustrative scenario
A 400-person software company funds 30 projects a year through annual business cases; 22 are "in progress" at once. It funds
its five product lines as value streams for a year, keeps a portfolio Kanban for cross-stream epics above six team-weeks with a WIP
limit of three, and releases a 10% exploratory reserve in quarterly tranches. Success after four quarters: median time from
approval to first release down by a third; at least one epic stopped or re-scoped; spend by theme inside the ranges.
:::

## Measure, govern, pay

### Metrics and KPIs

| KPI | Definition / formula | Data source | Pitfall | Cadence |
|---|---|---|---|---|
| Initiatives in progress | Count in "implementing" ÷ WIP limit | Kanban | Splitting one initiative into many to fit | Weekly |
| Time to first value | Median days from approval to first release customers use | Register, release log | A pilot nobody uses | Monthly |
| Decision latency | Median days from intake to triage decision | Register | "Parked" as a non-decision | Monthly |
| Allocation adherence | Actual capacity by theme ÷ target range | Time or cost data | Mislabelled work | Quarterly |
| Reallocation rate | Share of capacity moved between themes in a year | Allocation history | Churn without reasons | Annually |
| Stop rate | Initiatives stopped or re-scoped at reviews ÷ initiatives reviewed | Decision log | Zero is a warning, not a success | Quarterly |
| Estimate uplift | Actual cost (or duration) ÷ estimate at approval, for completed work | Register | Few data points; survivorship if stopped work is excluded | Annually |
| Benefits realisation ratio | Measured benefit ÷ promised benefit[^fowler] | Benefits record | Benefits nobody measures count as zero, not as unknown | 3 and 12 months after launch |

**Worked calculation (invented numbers).** Last year 14 initiatives completed. Their approved cost estimates summed to 9.0 million and
their actual costs to 12.6 million: cost uplift = 12.6 ÷ 9.0 = 1.4. Eleven had benefits measured at 12 months: promised 18.0 million a
year, measured 10.8 million: benefits realisation ratio = 10.8 ÷ 18.0 = 0.6. Of 40 initiative-reviews held, 3 ended in a stop and 2 in
a re-scope: stop rate = 5 ÷ 40 = 12.5%. So every case, new or in flight, should carry the 1.4 cost uplift and a benefit haircut;
the review works but is not yet bold. **Leading versus lagging:** WIP, decision latency and time to
first value move within a quarter; realisation and uplift lag by a year or more.

### Quality, risk and compliance

- **Data quality is the main risk.** Stale remaining estimates produce confident wrong decisions. Give each field an owner and a
  refresh date; audit a sample monthly.
- **Independent challenge.** Sponsors rate their own initiatives optimistically. The UK publishes NISTA's independent rating where
  it has recent evidence;[^nista] inside a company, finance or a peer reviewer can play that role.
- **Personal data.** Time tracking and allocation data are records about named employees; their lawful use, retention and access
  depend on the jurisdiction and works-council or union agreements. Report capacity at team level unless an individual view is
  needed and permitted. This is not legal advice.
- **Audit trail.** Keep the decision log, its inputs and who decided, as long as finance and audit policies require.

### Cost, capacity and sustainability

The portfolio function has its own cost: meetings, analysis, tools and owners' time. Keep the lean case to a page until the
cost of delay justifies more. Subtract run-the-business work (operations, fixes, compliance) before allocating change; a portfolio
that plans 100% of capacity for new initiatives will be late on all of them. Retiring old
systems frees capacity (SAFe's "Horizon 0" covers solutions moving towards decommissioning).[^safelpm]
Carbon rarely belongs in initiative ranking; where it matters, see [GreenOps](../greenops/).

### Assurance of the operating model

Check the system, not just the initiatives: (1) does every piece of significant work in teams have a register entry? (2) is the
active count within the WIP limit? (3) did each quarterly review produce at least one decision other than "continue"? (4) does
estimate uplift from completed work include stopped work? (5) is the benefits realisation ratio measured at all? An internal
audit can test these from the register and decision log.

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remedy | Prevention |
|---|---|---|---|---|
| Everything is "priority 1" | No explicit cost of delay; MoSCoW | Count items per priority class | Force a single ranked list with CoD | Rank, never classify |
| Nothing finishes | No WIP limit; approvals start work | Active count versus team count | Freeze starts until under the limit | Start only into a free slot |
| Review approves everything | Sunk-cost reasoning; no alternative shown | Stop rate over four quarters | Show the adjusted best queued option beside each item | Hurdle in the pre-read |
| Side-door work | Senior sponsors bypass intake | Work in teams with no register entry | Register it and rank it publicly | Board agrees "no entry, no capacity" |
| Scores inflate | Sponsors learn the model | Score drift per sponsor | Calibrate in a joint session; show assumptions | Finance challenge of benefits |
| Tool rollout, same chaos | Tool before process | Decisions logged per month | Run the cadence manually | Process first, tool later |

### Worked runbook: the portfolio that never says no

**Trigger:** two consecutive quarterly reviews in which every in-flight initiative continued, while time to first value grew.

1. **Stabilise (week 1).** Freeze new starts. Publish the active list with owners and age.
2. **Diagnose (weeks 1–2).** From the register, compute active count against capacity (Lab 2), median age, and each item's remaining
   cost with the historical uplift. Check whether pre-reads showed any alternative to continuing.
3. **Decide (week 3, extraordinary review).** For each item, compare remaining value net of stop costs with the best queued option
   after the same uplift (Lab 3). Expect to stop or re-scope some; record reasons.
4. **Recover (weeks 4–8).** Release freed teams to the top of the queue; set the WIP limit from capacity; add the hurdle to the
   pre-read template.
5. **Prevent.** Track stop rate and decision latency monthly; brief the board that a non-zero stop rate is the goal.

**Rollback:** if a stopped item turns out to carry a hard external deadline that the register missed, reinstate it with its deadline
recorded and fix intake so deadlines are a required field.

### Anti-patterns and myths

- **"Portfolio management means a bigger PMO."** It means fewer, faster decisions; reporting layers slow them.
- **"Precise scores make good decisions."** Scores without units hide the assumptions that matter; Maersk's teams adjusted the cost of
  delay behind a raw CD3 score, visibly and with reasons.[^maersk]
- **"Starting early is safe."** Without capacity it lengthens everything already running (Lab 2).
- **"Buy the SPM tool first."** Tools encode a process; without one, they encode the current confusion.

## Deciding and adopting

### When to use and when not to use

**Use it** when more initiatives compete for the same people or money than one leader can weigh, when work regularly waits for
approval or capacity, or when nobody can say what was stopped last year. **Do not build a function** when one leader owns all
change and a one-page ranked list suffices (this Atlas's rule of thumb: below roughly ten concurrent initiatives), or when the work
is one large programme ([ProjectOps](../projectops/)). **Hidden costs:** board time, owners' time on cases, and the politics of
visible stops.

### Decision framework

::: figure Do you need a portfolio operation, and which funding model?
```mermaid
flowchart TB
  Q1{"More initiatives than one leader can weigh?"}
  Q1 -->|No| N1["No function: one owner, one ranked list"]
  Q1 -->|Yes| Q2{"Mostly long-lived products or platforms?"}
  Q2 -->|Yes| Q3{"Can finance fund teams with guardrails?"}
  Q3 -->|Yes| V["Value-stream budgets plus epic Kanban"]
  Q3 -->|Not yet| H["Hybrid: fund teams, approve large epics"]
  Q2 -->|No| Q4{"Fixed scope set by contract or regulation?"}
  Q4 -->|Yes| PJ["Project portfolio with gates and stop criteria"]
  Q4 -->|No| H
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class Q1,Q2,Q3,Q4 decision
  class V,H,PJ core
  class N1 risk
```
Text equivalent: If one leader can weigh all initiatives, build no function: one owner keeps one ranked list. Otherwise, for
mostly long-lived products where finance can fund teams with guardrails, use value-stream budgets with an epic Kanban; if finance
cannot yet, a hybrid that funds teams and approves large epics. For mostly bounded change, use a project portfolio with gates and
stop criteria when scope is fixed by contract or regulation, and the hybrid otherwise.
:::

### Maturity model

**This Atlas's model**, not an official one; GAO's ITIM stages are the nearest published analogue for IT investment.[^gao]

| Level | Observable behaviour | Exit criterion |
|---|---|---|
| 1 Ad hoc | Nobody can list all running initiatives | A complete register exists |
| 2 Visible | Register and intake; status reporting | Every start is ranked against the queue |
| 3 Ranked | CoD on every case; WIP limit holds | A review has stopped or re-scoped work |
| 4 Adaptive | Stops and reallocations each quarter | Uplifts and realisation ratios measured for a year |
| 5 Learning | New cases carry measured uplifts; benefits checked | Sustained; revisit the model itself yearly |

### Adoption roadmap: 30/60/90 days

| Window | Actions | Milestone | Metric started |
|---|---|---|---|
| Days 1–30 | Build the register from teams' actual work; agree board membership; publish one front door | Complete list of active initiatives | Initiatives in progress |
| Days 31–60 | Introduce the intake form with CoD; weekly triage; set a WIP limit from capacity; freeze starts above it | First ranked queue | Decision latency |
| Days 61–90 | First quarterly review with a hurdle; agree theme ranges; schedule benefits checks | First recorded stop or re-scope | Stop rate; time to first value |


## Toolkit

### Checklists

**Quick start**
- [ ] One register with an owner for every field
- [ ] One front door, announced by the board
- [ ] A WIP limit derived from capacity

**Before each quarterly review**
- [ ] Remaining cost and weeks updated, with uplift applied
- [ ] Best queued option's value per unit of money, after the same uplift, in the pre-read
- [ ] Tolerance breaches listed

**Stop-or-continue (per initiative)**
- [ ] Sunk cost excluded from the comparison
- [ ] Stop costs and salvage counted
- [ ] Smaller scope considered
- [ ] Decision and reasons logged; teams told the same week

**Annual audit**
- [ ] Spend by theme within ranges
- [ ] Uplifts recomputed including stopped work
- [ ] Register export tested from the tool

### Templates

```text
PORTFOLIO DECISION RECORD
ID / initiative:            Date:            Forum:
Decision: continue | re-scope | stop | start | reallocate
Inputs used: remaining cost (uplifted) ...  remaining weeks ...
             expected value ...  hurdle (best queued option) ...
Reasons (3 lines max):
Dissent recorded:
Effect on capacity: teams released / added ...  from / to theme ...
Next checkpoint:            Decided by:
```

```text
ONE-PAGE PORTFOLIO CHARTER
Scope: which money and people this portfolio governs
Board: names, roles; quorum; who breaks ties
Themes and ranges: (from guardrails)
Front door: where requests go; the size threshold for portfolio decisions
Cadence: triage weekly; sync monthly; strategic review quarterly
WIP limit and how it is set
Stop rule: tolerance that triggers review; hurdle used
Measures: in progress, decision latency, time to first value,
          stop rate, uplift, benefits realisation
```

### Deep comparisons

| Organising choice | Strengths | Weaknesses | Choose when |
|---|---|---|---|
| Traditional PMO | Familiar controls, reporting | Gates and reports rather than decides | Project funding, regulated delivery |
| Value management office (SAFe)[^safelpm] | Built for value-stream funding and flow | Framework vocabulary; licensing | SAFe is already in use |
| Small office under the CFO or COO | Close to money; neutral | Far from delivery detail | Business units compete for one budget |
| No central function; board plus register | Cheap; fast | Depends on one chair's discipline | Small portfolios |

### FAQ

**Is PortfolioOps a real job title?** Rarely as one word. "Portfolio operations" titles exist in three different industries (see
[In 30 seconds](#in-30-seconds)); read the duties.

**Is WSJF wrong?** No, it is a fast relative method. Its additive numerator and size-for-duration proxy can mis-rank items; check the
top of the list with money and duration (Lab 1).

**Do we need SAFe to do Lean Portfolio Management?** No. Intake, cost of delay, WIP limits, guardrails and stop reviews work in any
framework; SAFe packages them with its own roles and events.

**How many initiatives should run at once?** Start from change capacity (after the run-the-business reserve) divided by the teams
one initiative can usefully absorb (Lab 2), then adjust by watching time in progress.

**What if leadership will not stop anything?** Show the best queued option beside each in-flight item. If nothing stops, the
portfolio is a reporting exercise; say so.

## Going further

### Advanced topics and emerging direction

- **Uncertainty in cost of delay.** Use ranges and simple simulation; the hard decisions are where two options' ranges overlap.
- **Information value.** A cheap experiment that resolves a big uncertainty can be worth more than a feature; Arnold and Yüce
  valued "information discovery" beside their four benefit types.[^maersk]
- **Portfolio-level flow data.** This Atlas suggests tracking how long initiatives age in each stage as an early warning; NISTA's
  red-rating tool (above) is a related use of portfolio data.[^nista]

### Learning path

| Stage | Do this |
|---|---|
| Prerequisites | [ProjectOps](../projectops/) for project control; [AgileOps](../agileops/) for team flow |
| 1 day | Read this page; run Lab 1 on your own top ten items |
| 1 week | Register one department's active initiatives; compare WIP with capacity (Lab 2) |
| 30 days | Run weekly triage and one stop-or-continue review with a hurdle (Lab 3) |
| Advanced | Read the PMI standard or ISO 21504; study the Maersk paper; compare with SAFe LPM |
| Portfolio project | An uplift and benefits-realisation analysis of your last 20 completed initiatives |

## Wrap-up

### Executive recap and cheat sheet

- **Decide:** what enters, in what order, how many at once, what stops.
- **Practices:** one front door; weekly triage; cost of delay; WIP limit from capacity; quarterly stop-or-continue with a hurdle.
- **Metrics:** initiatives in progress, decision latency, time to first value, stop rate, uplift, benefits realisation ratio.
- **Tools:** a register first; a suite when scale demands it; test exports.
- **Watch for:** side doors, sunk-cost reasoning, score inflation, tool-first rollouts.
- **Next action:** list every active initiative and its owner this month.

### A judgement call: finish the flagship or stop it?

::: example Illustrative scenario
Initiative F1 from Lab 3 has spent 4.2 million and the team says 1.5 million and 30 weeks remain. Benefits, if it works, are 60,000
a week; the owner rates the chance of success at 50%. Stopping would cost 300,000 and keep 200,000 of reusable work. The queue's
best option, Q1, promises about 1.85 per unit of money on its own estimates.
:::

**Option A: finish it.** It is the CEO's flagship, most of the money is spent, and stopping looks like failure. **Option B: stop
or re-scope it.** With historical uplifts applied to both, F1 returns 0.97 per unit of money committed against Q1's 1.25; with no
uplift on either, 1.68 against 1.85. F1 is below the hurdle both ways.

**How to decide.** The spent 4.2 million is the same under both options, so it favours neither. The test is remaining value
per money committed, net of stop costs, against the next best use of the same teams, estimated the same way. Before stopping, test
a cheaper scope: an EU-only release with 60% of the benefit for a third of the remaining cost and time would return about 3.6 by
the Lab 3 test (uplifted, net of stop cost and salvage; 2.3 before them).

**Assumptions and uncertainty.** The success probability is the owner's own rating; the hurdle rests on uncertain queue estimates;
uplifts come from a small history. Run pessimistic and optimistic cases: if F1 stays below the hurdle in both, stop; if they
straddle it, re-scope with a dated checkpoint.

**A defensible choice.** Re-scope with a hard checkpoint, and record the decision with reasons.

### Learning objectives and mastery check

You should now be able to **explain** the four uses of "portfolio operations"; **calculate** cost of delay, CD3 and delay cost;
**set** a WIP limit; **choose** a funding model; **run** a stop-or-continue review; and **measure** uplift and benefits realisation.

::: answer A colleague says "PortfolioOps is our private-equity value creation team". Are they wrong?
Not about the words: that is one established use of "portfolio operations". This page's meaning, steering investment in change
inside one organisation, is an editorial choice of this Atlas.
:::

::: answer Items A, B and C have cost of delay 1, 4 and 5 per week and take 5, 1 and 2 weeks. What order minimises delay cost?
B, C, A by CD3 (4, 2.5, 0.2): delay cost 27 against 69 for A, B, C (Lab 1, from the Maersk paper).
:::

::: answer Twelve teams are free for change work; each initiative can use at most four. What WIP limit do you start with, and why?
Three. More than three spreads teams thinly and delays every benefit; fewer leaves teams idle (Lab 2).
:::

::: answer A sponsor argues to continue because 80% of the budget is spent. What do you ask?
Uplifted remaining cost and time, expected value, stop costs, and how that compares with the best queued option estimated
the same way. The 80% spent stays spent either way.
:::

::: answer Your SAFe WSJF ranks a compliance chore above a large revenue initiative. What do you check?
Whether additive time-criticality and risk scores inflate a low-value item, and whether size is a fair proxy for duration. Put
money and weeks on both and compare by CD3; a real deadline enters as a start date, not a permanently high score.
:::

::: answer Your benefits realisation ratio is 0.6 and cost uplift 1.4. What changes in next year's cases?
Apply the 1.4 cost uplift and a benefit haircut to every case compared, new or in flight, until results improve; show
adjusted and unadjusted figures so the board sees the correction.
:::

### Conclusion

"PortfolioOps" is a label without an owner; the work behind it is old and well documented. What turns portfolio management into an
operation is not a framework or a suite but a few habits kept every week and every quarter: one front door, an explicit price on
waiting, a limit on what runs at once, and the nerve to stop work that no longer earns its place. Judge it by the decisions it makes
and by how quickly value reaches customers, not by the size of its reports.

## Sources and further reading

All sources were opened on 2026-10-23; notes on access are in the evidence ledger.

[^pmi4]: [The Standard for Portfolio Management – Fourth Edition](https://web.archive.org/web/20240712173102/https://www.pmi.org/pmbok-guide-standards/foundational/standard-for-portfolio-management) — Project Management Institute, 2017 (Internet Archive capture of 2024-07-12; the live page refused automated access). Checked 2026-10-23.
[^pmi5]: [Standards: about, development and current projects](https://web.archive.org/web/20260830114233/https://www.pmi.org/standards/about) — PMI (Internet Archive capture of 2026-08-30), section on the fifth edition's ANSI BSR-8 comment period. Checked 2026-10-23.
[^iso21504]: [ISO 21504:2022 Project, programme and portfolio management — Guidance on portfolio management](https://committee.iso.org/sites/tc258/home/projects/published/iso-21504.html) — ISO/TC 258 committee site. Checked 2026-10-23.
[^mop]: [MoP Foundation – PRINCE2 Portfolio Management Foundation](https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/mop-4/mop-foundation-2644) — PeopleCert. Checked 2026-10-23.
[^govs002]: [Government Functional Standard GovS 002: Project Delivery](https://www.gov.uk/government/publications/project-delivery-functional-standard) — Cabinet Office and Government Project Delivery, GOV.UK, updated 2025-09-17 (version 2.1). Checked 2026-10-23.
[^gao]: [Information Technology Investment Management: A Framework for Assessing and Improving Process Maturity (GAO-04-394G)](https://www.gao.gov/products/gao-04-394g) — US Government Accountability Office, version 1.1, 2004-03-01; supersedes the May 2000 exposure draft AIMD-10.1.23 (product page and PDF). Checked 2026-10-23.
[^safelpm]: [Lean Portfolio Management (discipline)](https://framework.scaledagile.com/lean-portfolio-management-discipline) — Scaled Agile, Inc., last update 2025-03-31. Checked 2026-10-23.
[^safewsjf]: [Weighted Shortest Job First](https://framework.scaledagile.com/wsjf) — Scaled Agile knowledge base (definition public; full article behind a login). Checked 2026-10-23.
[^safewsjf2016]: [WSJF – Scaled Agile Framework](https://webarchive.library.unt.edu/web/20161225132214/http://www.scaledagileframework.com/wsjf) — Scaled Agile, archived 2016-12-25 by the UNT Libraries web archive. Checked 2026-10-23.
[^bsfcod]: [Cost of Delay](https://blackswanfarming.com/cost-of-delay/) — Joshua Arnold, Black Swan Farming (consultancy). Checked 2026-10-23.
[^bsfqual]: [Qualitative Cost of Delay](https://blackswanfarming.com/qualitative-cost-delay/) — Black Swan Farming. Checked 2026-10-23.
[^bsfurg]: [Urgency Profiles](https://blackswanfarming.com/urgency-profiles/) — Black Swan Farming. Checked 2026-10-23.
[^bsfprio]: [Prioritisation](https://blackswanfarming.com/prioritisation/) — Black Swan Farming. Checked 2026-10-23.
[^maersk]: [Black Swan Farming using Cost of Delay](https://blackswanfarming.com/black-swan-farming-using-cost-of-delay/) — Joshua J. Arnold and Özlem Yüce, 2013 IEEE-format paper (Agile 2013), reformatted for the web by the authors. Checked 2026-10-23.
[^fowler]: [Products Over Projects](https://martinfowler.com/articles/products-over-projects.html) — Sriram Narayan, martinfowler.com, 2018-02-20. Checked 2026-10-23.
[^mck]: [How to put your money where your strategy is](https://karriere.mckinsey.de/capabilities/strategy-and-corporate-finance/our-insights/how-to-put-your-money-where-your-strategy-is) — Stephen Hall, Dan Lovallo and Reinier Musters, McKinsey Quarterly, 2012-03-01 (McKinsey careers-site mirror, read as an extract; mckinsey.com timed out). Checked 2026-10-23.
[^greenbook]: [Supplementary Green Book Guidance: Optimism Bias (PDF)](https://assets.publishing.service.gov.uk/media/5a74dae740f0b65f61322c72/Optimism_bias.pdf) — HM Treasury supplementary guidance prepared from Mott MacDonald's 2002 *Review of Large Public Procurement in the UK*; placed on GOV.UK 2013-04-21. Checked 2026-10-23.
[^greenbook2026]: [The Green Book (2026)](https://www.gov.uk/government/publications/the-green-book--2/the-green-book-2026) — HM Treasury and Government Finance Function, GOV.UK, updated 2026-02-05 (sections on optimism bias and discounting). Checked 2026-10-23.
[^flyv]: [What You Should Know About Megaprojects and Why: An Overview](https://arxiv.org/abs/1409.0003) — Bent Flyvbjerg, arXiv, 2014. Checked 2026-10-23.
[^eos]: [Elements of Scheduling](https://arxiv.org/abs/2001.06005), chapter 4 — edited by Jan Karel Lenstra and David B. Shmoys, arXiv, 2020. Checked 2026-10-23.
[^mcfarlan]: [Portfolio Approach to Information Systems](https://hbr.org/1981/09/portfolio-approach-to-information-systems) — F. Warren McFarlan, *Harvard Business Review*, September 1981 (abstract page; full text paywalled). Checked 2026-10-23.
[^little]: [Little's Law as Viewed on Its 50th Anniversary (PDF)](https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/OS/Littles-Law-50-Years-Later.pdf) — John D. C. Little, Operations Research 59(3):536–549, 2011 (course-hosted copy). Checked 2026-10-23.
[^markowitz]: [Harry M. Markowitz – Facts](https://www.nobelprize.org/prizes/economic-sciences/1990/markowitz/facts/) — Nobel Prize Outreach. Checked 2026-10-23.
[^nista]: [NISTA Major Projects Annual Report 2025-26](https://www.gov.uk/government/publications/nista-major-projects-annual-report-2025-26/nista-major-projects-annual-report-2025-26) — National Infrastructure and Service Transformation Authority, GOV.UK, 2026-07-13. Checked 2026-10-23.
[^pewire]: [Resurgens adds six to portfolio operations team](https://www.privateequitywire.co.uk/resurgens-adds-six-portfolio-operations-team/) — Private Equity Wire, 2021-02-17. Checked 2026-10-23.
[^vident]: [Senior Portfolio Operations Analyst](https://vident.hiringthing.com/job/1045970/senior-portfolio-operations-analyst) — Vident Asset Management, job posting (undated; open when checked). Checked 2026-10-23.
[^sfjob]: [Strategic Portfolio Operations Manager - Lead](https://www.purpose.jobs/discover/companies/salesforce-2/jobs/82357822-strategic-portfolio-operations-manager-lead) — Salesforce posting on the Purpose job board, posted 2026-06-11 (closed). Checked 2026-10-23.
[^ghpo]: [portfolio-ops](https://github.com/mahmood726-cyber/portfolio-ops) — personal GitHub repository. Checked 2026-10-23.
[^planview]: [What is Strategic Portfolio Management?](https://www.planview.com/resources/articles/what-is-strategic-portfolio-management/) — Planview (vendor), modified 2026-04-13. Checked 2026-10-23.
[^valueops]: [ValueOps by Broadcom](https://valueops.broadcom.com/) — Broadcom (vendor). Checked 2026-10-23.
[^atlfocus]: [Atlassian Focus](https://www.atlassian.com/software/focus) — Atlassian (vendor). Checked 2026-10-23.
[^atlalign]: [Atlassian Align](https://www.atlassian.com/software/jira-align) — Atlassian (vendor). Checked 2026-10-23.
[^msproj]: [Prepare for Project Online retirement](https://learn.microsoft.com/en-us/planner/prepare-for-project-online-retirement) — Microsoft Learn, 2026-08-21. Checked 2026-10-23.
[^msmc]: [MC1478955 – Final reminder: Microsoft Project Online retires on September 30, 2026](https://mc.merill.net/message/MC1478955) — Microsoft 365 Message Center post of 2026-09-24, via the merill.net archive. Checked 2026-10-23.

**Further reading** (not opened for this page): Donald G. Reinertsen, *The Principles of Product Development Flow* (2009); Mik
Kersten, *Project to Product* (2018).

**Changelog.** 2026-10-23, r0: first draft (research, ledger, three labs executed, six diagrams); not yet independently reviewed.
2026-10-23, r1: after independent review r1: intake arithmetic fixed; Lab 3 adjusts the hurdle like in-flight work and counts
stop costs, salvage and discounting; financial appraisal, CD3 conditions and dependencies added; source fixes; figures revised.
2026-10-23, post-score polish: equity-model scope and WSJF attribution sharpened; re-scope figure's basis stated; Lab 3
money-versus-people caveat; sunk-cost repetition trimmed.
