# Trap 2 - The scope

> Programs rarely sink from one bad idea. They sink from carrying every good one.

Source: https://www.bluewise.fr/why-programs-fail-the-scope-trap  
Author: Marc Morel  
Published: 2026-10-15  
Category: Programs  
Series: Why programs fail, part 3

## The ship that sailed 1,300 meters

On 10 August 1628, a crowd gathered on the quays of Stockholm to watch the Vasa leave on her maiden voyage. She was the pride of the Swedish navy: 64 bronze cannons on two gun decks, hundreds of painted carvings, a ship built to impress a king and frighten his enemies.

A few weeks earlier, her stability had been tested. Thirty sailors ran back and forth across the deck. After three runs she was rolling so hard that the admiral stopped the test. Nobody stopped the launch.

She sailed about 1,300 meters. A gust of wind heeled her over, water poured through the open gunports, and the Vasa sank in the harbor, in front of the whole city.

The legend says the king kept adding guns and decks during construction. Historians now doubt it; even the story grew in scope over the years. What nobody disputes is simpler: she was built to carry more than her hull could hold, and the test that said so was explained away.

## One more cabin, one more gun

Every program starts with a problem worth solving. Then the requests arrive. Marketing has wanted a new consent model for years. Risk would like the scoring engine replaced while we're in there. A competitor just launched a feature; we need it too.

Each request is reasonable. Each comes from someone important. And each one makes the program look bigger and more strategic, which makes it easier to fund. So nobody objects. A program that started as a fix becomes a transformation, with a transformation's budget, timeline and number of stakeholders.

Nobody adds a deck on purpose. They add a cabin, a gun, a carving. One at a time, the center of gravity rises. The team keeps building, the plan stays green, and the first real test is the maiden voyage: go-live, in front of the whole city.

**That is the scope trap: letting a program grow to carry everything everyone wants, until it can no longer carry what it was built for.**

## The ten faces of the trap

In 25 years, I have seen it take ten shapes, in three families: how scope gets in, how scope grows, and why scope never comes out. Most overloaded programs show at least half of them.

### How scope gets in

- **The solution as a requirement.** The program is launched as "a new portal," "a data platform" or "an agent," not as a problem to solve. Once the answer is the scope, nobody can ask whether a smaller answer would do.
- **Everyone's wish list.** To get the business case signed, each stakeholder receives one item in exchange for their support. The scope becomes a peace treaty, not a design.
- **Platform before product.** The program builds infrastructure for needs nobody has yet: the generic engine, the reusable framework, the API every team will one day consume. Today's users wait for tomorrow's.

### How scope grows

- **"While we're at it."** The most expensive four words in IT. The team is already touching the system, so the adjacent change looks free. It never is: it brings its own tests, data, dependencies and stakeholders.
- **Matching the rival.** A competitor ships something, and it goes on the list without anyone checking whether your customers want it.
- **The compliance umbrella.** Some requirements are truly mandatory. But once "regulatory" becomes a password, everything shelters under it, and nobody dares ask which article of which text actually requires this feature.
- **Changes without a price.** New scope is accepted in a workshop, recorded in a backlog, and never shows up in the date or the budget. The plan stays green. The ship gets heavier.

### Why scope never comes out

- **No non-goals.** The program says what it will do, never what it won't. Anything not explicitly excluded is fair game, and every steering committee reopens it.
- **Descoping as failure.** Removing a feature feels like breaking a promise to its sponsor, so nobody proposes it. Programs add scope easily and remove it only in a crisis, when removal costs the most.
- **The test that gets explained away.** The performance test fails, pilot users struggle, the migration rehearsal takes three times longer than planned. Each result gets a reason, and none of them gets to change the plan. The admiral stops the test, and the ship sails anyway.

## The weight nobody weighs

Scope creep is so common that we've stopped noticing it. In PMI's 2018 *Pulse of the Profession*, about half of projects reported uncontrolled changes to their scope. And the cost is rarely where people look for it.

**Weight grows faster than scope.** Every new feature must work with every existing one. Ten features make 45 possible pairs to design, test and support. Twenty features make 190. Double the scope, and you roughly quadruple the interactions. That's why the last 20% of scope so often takes half the time.

**Much of the cargo is never used.** Pendo's analysis of product usage found that [80% of features in the average software product are rarely or never used](https://www.pendo.io/resources/the-2019-feature-adoption-report/). Every one of them was someone's priority once. Every one of them is still being maintained, secured and migrated.

