PortfolioOps

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,^[1] ISO publishes guidance on project and programme portfolio management,^[2] 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”.^[3]

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.

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.^[8]
• 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.^[9] 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.”^[10] The 2026 Green Book still requires explicit adjustments for it.^[11] 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”.^[12]

• Not financial portfolio management. ISO 21504 states that it does not cover “other specific types of portfolio management (such as financial portfolio management)”.^[2] 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).
• 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.
• Not the company cadence. Annual planning, company OKRs and business reviews belong to BizOps; PortfolioOps scores and chooses between investments inside that cadence (an editorial split agreed between the two pages).

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.^[13] Applying the idea to organisational change grew through public-sector IT control, professional standards and Lean product development:

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

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.^[23] At a fixed delivery rate, more initiatives in flight means each one takes longer.

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

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”.^[24]
2. Limit work in progress. SAFe’s portfolio Kanban visualises and limits initiatives in progress;^[3] Little’s law says why it shortens time to value.^[23]
3. Make urgency explicit. Estimate cost of delay, even roughly; a ranking without it optimises for something else, typically cost and dates.^[21]
4. Ignore sunk cost. Decide on remaining cost and remaining value. GAO’s mature stages plan the “de-selection” of low-value investments.^[15]
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,^[11] based on data from past or similar projects.^[10]
6. Fund durable work durably. Long-lived products get team funding; genuine bets get staged funding (Narayan: “A team gets funded”).^[16]
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.

• 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”.^[3]
• 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”.^[3] The Salesforce advert listed tooling, data quality, dashboards, time-tracking compliance and resource data.^[6]
• 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.

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

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 --> [*]

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

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

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.

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

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.

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^[25]): 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).

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

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.^[8] The playbook for a new portfolio is to do the same before buying any tool.

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.^[27] 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^[10]); strategic misrepresentation by sponsors competing for funds (Flyvbjerg’s “survival of the unfittest”^[12]); the highest-paid person’s opinion (“HiPPO”^[24]); 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.

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.^[11] 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.^[21] 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.^[28] 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.^[28] 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.^[13] 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.

SAFe’s LPM replaces “project-based funding” with budgets allocated to value streams and governed by guardrails.^[3] Narayan lists a “halfway approach of project-mode funding and product-mode organization” among several “less-than-ideal variations”.^[16] 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.

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

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

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.^[34] Vendors advertise AI that drafts plans and surfaces risks;^[32] 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.

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).

# 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

# 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.

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.

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).

"""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])

[
  {"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}
]

[
  {"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:

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.^[8] 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.

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).

"""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:

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.^[23] 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.

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).

"""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])

{
  "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:

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 uses F1. Teardown: delete the folder.

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”.^[8] 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”.^[34] 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).

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.

• 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;^[34] 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.

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).^[3] Carbon rarely belongs in initiative ranking; where it matters, see GreenOps.

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.

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.

• “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.^[8]
• “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.

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). Hidden costs: board time, owners’ time on cases, and the politics of visible stops.

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

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

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

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:

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

Is PortfolioOps a real job title? Rarely as one word. “Portfolio operations” titles exist in three different industries (see 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.

• 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.^[8]
• 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.^[34]

• 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.

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.

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.

“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.

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

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.