Full Kit: Why the Best Time to Start a Project Is When It Can Actually Run

Every portfolio has a number that leaders watch with quiet pride: how many projects are underway. It feels like the measure of an organisation in motion. Twelve initiatives live, work happening on all of them, nobody idle. Starting is visible, it is reassuring, and it is almost always rewarded. A project that has started has momentum. A project still waiting in the queue looks like indecision.

So the instinct, when a new piece of work is approved, is to begin. Assign someone, open the plan, get the first task moving. Waiting to start feels like waste, especially when there is a capable person sitting there who could be making a beginning right now.

This is one of the most expensive instincts in portfolio management. Most work is started too early: released into the system before it is actually ready to run. And a project that starts before it is ready does not advance. It stalls, quietly, a week or two in, when the first missing input reveals itself. What you have created is not progress. It is a stalled project wearing the costume of an active one.

What "ready" actually means

Borrow a word from the discipline that first named this problem: the full kit. Before a piece of work is released, everything the first real block of it needs should already be in hand. Not everything the whole project will ever need, which is impossible to assemble in advance, but everything required to run the opening stretch without stopping.

That includes the obvious inputs and a set of less obvious ones that are the usual culprits. The specification is settled enough that the work will not be rebuilt when someone finally reads it properly. The decisions the work depends on have actually been made, not merely scheduled to be made. The upstream deliverable it consumes exists. Access, environments, licences and permissions are granted rather than requested. And the people it needs, including whichever scarce specialist it will lean on, are genuinely available in the window the work will reach them, not notionally assigned across four other things.

A project is fully kitted when you could hand it to the team and they could run, without stopping, until the work itself throws up the next genuine unknown. Anything short of that is a project that will start and then wait.

Why a stalled start costs more than a late start

Here is the part that runs against the instinct. Not starting looks like lost time. But starting something that then stalls is worse than leaving it in the queue, and it is worse in several ways at once.

A stalled project does not sit there harmlessly. It occupies a slot in the work in flight, and work in flight is not free: every live project draws coordination, status-chasing, and attention, whether or not it is moving. It fragments the people assigned to it, who now hold an open, unfinished thing in their heads while they are pulled onto something else, which is precisely the multitasking tax that shreds a portfolio's throughput. And when the missing input finally arrives, the work does not resume where it paused. It has to be picked up again, re-read, re-understood, re-familiarised, because the context has gone cold. The restart is not free either.

Worst of all is what a premature start does to your constrained resource. Half-ready work does not reach the constraint in one clean run. It arrives in fragments, stops when it hits the missing piece, and comes back later needing the constraint's attention a second time to finish what a full kit would have let it do once. Every one of those interruptions is constraint time spent, and constraint time is the one thing in the system you can never recover. You have taken your scarcest hour and spent it on a stutter.

The idle-resource objection

The strongest argument for starting early is the one that feels most responsible: the resource is free right now, so we should use it. Leaving a capable person unstarted while approved work sits in the queue looks like exactly the kind of waste a good manager is meant to eliminate.

But this is the utilisation trap wearing a new outfit. Keeping someone busy is not the same as advancing the portfolio. Feeding a resource half-ready work does not convert idle time into delivery; it converts it into a stalled project plus a future restart plus a fragmented specialist downstream. The apparent saving, an hour of someone's time that would otherwise have been idle, is bought at the price of several more expensive hours later, including some of the constraint's.

Readiness is the cheap thing. It is a specification finished a week earlier, a decision forced before rather than after the start, a dependency confirmed with a phone call. The constraint's time, and the throughput of the whole portfolio, is the expensive thing. Trading a little cheap waiting to protect a lot of expensive flow is not a close call. It only looks like one because the idle person is visible and the downstream damage is not.

Later start, earlier finish

The conclusion sounds like a paradox and is really just arithmetic: a project that starts later but fully kitted routinely finishes earlier than one that starts early and stutters. Delay to start is not the same as delay to finish. The early start banks a few days at the front and then loses them, several times over, to stalls, restarts and fragmented constraint time. The kitted start gives those days back at the front and then runs clean, and running clean is where the time is actually made.

This is the same lesson as capping work in flight, seen from the other side. Starting less to finish more governs how much you allow into the system at once. Full kit governs what state each piece is in when you let it in. One caps the quantity of live work; the other guarantees the quality of each start. A portfolio needs both, because a small number of stalled projects is only marginally better than a large number of them.

A gate, not a governance layer

The practical fix is a readiness check at the point of release: before a project is allowed to start, it has to clear a short, defined full-kit list. Is the spec settled? Are the decisions made? Do the inputs exist? Is the scarce skill actually available in the window? Not a committee, not a new reporting cadence, not another meeting in the calendar. A portfolio that answers a struggling delivery record by piling on oversight only finds its own coordination ceiling faster. This is the opposite move: a single yes-or-no gate that keeps unready work out of the system, so there is less live work to coordinate, not more.

The list itself is cheap to build, because the missing pieces are boringly consistent. In most organisations, the same three or four things stall the same starts every time: a decision that had not really been taken, an upstream deliverable that was not really done, a specialist who was not really free. Name those in advance and most premature starts disappear on their own.

What to watch instead of starts

At the portfolio level, the number to stop celebrating is how many projects are underway, because it counts stalled work and running work as if they were the same thing. The number worth watching is how much of your in-flight work can actually run right now: what proportion of live projects are moving, versus parked against a missing input.

That single figure tells you something the start count actively hides. A portfolio can look fully deployed, every resource assigned, every initiative live, and be mostly stalled underneath, holding capacity hostage in projects that cannot move. This is another face of the Project Illusion: a dashboard full of active projects read as a portfolio in motion, when a good share of that motion is projects sitting still with someone's name attached. A portfolio function that measures readiness at intake, and running-versus-parked in flight, is managing the thing that actually determines throughput. One that counts starts is measuring its own optimism.

The shift

The default is to treat starting as progress and waiting as waste, so work is released the moment it is approved and readiness is something the project is expected to sort out once it is already moving. Flow Economics says the opposite: releasing unready work is not progress, it is a stall you have not noticed yet, and the constraint pays for it. Assemble the full kit first, release the work only when it can genuinely run, and accept a little cheap waiting at the front to buy a lot of expensive flow later.

Starting a project has always felt like the moment something begins. In a constrained system, starting the wrong project, or the right project too early, is the moment something quietly stops. Before you release work into the portfolio, be sure it can actually run. The best time to start is not the moment you are allowed to. It is the moment you are ready.

---

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 part looks like on its own. If your portfolio measures how much work has started rather than how much of it can actually run, the Flow Economics framework is a good place to see the full picture.