The Case for Smaller Projects: Why Batch Size Decides How Much Value You Capture

Two teams are handed the same scope: a year of work to replace a core system. The first team plans it as one project. Design the whole thing, build the whole thing, integrate the whole thing, and go live at the end of the year. The second team plans the same work as four projects of three months each, every one of them delivering a usable slice of the new system into production before the next begins.

Same people. Same total scope. Same technology. On a resourcing spreadsheet the two plans look almost identical, and the first one usually looks tidier, because it has fewer moving parts and one clean go-live to manage.

The second plan is worth substantially more, and it is also less likely to fail. Not because the team is better, but because of a decision most portfolios make by accident and never revisit: how big to make each piece of work before it delivers anything.

That decision has a name. It is batch size, and it is one of the most consequential economic levers in a portfolio. This piece is about why the big batch quietly costs more, and how to think about the size of the work you release.

Batch size is a choice you are already making

Every project is a batch. It is a quantity of work that you accumulate, hold, and then release as a lump. A twelve-month programme is a large batch. A two-week increment that goes live is a small one. The scope can be identical; what differs is how much you build up before any of it reaches the finish line and starts returning value.

Most organisations never treat this as a decision. Batch size is inherited from how the work was scoped, how the budget was approved, or how the vendor priced the contract. A big initiative arrives as a big project because that is the shape it was funded in, and nobody asks whether the same scope, delivered in smaller pieces, would be worth more.

It almost always would, and the reasons are economic rather than a matter of taste.

The big batch returns nothing until the end

Start with the most basic point, and the one that matters most in a constrained portfolio. A project returns no value until it delivers. Work that is ninety percent complete has produced exactly nothing; it is inventory, not outcome. The value only lands when something reaches production, a market, a user, a customer.

A twelve-month project therefore holds all of its value hostage for twelve months. The organisation carries the full cost of the work - the people, the constrained capacity, the money - for a year before a single pound of return comes back. The four-project version returns value four times, starting at month three. The same effort, sequenced to deliver earlier, is worth more simply because value delivered sooner is worth more than the identical value delivered later.

This is not a soft argument about momentum or morale. It is the same time-value logic behind drag cost: the value of finished work is time-sensitive, so pushing its arrival later destroys real economic value. A big batch does not delay the work by accident. It delays it by design, because it is built to deliver everything at once, at the end. The bigger the batch, the longer the whole of its value sits in the queue, earning nothing.

The big batch hides its problems until the end

The second cost is subtler and often larger. A big batch delays not just the value, but the feedback.

When you finally integrate and release twelve months of work, you discover twelve months of accumulated misunderstandings all at once. The requirement that was misread in month two has had ten months to be built upon. The integration assumption that turned out to be wrong has shaped everything downstream of it. Every defect, every misread need, every architectural choice that does not survive contact with reality is found late, when it is most expensive to fix, because so much has been built on top of it.

Small batches surface the same problems early, when almost nothing has been built on the mistake yet. The team that ships a working slice at month three finds out at month three whether its assumptions hold. If they do not, the correction is cheap, because there are only three months of work resting on it. Feedback that arrives early is worth far more than feedback that arrives late, for the same reason a wrong turn spotted at the first junction costs less than the same wrong turn spotted fifty miles on.

This is why big projects so often slip by more than their size seems to justify. The slippage is not proportional to the scope. It is driven by rework discovered late, and late discovery is a direct consequence of batching the work into one long build with feedback deferred to the end.

The big batch concentrates risk

The third cost is the one executives feel most sharply after the fact. A big batch is an all-or-nothing bet.

If a twelve-month project is cancelled, descoped, or overtaken by a change in strategy at month ten, most of its value evaporates, because almost none of it had been realised yet. Ten months of constrained capacity return close to nothing. The four-project version has already banked three deliveries by then; only the fourth is at risk. Splitting the work does not just deliver value earlier. It de-risks the whole endeavour, because each increment that lands is value the organisation can no longer lose.