**The bigger the ship, the more it misses.** PMI's 2026 report found that [31% of complex projects fail to deliver the full scope of their intended benefits](https://www.pmi.org/about/press-media/2026/pulse-why-complex-projects-fail-best-practices-are-not-enough-system-thinking), more than twice the rate of projects overall.

There is also a quiet asymmetry. Every addition has a sponsor who wants it. A removal has nobody, so scope only ever moves in one direction, until the hull decides for you.

## Early signals

You can feel the ship start to list long before it capsizes:

- Nobody can state the problem in one sentence that the sponsor and the team both agree with.
- The list of stakeholders keeps growing, and each new one arrives with requirements.
- Scope has grown since the business case, and the date and budget haven't moved.
- There's no written list of what the program will not do.
- "While we're at it" comes up in every workshop.
- Features are justified by what competitors have, not by what customers do.
- Every requirement is tagged "regulatory," and nobody can cite the article.
- In two years, nothing has ever been removed from the scope.
- A test or pilot failed, and the response was an explanation rather than a decision.

## Keep the ship upright

The answer isn't to refuse every request. Programs need to adapt as they learn. It is to **make scope visible, priced and reversible, so the ship is designed for the load it actually carries.**

1. **Start from the problem and the outcome.** Write the outcome as a measurable change for real people: "a new customer can open an account in under ten minutes," not "a new onboarding platform." Every item in scope must trace back to it.
2. **Write the non-goals.** A short, explicit list of what the program will not do, signed by the sponsor. It is the cheapest risk control a program will ever have, and it ends a surprising number of debates before they start.
3. **Give scope a budget.** Treat scope like money: something new comes in, something of similar size goes out, or the date and budget change openly. Nothing enters for free.
4. **Price every change at the moment of decision.** Show its effect on the date, the cost and the risks in the same meeting that approves it. Most scope creep survives only because its cost is invisible when it is accepted.
5. **Ship the smallest thing that proves the outcome.** Put a thin, real slice in front of real users early. Usage data settles arguments that workshops never will.
6. **Product before platform.** Build for needs that exist today, and let the platform grow as the second and third products arrive. Generalize from real cases, not imagined ones.
7. **Challenge the umbrella.** For every "regulatory" requirement, name the text and the article. Keep what is truly required, at the level it is required, and treat the rest as ordinary scope.
8. **Make removal normal.** Review scope every quarter with the same energy as additions. Retire features nobody uses, and thank the people who propose removing things: they give the program back its stability.
9. **Give your tests the power to stop a launch.** A stability test that can't delay the voyage is theater. Decide in advance which results stop or reshape a release, make them visible to the sponsor, and protect the people who bring bad news. The admiral needed someone he was allowed to tell.

## What to avoid

- Launching a program named after a solution.
- Buying stakeholder support with scope.
- Accepting a change without showing its cost in time and money.
- Building a platform before a single product needs it.
- Treating "regulatory" as a reason nobody may question.
- Celebrating additions while treating removals as failures.
- Explaining away a failed test instead of deciding what it changes.

## The AI twist

AI makes every extra gun cheaper to cast. A feature that took a sprint now takes an afternoon, so "while we're at it" has never sounded more reasonable. But AI lowers the cost of building, not the weight of carrying. Every feature still interacts with all the others, still has to be secured, supported, migrated and explained to users. Cheap additions mean the center of gravity rises faster than ever.

AI also brings a new face of the first family: the solution as a requirement, rebranded. Programs launched as "we need an agent" rather than "we need to solve this problem" are the Vasa of this decade. Gartner predicts that [over 40% of agentic AI projects will be canceled by the end of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027), citing rising costs and unclear business value.

Used well, though, AI is an excellent ballast engineer. It can build a throwaway prototype to test whether users want a feature before anyone commits to it. It can analyze usage data and list the features nobody touches. It can estimate the impact of a change across the codebase in minutes, so every request arrives with its price. And it can trace a "regulatory" requirement back to the text, or show that the text doesn't say what everyone assumed.

## Built for its load

The Vasa was raised from the harbor in 1961, remarkably intact, and today she stands in a museum in Stockholm. Visitors walk around her for hours. She is magnificent: every carving, every gunport, every ambition of the men who built her. A perfect ship that could not sail.

The best programs I've worked on were not the most ambitious on paper. They were the ones with a sponsor who could say, calmly, "not in this release," and a team that was thanked for removing things as warmly as for adding them.

So at your next scope review, ask one gentle question: *if we had to launch next month, what would we leave on the quay?* The answer is usually the scope you should have had all along.

Have you ever watched a program take on one deck too many? I would genuinely love to hear your story.

*All situations described here are composites, drawn from many programs over 25 years.*