We’ve noticed that almost all big initiatives follow the same pattern. Early on, teams are busy with development work in their Sprints, milestones are getting checked off, and the regular status reports show everything as “green.” Those early days feel productive, building out the foundational parts of the project that are well-understood, well-scoped, and easy to report upward.
Leadership is cautiously optimistic, but may be hedging their external commitments, knowing schedules tend to slip out at the end. The experienced people in the org may seem uneasy, quietly waiting for the hammer to drop. They don’t plan vacations towards the end of the release, having been burned too many times by what feels like the inevitable “end game” phase.
And sure enough, the moment integration starts, or deeper system testing begins, or real users touch the system for the first time, we realize things aren’t as rosy as the early status reports indicated. The project goes red. It’s a crisis. Leadership starts getting more heavily involved, bringing additional pressure to get the thing out the door by the committed date. Post mortems usually identify poor planning, undisciplined execution, or teams that couldn’t coordinate and communicate well enough.
While all of that early effort felt productive, the team was busy producing the wrong things. Not because they didn’t plan enough, or weren’t disciplined in their execution, but because the system rewarded the wrong sequence. Predictable work is easy to estimate, easy to staff, easy to put on a timeline, and easy to call progress, so that’s what gets done first. The hard stuff waits.
The Illusion of Foundation-First
There’s a widespread belief in project planning that you have to build those base foundations before you can get to the complex parts. After all, don’t we need to put the infrastructure in place, finalize the specifications for the system’s end state, and ensure the requirements are clear and detailed?
The problem is that the only way to learn about the complex aspects of that initiative is to build and test things in real-world situations. More planning and analysis won’t surface them. The complex parts are emergent—they reveal themselves through contact with reality.
So when teams sequence work to get the foundational pieces in place first, they’re not de-risking the project; they’re delaying learning. Status stays green right up until we get to the complex parts. Doing those last parts causes new information to emerge, and the project plan breaks.
What Emerges Late (but Didn’t Have to)
The things most likely to change your plan are often the things you discover last:
- How the pieces actually work together
- How real users interact with the real system
- How dependencies will impact your team’s work
- How downstream teams like marketing, operations, and finance will support the release
None of these is unusual. They’re the normal complexity of large initiatives. But discovering them as the deadline rapidly approaches snowballs into a project crisis.
Early learning is safe and cheap. Late emergence is risky and expensive.
The Real Fix
The answer isn’t better planning and requirements, more rigorous status tracking, or demanding better estimates from your teams.
The answer is getting to the complex parts sooner—on purpose. That means finding the minimum effective slice of a feature that will force the riskiest integrations to work and put the system in front of real users early enough to actually change the plan.
That’s what Feature Mining, a key move in our CAPED (Complexity-Aware Planning, Estimation, and Delivery) approach, reliably does. Feature Mining cuts through a big, complex initiative to find that first slice—the one that creates real learning about how the pieces fit together and how users will interact with the system, delivered weeks or months before you’d otherwise get there. Check out last week’s newsletter for real examples of Feature Mining doing that for several of our clients.
Go Deeper on April 14
If this pattern sounds familiar, our free webinar on April 14 goes deeper on how to break out of it. We’ll show how CAPED helps organizations stop deferring the key learning and start designing for earlier emergence. Register here.
And if you want to build this capability inside your organization, our Certified CAPED Consultant training runs May 19–22 in person.
Last updated