Large batches concentrate risk in exactly the place you least want it: at the end, after the money is spent, when your remaining options are narrowest.

Why the constraint makes this worse

In a portfolio that shares constrained resources - and every real one does - a large batch does one more expensive thing. It occupies the constraint for a long, unbroken stretch before releasing it.

While your scarce specialists are locked inside a twelve-month build, they are unavailable to anything else, and the true cost of that is not their salary. It is the value of everything else that could have passed through them in the meantime. A big batch is a long-term claim on your most valuable capacity, made once, at approval, and not revisited until the batch completes. Smaller batches hand the constraint back more often, which means the portfolio gets more chances to re-sequence, to respond to a higher-value opportunity, or to stop work that is no longer worth finishing. Batch size and portfolio flexibility are the same lever seen from two ends: the bigger the batches, the more rigid the portfolio, because the constraint is committed for longer before you can change your mind.

So why not make everything tiny?

Because splitting is not free, and this is the part the enthusiasts skip. Every batch carries a fixed cost to set up and release: the planning, the testing, the deployment, the coordination, the paperwork of a go-live. Call it the transaction cost. Halving your batch size doubles how many times you pay it.

That gives batch size the shape of a genuine trade-off rather than a slogan. Push batches larger and the holding cost climbs - value delayed, feedback deferred, risk concentrated. Push them smaller and the transaction cost climbs - you pay the overhead of releasing more often. The total cost is a U-curve, and the cheapest point is where the two meet. The reason so many portfolios sit far to the large-batch side of that optimum is not that they have calculated it and chosen. It is that the holding costs are invisible and unbudgeted, while the transaction costs are concrete and land on someone's desk, so the pressure is always to batch up and release less often.

There is a more useful move hidden in this, though. The optimal batch size is set by your transaction cost - so if you lower the cost of releasing, the optimum shifts smaller on its own. Organisations that invest in making a go-live cheap and routine, rather than a heroic quarterly event, do not just make their releases easier. They change the economics of the whole portfolio, because now smaller batches genuinely pay. The teams that ship in small increments are usually not braver. They have made shipping cheap enough that small increments are the rational choice.

How to split, and how not to

Splitting only pays if each piece delivers value on its own. The common failure is to slice a project into phases that are really just stages of one indivisible build - analysis, then design, then build, then test - so that nothing delivers anything until the last phase completes. That is not four batches. It is one big batch with reporting boundaries drawn inside it, and it carries every cost above.

A real split runs the other way. Each slice should deliver a thinner but complete piece of the outcome: a working part of the system, in production, useful to someone, on its own. The first increment of a system replacement might migrate one product line rather than designing the architecture for all of them. It is worth less than the whole, but it is worth something, and it is worth it now - and it teaches you what the next slice should be.

The test to apply at approval is simple, and it is a variant of the question Flow Economics asks everywhere: if we stopped after this piece, would we have delivered value? If the answer is no, you have not split the work. You have only split the schedule, and the batch is still as big as it ever was.

The shift

The instinct in most organisations is that a big, ambitious initiative deserves a big, ambitious project - that breaking it up is a loss of nerve, or an admission the thing was too hard to do properly in one go. The economics say the reverse. The big single project is the expensive way to deliver the scope: it delays all of its value to the end, hides its mistakes until they are costly, concentrates its risk where you can least absorb it, and holds your constraint hostage the whole time.

Decomposing that same scope into the smallest pieces that each deliver something is not caution. It is how you capture more of the value, sooner, at lower risk, with the option to change your mind still open. Batch size looks like a delivery detail. It is one of the quiet decisions that determines how much of your portfolio's potential value you actually get to keep.

---

Flow Economics is the discipline of understanding how value actually moves through an organisation when its resources are constrained, and of making decisions that maximise what the whole system delivers rather than what each project looks like on its own. If your portfolio is built from a few large batches rather than many small ones, the Flow Economics framework is a good place to see the full picture.