Running a Portfolio of Projects Without Losing the Plot

Managing one project is a skill. Managing eleven at once is a different job with a misleading name — and most organizations do it with the wrong tools: a spreadsheet nobody trusts, a monthly meeting where every project is "mostly on track," and a resourcing model that assumes people can be split into eighths. The result is predictable: too many projects, all slightly starved, none finishing, while the org's real priorities get decided by whoever escalates loudest.

Portfolio management done properly is not more paperwork on top of project management. It is four specific mechanisms: a single trustworthy inventory, an honest health view, an explicit answer to resource contention, and the discipline to kill projects on purpose. This guide builds each one, with the formats and numbers that make them work at the 5-to-30-project scale where most teams actually live.

First, admit what a portfolio is

A portfolio is a set of bets drawing on a shared pool of people and money. That definition carries three consequences teams resist:

• Projects compete. Approving a new project is never a standalone decision; it is a decision to slow everything that shares people with it. An org that only ever says yes doesn't have a portfolio — it has a queue with no exit.
• The portfolio has a throughput. If your organization historically finishes eight meaningful projects a year, running twenty concurrently doesn't produce twenty outcomes. It produces eight late outcomes and twelve zombies. Work-in-progress limits apply to projects exactly as they apply to tasks, for exactly the same queueing reasons.
• Someone owns the whole. Portfolio decisions — start, stop, reprioritize, reassign — need a decider or a small committee with teeth. If nobody can stop a project, nobody is managing the portfolio; they're just watching it.

If you take one sentence from this article: most portfolio problems are too-many-projects problems wearing other costumes. Slow delivery, burned-out leads, constant context switching, "we never finish anything" — the fix is rarely better tracking of twenty projects. It's running twelve.

Build the inventory: one list, no exceptions

You cannot manage what you can't enumerate. The first mechanism is a single portfolio inventory — one table, one owner, updated on a stated cadence. Getting to a complete list is harder than it sounds, because portfolios accrete invisible projects: the "small" website refresh marketing started, the compliance work eating a third of an engineer, the CEO's pet integration. Run the collection pass by asking every team lead one question: "What is your team spending more than 10% of its time on?" Everything that comes back goes in the list, dignified with a row whether or not anyone ever approved it.

The inventory's columns — resist adding more until these are reliably maintained:

Column	What it holds	Why it earns its place
Project	Name + one-line outcome	If the outcome can't fit one line, that's a finding
Sponsor	The person whose problem this solves	Rows with no findable sponsor are kill candidates
Lead	Who runs it day to day	One name, not a team
Stage	Proposed / Active / Paused / Done / Killed	"Paused" is a real state; undead is not
People	Names and rough allocation (e.g., "Maya 50%, Jon 100%")	This column powers every contention conversation
Health	Green / Yellow / Red, set by the lead	With definitions — see below
Next milestone + date	The nearest verifiable commitment	The single best one-glance health signal
Kill criteria	The pre-agreed conditions for stopping	Written at start, when nobody is defensive

Twenty minutes of maintenance per project per week, mostly by leads updating their own rows. In tooling terms this is a table with grouped rows and people/status/date columns — teams on Openbook typically run it as a Table Board room in a leadership space (status, people, and date column types are built in), with each project linking out to its own working space. Any tool works; the invariants are one list, named owners, and edit access for the leads so the inventory is maintained by the people who know, not by a PMO chasing them.

Health that means something

Portfolio health reporting fails in one famous way: everything is green until it's suddenly red, a pattern usually called watermelon reporting (green outside, red inside). The cause is rarely dishonesty — it's that "green" was never defined, so leads default to optimism, and that yellow gets punished, so nobody volunteers it.

Fix the definitions first. Health is a claim about the commitment, not the team's effort:

• Green — current forecast hits the next milestone and the end commitment without consuming more than the remaining buffer.
• Yellow — the forecast misses a commitment unless something changes; the lead has a specific recovery plan and a date by which we'll know it worked.
• Red — the commitment will be missed or the plan is no longer viable; a decision above the project level is needed (scope, date, people, or kill).

Two operating rules make the definitions stick. First, yellow is rewarded: the correct leadership response to a first yellow is "thank you — what do you need?", visibly, in front of other leads. Punish one honest yellow and your portfolio goes watermelon within two cycles. Second, red means a decision, not a mood. A red project that sits red for three weeks without a portfolio-level decision isn't being managed; it's being witnessed. Every red gets a decision date within one review cycle.

Track one more signal the RAG column can't show: trajectory. A project that's been yellow for five weeks running is materially different from one that went yellow on Tuesday. Keep the history — the pattern of health-over-time surfaces chronic starvation and slow leaks that any single week hides. This is the portfolio-level version of the standing-questions status habit; the project-level mechanics are covered in project status reports people actually read, and portfolio health should be derived from those reports, never collected as a separate parallel truth.

Resource contention: the actual hard problem

Every portfolio conversation is secretly a people conversation. Three mechanisms handle it.

1. Make allocation visible and sum it

