← All articles

25 June 2026 Β· By Douwe Pietersma

A sharper scope boundary demonstrably lowers the failure rate

Projects with a sharp scope definition demonstrably perform better on cost and schedule. A larger scope is not ambition β€” it is a higher chance of failure.

scope boundaries PDRI

In the final weeks before kickoff, a project team adds three more 'quick wins' to the scope β€” and discovers six months later that those three additions together cost more interfaces than the rest of the project combined. There is a persistent misconception in project land: that a larger scope signals more ambition, more drive, more value. The opposite is better supported by evidence. The sharper and more deliberately small the scope, the greater the chance the project succeeds. Boundaries are not a limit on your ambition: they are the condition for achieving it.

Better scope, better outcomes

The evidence is concrete. In 2017, as part of the Construction Industry Institute's PDRI research, Collins, Parrish and Gibson examined the relationship between scope definition and project performance. Projects with a better scope definition before the start of execution performed statistically significantly better: roughly 14 percent better on cost and 16 percent better on schedule.

These are not small margins. And they do not come from working harder during execution, but from thinking better before the start. The gain arises at the drawing board, not on the building site.

One caveat about this research: the evidence comes mainly from the construction and engineering sector, where the PDRI belongs. For IT and organisational projects it is wise to triangulate it with other sources. But the underlying logic, that ambiguity about what is and is not included is a structural cost, holds well beyond a single sector.

Why a larger scope is a higher chance of failure

The Advisory Board on IT Assessment is unusually explicit here. It states that scope should be "kept as small as possible", with a clear rationale: a larger scope means a higher chance of failure. This is not a dogma of caution, but an observation about how complexity behaves.

Every expansion of scope adds complexity not linearly but more than linearly. More components means more interfaces, more dependencies, more parties who have to agree, and more ways in which things can go wrong. A project that wants to solve "everything at once" signs up in advance for a web of connections that no one can any longer oversee.

Scope is not a wish list. It is a boundary you draw deliberately, in full awareness that everything you pull inside it increases the chance of failure.

Scope in terms of results, not activities

The Advisory Board also imposes a requirement on the form of the scope description: it must be "described in terms of results to be achieved". Not as a list of things the project team is going to do, but as a delineation of what will exist at the end.

That ties directly to the requirement that goals be outcome-focused. A scope written up as a list of activities, "we build X, we set up Y, we migrate Z", obscures which results do and which do not fall within the boundaries. A scope that describes results forces sharpness: this we deliver, this explicitly we do not.

The power of the explicit "not"

The most valuable part of a scope definition is often not what it contains, but what explicitly falls outside it. The out of scope list is the antidote to scope creep, the gradual expansion by which so many projects overload themselves.

Without an explicit outer boundary, every new wish is in principle open to discussion. "Could we just add this as well?" then has no natural answer. With an explicit outer boundary, every expansion becomes a deliberate decision, with a visible price, and that is exactly what you want. Expanding is allowed, but as an explicit choice, not as silent accretion.

What this means for you

Run your plan's scope through one test: is there an explicit list of what falls outside it, or only a list of what's in? If the out-of-scope list is missing, write it today β€” before the next 'can we just add this too' request.

Keeping the scope deliberately small is not a lack of ambition. It's how ambitious projects actually get finished.

Sources

  1. Collins, W., Parrish, K. & Gibson, G.E. (2017), Journal of Management in Engineering.
  2. Adviescollege ICT-toetsing, Toetskader (eis dat scope "zo klein mogelijk gehouden" en "beschreven in termen van te behalen resultaten" wordt).

Want your project plan checked?

Upload your project plan and receive an AI readiness score across 7 categories with go/no-go advice and the gaps to close before kickoff within two minutes.

Try PlanScore