Once in Red, Always in Red: Why Every Project Reports Green Until the Whole Portfolio Turns Red

The video tells the story in a minute. Below: what a project report cannot see, what the public record shows, what we do about it in Epicflow, and what it means for next year’s plan.

In short: In multi-project management, where a portfolio shares its people, the report can stay green for months and then turn red almost at once. The mechanism is the rescue. When a project falls behind, it borrows a person from another project, from a place where that project believes it can spare one: not its critical path, but one of the side paths that feed into it. Critical chain calls such a side path a feeding chain and gives it a small buffer of its own, the feeding buffer. The rescued project is back in the green, and the project that lent the person still looks green, because only its feeding buffer is used. Over months these loans drain the feeding buffers out of sight, until in many projects several side paths have become critical in the same weeks, and all of them need the same people. That is what I mean by “once in red, always in red”: a project that falls behind in a shared pool rarely catches up, because the help it needs is the same help every other red project needs.

The whole story, with the figures and the research behind it, is on Flow Economics, where we publish the thinking behind our articles without the software: The Borrowed Buffer: Why a Whole Portfolio Turns Red at Once.

What a project report cannot see

Whatever form it takes, a project report measures time. In critical chain it is the fever chart, a graph of how much of the project’s time buffer has been used. Everywhere else it is the monthly status report, with a green, amber or red next to each project. Both answer one question, project by project: do the dates still hold? Both also rest on one assumption: yes, as long as I get the people I was promised. With that assumption the report hands the responsibility for the dates to someone else; who takes it is a question the report does not ask. When the people do not come, the report says so as a complaint: the project did not get the engineers it was promised.

The promise itself sits in the resource plan. In most portfolio systems, resource management means allocation: a project manager books a share of a person for a period, and the plan is the sum of those bookings. Each booking was right on the day it was made. However, when a task slips, the person is still on it when the next project’s booking starts, and the booking does not move with the work unless someone moves it by hand. As a result, the resource plan reads fully allocated and green, while the waiting project reports amber for lack of people. Both are right, and neither looks ahead. When the green hides a red, Flow Economics calls it a watermelon report.

The public record is full of them. Three cases, each with the official account linked:

• Ajax, the British Army’s £5.5 billion armored vehicle program. In March 2019 the government’s project authority rated it amber and called the need for more people “critical”; no significant extra people followed. By September the program director gave the delivery date a 10 percent chance, while the report to the top said “challenging” but “achievable”. The rating went red in April 2021, two years after the warning (the official review).
• HealthCare.gov went live on October 1, 2013 and failed in public. Congress had been told in September that it was on track; the inspector general later found that the agency “continued on a failing path despite signs of trouble” (HHS Office of Inspector General).
• The US Navy’s shipbuilding programs. In April 2024 one review showed several of them late at once: the Columbia submarine, the Navy’s top priority since 2013, by 12 to 16 months; the Constellation frigate by 36 months, where the budget book of a month earlier still said 15. The Navy’s summary names the workforce and the supply chain; the Congressional Research Service calls the workforce the central factor: too few production workers, new hires who produce less, and too few ship designers (Congressional Research Service).

None of this is rare. Of the 189 projects in the UK government’s own major projects portfolio, 29 are rated green. Recovering amber and red programs has become a conference topic of its own; in October 2026 I was asked onto a panel at Defence PPM London 2026 under exactly that title.

The pattern is the one from the video: the warning was not in the dates but in the people. On Ajax the warning was on paper two years before the status changed: a program office too small for the work, a director who also ran a second program, staff borrowed from elsewhere, and a review that put it in writing. In the Navy’s review one factor runs through every program: the workforce. The reports measured time, as they were designed to do; capacity, the other dimension, was never on the chart. The conclusion is that in an organization that runs many projects on the same teams, what is critical is the load on each resource group, a team or a skill, across all projects, over time. The most loaded group is the bottleneck. It shifts as the mix of projects changes, although slowly: with a fairly stable portfolio, a 51st project added to 50 hardly changes the picture. The overload shows in that load long before any report changes color. No report that looks at one project at a time can see it.