Take the People column and pivot it: for each person, sum their claimed allocations. The first time an org does this honestly, the table is comic. Maya is allocated 50% + 40% + 30% + "just advising" on a fourth project. Platform engineers sum to 180%. The org chart says you have 40 delivery people; the allocation table says you have 40 people doing 67 projects' worth of fractional attention.

Two numbers matter. Nobody over 100% is the obvious rule. The less obvious and more valuable one: minimize the people on more than two projects. Context switching between projects costs heavily — studies of task switching consistently find that fragmented attention loses a meaningful fraction of productive time to reorientation, and practitioner rules of thumb put the loss around 15–20% per additional concurrent project. A person at 3 × 33% delivers far less than three-thirds of a person. Where fractions are unavoidable (design, data, legal — the classic shared-specialist bottlenecks), prefer time-boxed fractions ("Maya is Project A's for the first three weeks of the quarter, then B's") over standing percentages, which dissolve into whoever-shouts-loudest scheduling.

2. Resolve contention at the portfolio, not in DMs

When two projects need the same person, the leads cannot resolve it — they're both right, locally. Contention gets resolved by one mechanism: the portfolio ranking. Which means the portfolio must have a ranking — an ordered list, 1 to n, no ties, owned by the portfolio decider. Not tiers ("high priority" containing nine projects is not a ranking), an order. Then the rule is mechanical and blessedly boring: when people are contended, the higher-ranked project wins, and the lower-ranked project's dates move and get announced as moved. The alternative — splitting the person — silently damages both projects and announces nothing.

3. Hold a project WIP limit

Set an explicit maximum of active projects, derived from the allocation table rather than ambition: count your real delivery capacity, subtract the standing taxes (run-the-business work, support, maintenance — typically 30–50% before any project starts), and divide by honest project sizes. Most orgs land on a number about half their current active count, which is the finding. New projects then enter only when a slot opens — meaning something finished or was killed — or when the decider explicitly trades: "X enters, Y pauses, here's the announcement." The sequencing logic and dependency mapping that make those trades safe are the same ones used inside a single project, applied one level up.

Kill criteria: deciding endings in advance

Organizations are good at starting projects and terrible at stopping them, for structural reasons: sunk cost feels like investment, the sponsor's reputation is attached, and there is never a natural moment when stopping is anyone's job. The fix is to make endings a pre-agreed condition rather than a fresh argument.

At approval time — while everyone is still rational because nothing is sunk — every project writes two or three kill criteria into its inventory row. Good ones are observable and dated:

• "If the pilot doesn't reach 20 active customers by end of Q1, we stop."
• "If the vendor's API certification isn't granted by March, we stop — the manual path doesn't scale."
• "If projected cost exceeds $150k or the sponsoring deal falls through, we stop."

Then, at each portfolio review, checking kill criteria is an agenda item, mechanical as a smoke alarm test. When a criterion trips, the default is stopping; continuing requires the decider's explicit, written override. This inversion is the entire trick — it moves the burden of proof from "someone must argue to kill it" (socially expensive, so nobody does) to "someone must argue to save it."

Handle the ending itself well, because how you kill projects determines whether anyone ever gives you honest data again:

• Killed is not failed. A project stopped because its premise didn't survive contact with evidence is a cheap lesson; celebrate the cheapness explicitly. The team that killed a doomed project in eight weeks saved you the version where it died at month nine.
• Harvest before burial. A one-page closeout: what we learned, what's reusable, what the kill criteria caught. Filed where the next proposal will find it.
• Redeploy loudly. The freed people move to ranked work within days, and the move is announced as the point: "Killing X is what funded accelerating Y."

Watch for the compromise failure mode: the zombie pause. Pausing a project is legitimate exactly when it has a named re-entry condition and date ("paused until the Q2 platform work lands"). A pause with neither is a kill that lacked the courage of its convictions, and it still costs you — paused projects hold mindshare, block decisions, and haunt planning. Audit the Paused column quarterly; anything without a live re-entry condition gets promoted to killed.

Exec reporting: one page, four sections

Portfolio reporting to executives fails in two symmetrical ways: the 40-slide deck nobody reads, and the sunny one-liner nobody can act on. The format that works is one page, four sections, monthly:

1. The portfolio at a glance. The ranked list with health, trajectory arrows (↑↓→ vs. last month), and next milestone per project. Ten seconds of scanning should answer "where is the risk concentrated?"
2. Changes. Started, finished, killed, paused, re-ranked — with one-line reasons. This section is where portfolio management becomes visible as decisions rather than surveillance.
3. Decisions needed. Two or three items maximum, each framed as a real choice with a recommendation: "Design is contended between P2 and P5; recommend P5 slips three weeks — approve?" Execs engage with decisions and glaze at status. If this section is empty three months running, you're reporting, not managing.
4. Honesty ledger. Buffer consumption on the top-ranked projects, any kill criteria approaching their trip point, and one metric almost nobody reports: cycle time from project start to finish, trending. If your average project takes eleven months and your active count is climbing, the ledger will say what no individual green status will.

