There’s a kind of software failure that never shows up in the statistics, because nothing was ever built. The company did the planning. There’s a requirements document somewhere, maybe some wireframes, maybe an estimate. And then nothing happened. Six months later the document is out of date, the sponsor has a new job, and the problem the project was meant to solve is still there.
We see this often enough to have a name for it internally: failure before launch. This post is about why it happens and what we’ve changed in our own process to stop it.
What planning is supposed to produce
Software planning is the work of defining objectives, requirements, scope, and feasibility before you commit to a build. Done badly it produces a document. Done well it produces a decision.
At Frogslayer the planning phase is the VDP Sprint: Validation, Design & Planning. It runs three to four weeks at a fixed fee. It opens with a two-day face-to-face workshop, continues with design sessions about twice a week, and ends with click-through mockups of the key screens, functional and non-functional requirements, a tech-stack recommendation, and a roadmap with the investment. The point of all that output is to make the go/no-go decision easy and the build predictable.
The VDP is our main risk-mitigation tool. It’s also the moment of greatest danger for a project, because the transition from planning to building is where momentum goes to die. Here are the four reasons it does.
Reason 1: scope creep, then sticker shock
Deciding to build should never be taken lightly, and once you decide, the temptation is to make it count. Every stakeholder has a feature. The latest technology trend has to be in it. The first version should “wow” users. Each addition is reasonable on its own, and together they double the timeline and the price.
Then the estimate arrives and the sponsor, who was picturing a smaller number, stops. The project doesn’t get killed. It gets “revisited next quarter,” which is the same thing with better manners.
The defense is to settle the business goal and the success criteria before any complex product decisions get made, and to keep asking, for every feature, whether it serves that goal. A first version that does one thing well and ships is worth more than a plan for everything that doesn’t.
Reason 2: misaligned expectations
Expectations are beliefs about what an effort will produce. The best products are built with outcomes in mind, but they’re also built by multi-disciplinary teams and sponsored by stakeholders with different jobs. Different perspectives mean different, sometimes competing, expectations.
Two patterns come up repeatedly. The first is a system meant to serve several business units that share most of their needs but disagree about what should be built first. Each unit expects its priority to lead, and the plan can’t satisfy all of them. The second is personal experience with a small project (a website, an internal tool built by a contractor) that sets unrealistic expectations for what a secure, modern application costs. When the real number arrives it reads as a mistake rather than a fact.
Both are solved the same way: surface the expectations early, in the room, and reconcile them before the estimate exists. That’s why the VDP starts with a two-day workshop rather than a questionnaire.
Reason 3: priorities change
Businesses change constantly, mostly in response to competitors, customers, and suppliers. A project that runs six months or more will be affected by priority shifts inside the organization, including ones made several levels above it that nobody thinks to mention to the team.
The most damaging version is a leadership change in the sponsor or product-owner role. A new leader inherits a wider portfolio and re-evaluates everything, and a planned-but-unstarted project is the easiest thing to cut. It has no sunk cost, no users, and no one defending it who was there at the beginning.
You can’t stop priorities from changing. You can shorten the exposure. A plan that takes four months to produce and then sits for three more will almost certainly meet a reorganization. A plan that takes four weeks and moves into build within a few more has a much better chance.
Reason 4: time
Too little. Too much. Too little time spent with end users. Too much time between phases. Too little time dedicated to the project by the people who have to make decisions. Too much emphasis on the calendar and not enough on the outcome.
Time cuts both ways. Rushing the plan skips the conversations about vision and priority that make it worth building. Padding the plan invites Parkinson’s law: work expands so as to fill the time available for its completion. The measure that matters is time to real business value, and the longer it takes to get there, the more likely the project is to fail before it starts.
What we changed
The four reasons above all point at the same gap: the space between “we have a plan” and “we’re building.” Our process is designed to close it.
The plan ends with a number. The VDP roadmap includes the investment, so sticker shock happens inside the sprint, where it can be handled by trading scope, rather than after it.
Scope is controlled from the start. We work to a fixed budget with controlled scope. New ideas are welcome, and they displace something rather than adding to the bill. That discipline starts in planning, not in the build.
The hardest things go first. The roadmap sequences the riskiest technical questions at the front of the build, so the plan doesn’t rest on an assumption nobody has tested.
The people who’ll use it are in the room. Not surveyed. In the workshop, in the design sessions, clicking through the mockups.
The gap is short. Kickoff is planned during the VDP, not after it.
When not building is the right answer
Some VDP Sprints end with a recommendation not to proceed, or to proceed with something much smaller, or to buy instead of build. Those aren’t failures of the planning phase. They’re the planning phase doing its job. The failure we’re describing in this post is different: a project that should have been built, that everyone agreed should be built, and that quietly wasn’t.
The first step
If you have a plan sitting on a shelf, the question is whether it’s still right. Bring it to a 30-minute call at /contact/ and we’ll tell you whether it needs a refresh or a restart. If you’re at the beginning, start with the VDP Sprint and read what custom software costs first so the number at the end isn’t a surprise. And if the plan is for a system that replaces one you’re already running, a System Evaluation of the current one is often the better place to begin.