Two sides of the same coin

The borrowed person and the bottleneck are one thing seen from two sides. Seen from inside a project, a rescue is a person borrowed from a side path of another project, and the report stays green. Seen from the shared team, that person was already committed elsewhere: the queue of projects waiting for that team sets the pace of every project in it. The National Audit Office says the same about the reset of a troubled program, in its own words: a reset “may require additional capacity or specific skills to be transferred from elsewhere with knock-on effects”. Managing projects one by one therefore spends the feeding buffers to keep the reports green. Managing the bottleneck starts at the other end, with four moves: find the team everything waits for, put a price on each week in its queue, test the fix before anyone moves, and give every team one order of work. The first side explains why a portfolio turns red; the second is what you do before it does.

What we do in Epicflow

The idea for Epicflow originated from practice. As a critical chain consultant I kept running into this pattern, and two things were missing. The first was one priority for every person across all projects: which task next. Critical chain had that right, and critical chain tools do it well. The second was the capacity needed over time for every resource group, not only for the drum, the one group that critical chain assumes sets the pace of the whole organization. No tool gave me that without scheduling every task over time, which Goldratt, the father of critical chain, called a waste of time given the uncertainty, and he was right. So, in 2008 I started to build one, with four members of the Goldratt implementation group. That tool is now Epicflow.

Epicflow does not sum bookings. Instead, it spreads the remaining work of every project over its forecast duration, uncertainty included, and sets that load against the capacity of each resource group, months ahead (capacity planning). When a task slips, the load moves with it, so the queue at a shared team shows before any booking is broken. Where the load exceeds the capacity, that group is the bottleneck, and every project that needs it is at risk, whatever its own report says. A program office carrying twice the work its hours allow shows up as a red bar in the load two years before the status report changes, with the projects behind it named.

We do not level the schedule (shift the tasks until no team is overloaded) and hand it to the teams, because a leveled plan looks different tomorrow: one late task moves everything behind it. Leveling serves one purpose here, to test whether the dates are feasible. Execution runs on priorities, which are stable and can be explained on the work floor. A schedule is a forecast; a priority is an instruction. Most tools confuse the two.

The same forecast puts a price on the queue: what each week of delay costs a project in dates, penalties and margin (project financials). Before anyone moves a person, the move is tested in a What-If: re-sequence, pause what can wait, move people, hire where it counts, or add an AI agent as a resource. The chosen plan becomes every team’s priority list, and progress flows back into the forecast.

In Epicflow the teams come first. Projects come and go, but it is your people who stay and get the job done.

What this means for next year’s plan

An annual plan is usually made the way the pattern above starts: every project looks feasible on its own, and capacity is counted as one number, the headcount. The time dimension is planned in detail; the capacity dimension is assumed. The projects that start together in January turn amber together, and by the time they turn red, the help they need is already promised to other red projects. Nobody chose it; the plan was followed while reality moved on.

Enrique Rey, with whom I founded the company behind Epicflow, used to say that the only way to correct a plan is through the projects you have not started yet. The running ones are past correcting: their dates stand and they are already red. The new ones you can still place so that they give the running ones room to recover, instead of stacking a new overload on an old one. That deserves an article of its own; here it is the reason the annual plan is where the correction happens.

The answer follows from the same two dimensions. Look at the load on every resource group over the year before committing to the plan, and start projects only when the bottleneck has room, instead of starting everything at once. The annual planning page shows in under two minutes what that does on a sample portfolio, and explains the four things a capacity-based annual plan needs.

About this article: the story and the conclusions are my own, from my years as a critical chain consultant and from my PhD research. The sources are in the full version on Flow Economics; the public cases are taken from the official reviews linked in the text. The voice in the video is an AI clone of my own voice.