Keep the supporting detail pull, not push: the one-pager links to the live inventory and each project's status room, so an exec who wants depth can get it without anyone building a deck. And date-stamp everything — an undated portfolio report is indistinguishable from last month's, and executives notice.

The operating cadence

The mechanisms above run on three loops:

• Weekly (30 min, leads async): every lead updates their row — health, forecast, next milestone, contention flags. No meeting; the inventory is the meeting. Escalations flagged here don't wait for the monthly.
• Monthly (60–90 min, portfolio review, the decider chairs): walk reds and yellows only — greens get skipped on principle, which is the reward for being green. Check tripped kill criteria. Resolve flagged contention against the ranking. Approve entries from the intake queue only into open slots. Produce the one-pager as the output, not as prep.
• Quarterly (half day): re-rank the whole portfolio against strategy, audit the Paused column, review the allocation table for over-splitting, and review cycle-time trend. This is also when the WIP limit itself gets revisited — did we actually finish more by running fewer? (Almost always yes, and the quarterly is where that evidence accumulates into culture.)

Note what's absent: a weekly all-leads status meeting. If the inventory is maintained and the health definitions are real, the weekly meeting is redundant with the table — and killing it is a good early demonstration that the portfolio system pays rent.

Balance: the view the ranking can't give you

A ranked list optimizes each slot but can't see the shape of the whole. Once a quarter, tag every active project along two axes and look at the distribution.

Purpose mix. A workable three-way split: run (keep-the-lights-on: compliance, upgrades, debt), grow (extend what already works: features for existing customers, expansion of proven channels), and transform (new bets whose premise is unproven). There is no universal correct ratio, but there are diagnostic extremes. A portfolio that is 80% run is an org managing decline in an orderly fashion; 60% transform is a casino with standups. Most steady-state teams land somewhere near half grow, a quarter to a third run, and a deliberate minority of transform — the useful act isn't hitting a target ratio, it's seeing your actual one and asking whether anyone chose it.

Bet size and horizon. Plot projects by people-months committed against months-to-first-evidence. The dangerous quadrant is big-and-slow: large commitments whose first real signal arrives in month eight. One of those may be a strategy; four of them is a portfolio that can't learn. When the quadrant is crowded, the fix is usually not killing the bets but restructuring them — pulling an evidence milestone forward (a pilot, a spike, a paper-launch) so the kill criteria have something to read before the money is spent. This is the portfolio-level payoff of front-loading risk in each project's milestone plan: a portfolio of projects that each surface their scariest evidence early is a portfolio that can rebalance quarterly instead of annually.

Ten minutes with two pie charts in the quarterly review covers this. The output is occasionally a re-rank, more often a restructured bet, and always a better answer to the exec question "are we working on the right kinds of things?" — which the ranked list alone was never built to answer.

Anti-patterns: a field guide

• The shadow portfolio. The official list has twelve projects; the allocation table reveals nineteen. The unlisted seven aren't small — they're just unaccountable. Countermeasure: the 10%-of-anyone's-time rule for inventory inclusion, re-run quarterly.
• Peanut-butter resourcing. Spreading people thinly across everything so that no sponsor is upset and no project is fast. The ranking exists precisely to concentrate force; a portfolio where every project got a little is a portfolio where ranking decisions were dodged.
• The permanent yellow. Chronic yellow with a rotating recovery plan is red with better manners. Two consecutive misses of "the date we'll know recovery worked" auto-promotes to red.
• Intake by ambush. Projects entering via executive hallway conversation, pre-staffed before the portfolio sees them. Countermeasure is social, not procedural: the decider's consistent line — "great idea, it goes in the intake queue with the others, and here's what it would displace."
• Reporting theater. A beautiful monthly deck about a portfolio nobody is allowed to change. If starts, stops, and re-ranks aren't happening, the reporting is a costume. Decisions are the product; reports are exhaust.

Where to start, in order

1. Build the inventory this week. Ask every lead the 10% question, dignify everything with a row, and publish the list. Half the value of portfolio management arrives with the mere existence of a complete list.
2. Pivot the People column into the per-person allocation table and circulate it. Let the 180% rows make the argument for you.
3. Define G/Y/R in writing, announce that yellow earns thanks, and start keeping health history.
4. Force-rank the list — one order, one owner. Resolve your current worst contention with it, and announce the resolution including the loser's new dates.
5. Next quarter: set the project WIP limit, write kill criteria into every active row (retrofitting them is awkward and worth it), and switch exec reporting to the one-pager.

New projects deserve the same rigor at birth — the intake step is a natural place to require the sponsor conversation, success criteria, and non-goals from the project kickoff checklist before a proposal can claim a slot.

If your portfolio currently lives in a spreadsheet three clicks from where the work happens, Openbook closes the gap: a Table Board for the inventory, a space per project underneath it, status rooms feeding health upward, and dashboards for the exec view — one address for the whole plot. Start free and put the list where the work lives.