The video gives you the short version: most software projects do not fail because of bad developers. They fail because of a conversation that never happened.
This is the longer version. What that missing conversation looks like, what scope creep actually is, and how to make sure your next project is the one that works.
What Is Scope Creep?
Scope creep is what happens when a project’s requirements quietly grow after the work has started. One extra feature here. A small change there. A "while you’re in there, could we also" every couple of weeks.
None of it was in the brief. None of it was priced. All of it takes time. And because each addition is small, nobody notices the project changing shape until the budget runs out before the feature list does.
It is like asking your builder for a conservatory halfway through them fitting your kitchen, then being surprised the quote went up and the finish date moved.
Here is the important bit. Scope creep is not caused by demanding clients or greedy developers. It is caused by a missing document. If nobody wrote down exactly what the thing was supposed to do, then nobody can say when it is finished, and every new idea feels like it should have been included in the price.
The Numbers Are Not Kind
This is not a rare problem, and it is not a new one. The software industry has been measuring its own failure rate for decades and the results barely move.
The Standish Group’s long-running CHAOS research has consistently found that only around one in three software projects succeed, meaning delivered on time, on budget, and with a result people are happy with. Roughly a fifth fail outright.
McKinsey and the University of Oxford studied thousands of large IT projects and found they ran 45 percent over budget on average while delivering 56 percent less value than promised.
And the Project Management Institute has reported that around half of all projects experience scope creep.
Half. This is not something that happens to unlucky people. It is the default outcome of starting a build without a proper specification.
The Five Ways Scope Creep Sneaks In
After enough rescue conversations, you start to see the same patterns. These are the five we see most.
1. The "while you’re in there." Small verbal requests that never touch a document. Individually reasonable, collectively a second project hiding inside the first.
2. The demo effect. The first working demo is exciting, and excitement produces ideas. Good ideas, usually. But a good idea arriving mid-build costs three times what it would have cost in the plan.
3. Stakeholder soup. The project starts with one decision maker and somehow ends up with five. Each new voice arrives with opinions and no context, and the developer tries to please all of them.
4. The vague brief. "Like Uber, but for scaffolding." That is a pitch, not a specification. If the brief fits on a napkin, the budget is a guess and everyone is pretending otherwise.
5. No change process. New ideas during a build are normal and often valuable. The failure is absorbing them silently instead of writing them down, pricing them, and deciding together whether they go in now, later, or never.
The Warning Signs Your Project Is Drifting
If your project is live right now and something feels off, look for these.
- The deadline has moved twice but the feature list has not shrunk
- The project has been "nearly done" for more than a month
- Progress updates describe effort ("we worked on the dashboard") rather than outcomes ("the dashboard is finished and tested")
- Nobody can tell you what a requested change will cost before it gets built
- You cannot point to a single document that says what "done" means
One of these is a wobble. Three or more means the project needs a reset conversation, and the sooner it happens the cheaper it is.
How the Next One Will Not Fail
The fix is not talent. It is process, and it is not complicated.
Write the specification before the code. Every screen, every feature, every integration, agreed by both sides before the build starts. This is what a discovery phase is for, and we have written a full guide to it in our blog on the most expensive mistake in app development.
Put a change process in place. When a new idea appears mid-build, it gets written down, priced, and scheduled. Into this phase, into phase two, or into the "maybe never" pile. No silent absorption.
Build in phases. Launch a core version first, learn from real users, then extend. Small releases keep the feedback loop short and the risk low.
Appoint one decision maker. Opinions from everywhere, decisions from one place.
None of this slows a project down. It is the thing that stops a project slowing itself down.
Start With a Proper Scope
If you have an idea brewing, or a failed project you are nervous about restarting, the best first step is clarity on what you are actually building.
We built a free tool for exactly this. Answer 8 questions about your idea and
Scope My App generates a personalised scope report: complexity rating, recommended build phases, estimated investment range, and the risks worth knowing about. No email required. No sales call.
