Why more open projects deliver less

A retail technology company, 140 people. At the start of the year the leadership team listed twelve priority initiatives: a new customer portal, tax integration, an onboarding overhaul, a database migration, three large-account projects, and so on. All were approved, and all started in February.

By July, four had shipped. The year before, with five approved initiatives, six things were done by July — the five plus one that showed up along the way. Same team, same budget, more ambition, less delivered.

01The idea: flow, queues and Little's Law #

Donald Reinertsen published The Principles of Product Development Flow in 2009, after years applying queueing theory to product development. The book has 175 principles; the spine of all of them is that knowledge work obeys the same math as any system with a queue — and that most companies manage the cost of the work and ignore the cost of the queue.

The most useful relationship is Little's Law, formalized by John Little in 1961: in a stable system, the average time an item takes to move through equals the average number of items in progress divided by the average completion rate.

Reinertsen adds two things the formula doesn't show on its own. First, the delivery rate isn't constant: it drops as work in progress rises, because of context switching and extra coordination. Second, queues grow non-linearly as utilization approaches 100% — the last 10% of load costs far more waiting time than the first 50%.

02Why managerial intuition gets this wrong #

Intuition says: if it matters, start it. Starting looks like progress and costs almost nothing — a kickoff meeting and a document. The real cost shows up later, spread thin: every open front pulls attention, generates status questions, competes for the same specialist and creates one more place where something can stall.

There's a social effect too. Cancelling or postponing an approved project looks like defeat; letting it crawl looks like prudence. The result is a portfolio that only grows, where the real prioritization is done by whoever is loudest that week.

In 2009 Reinertsen was writing for product teams. In a mid-size Brazilian company in 2026 the phenomenon is broader: client projects, internal initiatives, regulatory demands and process improvements all compete for the same ten people, and no consolidated list exists.

03The math of an inflated portfolio #

The scale of that mid-size Brazilian company of 140 people (figures in Brazilian reais), with a 22-person project team. Explicit premises, conservatively estimated:

Want to see how this looks inside a real operation? Explore the platform.

The math: with 12 open and 2 deliveries a month, the cycle is 6 months. Cap it at 5 and assume only a 30% gain in rate — a modest number next to what the context-switching literature suggests — and you get 2.6 deliveries a month and a 1.9-month cycle. If each delivered project unlocks on average R$ 120 mil in annual revenue or savings, pulling four of them forward by several months is worth on the order of R$ 480 mil. None of that requires hiring anyone.

04Where this stalls in practice #

1. Nobody has the full list. Client projects live in one tool, internal initiatives in another, and the 'small stuff' that eats weeks lives nowhere. With no list, no limit is possible.
2. Limiting means saying no to a peer. A work-in-progress cap only survives if it's a leadership rule, not a project manager's preference.
3. 'Parked' gets confused with 'lost'. A project waiting in the queue with its scope intact hasn't lost anything — it just hasn't started. You have to separate the waiting line from what's actually running.
4. People are assigned in fractions. Saying someone is 20% on four projects is accounting fiction: in practice they switch context four times a day.

05What data-driven management answers #

A work-in-progress cap is easy to decide and impossible to sustain without visibility. The data you need is mundane: what's open, since when, with whom, and in what state. When that record comes out of the work itself, cycle time calculates itself and the queue stops being a matter of opinion.

It's worth pairing this with two other readings. The queue tends to concentrate at one specific step — that's Goldratt's argument about the bottleneck. And constant context switching isn't a manager's discipline problem: their day is fragmented by nature, which makes it even more important that the system, not memory, holds the state of things.

That's the job of the projects and operations modules in the platform: one list of everything open, with time in each state, no manual consolidation. If you'd rather see the cut by area before deciding where to apply the cap, the solutions by operation help, and a short conversation usually clarifies more than a feature comparison.

The team wasn't slow. It was divided by twelve.