A Project Slot Is Not A Unit Of Capacity

Five at a time, and labels did not make the list

A multi-plant protein processor decided it would run five improvement projects at a time. As one finishes, another rotates in. It is a reasonable instinct. Organizations that run everything at once finish nothing, and a leadership team that says no to a sixth project is usually doing better than one that says yes to a twelfth.

Then the list came back. Flexible film, a $4.6 million category where comparable competitive events had returned 15 percent or better almost every time, was pushed out on the grounds that it was too much of a lift right now. The plan instead was to accept the incumbent's standing offer of 4 percent, which was the same proposal the supplier had submitted before negotiations opened. Labels, which one analyst had already sized at roughly $390,000, was simply out.

The reaction in the room was the right one and it was not about the merits of either category. Labels and third-party logistics do not touch the same people. Neither does film and energy. The cap was one number applied across a portfolio whose projects almost never draw on the same humans, which means the number was throttling value while protecting nobody from overload.

A cap on count is not a cap on load

Limiting work in process is one of the few management ideas that works nearly everywhere it is applied. On a line, capping the number of jobs released ahead of the constraint shortens queues, cuts expediting, and makes due dates mean something. The reason it works is specific: the limit is set at the constrained resource. You do not cap jobs in the plant, you cap jobs at the bottleneck.

A portfolio cap set as a count breaks that rule at the first step. It assumes every project consumes the same thing, which is only true if every project consumes the same people. In a sourcing or improvement portfolio, that is almost never the case. A labels project runs through packaging engineering and a graphics coordinator. A logistics project runs through distribution and a transportation analyst. A labor study runs through one plant's supervisors. Counted as slots, those three are identical and interchangeable. Measured as load, they overlap almost nowhere.

Two failure modes follow, and both showed up here.

The first is that the cap silently reprices work. A category with a sized return gets compared not against its own cost but against the opportunity cost of a slot, and slots are scarce by decree rather than by capacity. That is how a half-million-dollar item with a light workload gets dropped while a heavier item with a thinner return keeps its place. Nobody made that trade deliberately. The counting rule made it.

The second is that finished work keeps occupying slots in people's heads. One category on this list was effectively complete and locked for years forward, and it was still being discussed as though it held a slot. A count-based limit needs an explicit release event, and if closing a project is a review-meeting activity rather than a same-day one, your real limit is lower than your stated one by however many finished projects are still sitting on the board.

Re-cut the cap, do not argue against it

The instinct when a client or a leadership team sets a limit you disagree with is to argue the limit down. That argument is unwinnable and it is also the wrong one, because the limit is not the mistake. The unit is.

The move that works is to bring back the same portfolio expressed in load rather than in count. For each active and parked project, name the functions it consumes and the specific people inside those functions. Then show the collisions. In this case the honest read was that the list could probably support eight to ten concurrent projects with less strain on any individual than the current five, because the current five happened to stack on the same plant.

Two supporting habits make that argument land. First, every parked item stays visible with its sized value and the one thing it is waiting for, so nobody has to remember that a $390,000 item exists. A parked list that is not published is a cancelled list. Second, a completed project is closed and its slot released on the day it closes, not at the next portfolio review, and the closure is stated out loud so the room stops carrying it.

There is a judgment call underneath all of this that is worth naming plainly. A decision this consequential had reached us through an intermediary, and the person who actually set the rule had never heard the case directly. It is tempting to work the relationship you have rather than the one you need, because the relationship you have answers your calls. That is a comfortable way to lose an argument you never made. When a limit is going to cost a client six figures, take the numbers to the person who set the limit, show them the last thirteen comparable events and what those returned, and let them decide with the evidence in front of them. They may still say five. But then it is a decision rather than an accident of who was in the room.

What a well run portfolio limit reads like

The limit is stated per constrained function, not per portfolio, and each function's limit traces to a named group's capacity. Every active project lists the functions and people it consumes. Every parked project carries a sized value, an owner, and the single condition that would un-park it. Completed projects are closed and released the day they close, and the count of open slots is current on any given morning. Nobody can name a parked item worth more than the smallest active one without a written reason it stays parked.

The number was never the problem

Five was defensible. Five projects, counted, was not. The plant that set the cap was protecting a handful of people from being pulled in every direction, which is a real problem with a real fix. Counting is just the fix that requires knowing nothing about who does the work.