The structuring gap

When a project stalls, the explanation offered afterwards is almost always one of two things: the market was wrong, or the team did not execute. Both are usually too generous, and both arrive too late to be useful. In our experience the more common failure sits earlier and lower down. A decision was taken. Everybody agreed with it. And nobody converted it into the sequence of smaller decisions it actually implied.

We call this the structuring gap, and it opens quietly. A board approves a direction. A founder picks a market. An owner commits capital to a new line of business. The decision is real, the money is real, and the calendar starts to move. What does not yet exist is an answer to a set of unglamorous questions: who owns this, what has to be true before the next stage begins, what does the first version actually cost, who signs, and what happens if the answer to any of those is no.

Six months later the project is not dead. That is the difficult part. It is simply nine months behind, with a budget that has been spent on the parts that were easiest to start.

Three symptoms worth recognising

The gap is hard to see from inside, because everything about it looks like progress. Three symptoms show up early enough to be worth naming.

A calendar with dates but no thresholds

The plan says the pilot launches in March. It does not say what must be true in February for March to be possible, nor what the team should do in the case where it is not. A calendar of dates is a statement of hope. A calendar of thresholds is a plan, because it tells you in advance which week you will discover you are in trouble.

Universal agreement and no movement

When everybody in the room supports a project and nothing has happened in eight weeks, the problem is rarely conviction. It is that the project has not been broken into pieces small enough for any single person to own one. Enthusiasm distributes easily. Responsibility does not.

Nobody can price the first version

Ask what the first credible version of the project costs, in money and in months, and note how long the silence lasts. If the answer is a range so wide that both ends imply different businesses, the project has not been structured. It has been described.

What structure actually means

Structure is not documentation, and it is not governance in the procedural sense. It is the set of constraints that turn an intention into work somebody can begin on Monday. In practice it means being specific about four things.

• Scope. Not what the project could eventually include, but what the first version deliberately excludes, and why that exclusion is safe.
• Phasing. The order in which uncertainty is removed. Good phasing spends the smallest amount of money on the question whose answer would kill the project.
• Economics. What each stage costs, what it unlocks, and at what point the project becomes self funding or requires a decision to commit further.
• Decision rights. Who can say yes, who can say no, and what happens when they disagree. This is usually the piece that is left implicit, and it is usually the piece that costs the most.

None of this is intellectually difficult. It is simply unrewarding to produce, which is why it tends not to get produced. Structuring work generates no announcements and no momentum. It generates the conditions for momentum, which is a much harder thing to celebrate.

Sequencing is the deliverable

If we had to reduce our own method to a single idea, it would be this: in almost every project we see, the order of the work matters more than the quality of the work.

Consider a business preparing to open a new market. It can hire the country lead first, or sign the anchor partner first, or build the local product adaptation first. All three are necessary. The order determines the cost. Hire first and you are paying a senior salary to a person with nothing yet to sell. Build first and you have adapted a product to assumptions no customer has confirmed. Sign the partner first and you have a constraint, a deadline and a reference, which is to say you have converted an ambition into an obligation.

The right sequence is not always obvious, and it is not always the same. But it is always knowable in advance, and it is almost never chosen deliberately. Most sequences are chosen by whichever piece of work the team already knew how to start.

The uncomfortable part

Structuring a project forces the question that most planning processes are designed to avoid: what are we not going to do. Not later, and not in principle. Now, in this version, on purpose.

This is uncomfortable because exclusion is where disagreement lives. As long as the project remains broadly defined, every stakeholder can read their own priority into it and support it sincerely. The moment scope narrows, one of them discovers that their priority was in the part that got cut. That conversation is unpleasant, and it is far cheaper in month one than in month nine.

A useful test: if the structuring exercise has not produced at least one difficult conversation, it has not been done. It has been documented.

Where to start

When we are brought into a project that has stalled, we rarely begin with strategy. We begin by writing down what has actually been decided, what has merely been discussed, and what everyone assumes has been decided but nobody can point to. That list is usually shorter and more alarming than anyone expects, and it is almost always enough to explain the delay.

From there the work is mechanical rather than clever: attach an owner to each open item, attach a date, attach a threshold, and identify the two or three items on which everything else depends. Those are the only ones that need senior attention. The rest can be delegated the moment they are named.

Projects do not usually need more ambition. They need somebody to stand in the gap between the decision and the work, and to stay there until the two are connected.