Six months to first release. The first release would carry the essential things, and we agreed to move the rest into a second and third phase.
The first two months went well. Then we showed a preview.
The owner started adjusting. Each request was small. Move this here. Change how that behaves. Nothing that sounded like a rebuild.
Some of them were not small. A change that looks like one screen can reach into everything built after it, and you cannot see that from the outside. You see a small ask. The team sees three weeks.
We launched four weeks late. Most of that delay was not development. It was legal review and contracting for third parties we depended on, which took far longer outside the team than the work took inside it, and all of it had to clear before anything could ship.
The product worked. And the owner was expecting a different product.
Everything he had asked for over those two months had been captured and moved to phase two. That was the right call. But somewhere along the way, the part where this release was phase one of three stopped being said out loud.
Nobody told him it was off. It simply stopped being mentioned, and he carried on picturing the whole thing.
So he looked at what launched, saw pieces missing, and was disappointed. From where he stood, that was fair.
I proposed those phases. They were agreed in the room, and I treated that as the end of it. An agreement nobody repeats does not stay agreed.
None of that was technical. All of it was visible from the first week, and free to ask about.
I call it structural risk. It is the missing question again, except now it lives in how the work is set up rather than in a single decision or a single codebase. It tends to hide in three places, all of them in plain view.
The first is scope. Not scope that grows loudly. Scope that grows politely. Someone asks for one more thing. It is reasonable, so it goes in. The date does not move.
Each yes shifts the line between what the project treats as essential and what it merely carries. Nobody decides to shift it. It just shifts. A few months in, everything on the plan looks equally important, because nobody can point to where the line used to be.
The question that goes unasked is the plain one. What did we just agree to drop to make room for this.
The second is agreement, or the look of it. Engineers build toward one understanding. Stakeholders expect another. Leadership describes a third to the board. Everyone uses the same words, so everyone assumes the words mean the same thing.
That was the real failure above, and the scope creep was only its symptom. The gap stays invisible until launch, when people compare what arrived against what they had been picturing.
The question that goes unasked is whether everyone means the same thing by done.
The third is the work nobody is tracking. Legal review. Contracts with the parties you depend on. Security sign-off. Procurement. None of it is development, so none of it is on the development plan, and all of it sits between you and a launch.
Ours cost four weeks. Not because anything went wrong, but because that work had never been on a timeline in the first place. It was knowable in week one. Nobody asked.
The question that goes unasked is what has to be true outside this team before we can ship.
Scope, agreement, and the work nobody is tracking. None of them is a technical failure. Each is a decision nobody made out loud, sitting in the open, waiting to be paid for.
Here is the part I would rather write than the failure.
We shipped phase two a few weeks later. That was the product the owner had been describing, and when it arrived it landed.
Which tells you something about where the problem actually was. The phases were not wrong. The plan was not wrong. Every request he made had been captured, scoped and scheduled, and the proof is that we could deliver it quickly once we sat down and said out loud what was in which release.
What had failed was one sentence, never repeated often enough. This is phase one.
The recovery was cheap because the thinking was already done. That is the useful part. If the phasing had been sloppy rather than unspoken, a few weeks would have been a few months.
So here is a short pass to run at the start of a project, before anyone writes a ticket. Three questions, out loud, with the people who will do the work.
What have we already agreed to drop? If the scope keeps growing and nothing has been cut, the plan is fiction. Find the cut now, while it is cheap.
What does done mean for this release, in one sentence, and does everyone say the same sentence? If you get three sentences, you have three projects, and you found out in week one instead of at launch.
What has to happen outside this team before we can ship? Name it, and give it a date, because nobody else will.
None of these are technical. That is exactly why they get skipped. A kickoff is full of people ready to answer hard technical questions, and these are not those.
Ask them anyway. The risk you surface in the first week is the one you do not pay for in the last one.
Which leaves the question I keep circling. If these risks are visible the whole time, and free to ask about, why do they go unasked so reliably. Why does a plan drift toward the unexamined instead of away from it.
That drift is not bad luck. It has a shape, and that shape is where I go next.
Cases in this series are composites. The patterns are real, the companies are not.
The full Core and Bloat™ method, four boxes and all, sits at dirkbauer.com/core-and-bloat.html.