Most IT Projects Don’t Fail During the Build. They Fail Before It Starts.

Where the Failure Actually Starts

The pattern is almost always the same. Someone spots a problem, the inventory system is slow, the reporting is manual, the old CRM doesn’t talk to the website, and the instinct is to jump straight to solutions. A vendor gets a call. A demo gets booked. A few weeks later there’s a proposal on the table, and because it looks professional and the vendor sounds confident, it gets signed.

What’s missing is the step in between: actually understanding the problem before paying someone to fix it. Nobody sat down and asked what’s really broken, who it’s hurting, or what fixing it is actually worth. Nobody even agreed on what “done” would look like. The vendor built a solution to the problem as they understood it from a short call. That’s rarely the problem the business is actually carrying.

This shows up later in a few predictable ways: requirements keep “emerging” mid-project because nobody gathered them properly to begin with; the loudest stakeholder’s wish list becomes the scope, whether or not it matches what the business needs; nobody can say what success looks like, so nobody can say when the project is actually finished; the solution gets shaped around what the vendor is good at selling rather than what the problem actually requires; and budget and timeline got locked in before anyone knew enough to set them accurately.

None of this makes the vendor dishonest. A vendor can only build what they’re told to build, and if the scoping was thin going in, the project was always going to drift. The failure happens upstream, at the point where a business jumps from “we have a problem” straight to “here’s a solution” and skips the part that should sit between.

Why Discover, Plan, Execute Is a Sequence, Not a Slogan

Discover, Plan, Execute only works as an actual sequence, not a line on a slide. Skip a stage and nothing gets saved. The cost just moves further down the road, where it’s more expensive to fix.

Discover comes first, and it’s the stage most businesses rush through or skip entirely. It’s where the real problem gets defined, not guessed at: what’s actually costing the business money, which constraints are real, and which ones people just assumed were real. A proper discovery phase tends to turn up at least one surprise, a process nobody thought to mention, a dependency nobody flagged, someone who should have been in the room and wasn’t.

Planning is what turns that discovery into something you can actually act on. Requirements get ranked instead of just listed out. The timeline gets built around what’s realistic, not what everyone’s hoping for. And somewhere in this stage, the business has to agree on what success actually looks like, specific enough that everyone would recognize it the moment they saw it. A plan that can’t answer whether something is done yet isn’t really a plan.

Then comes execution, the part everyone’s itching to get to, and the part that goes easiest when the first two stages were actually done properly. Less drift, because what’s being built is what was actually needed. Less re-scoping, because the scope came from real information instead of a guess. And when something unexpected turns up mid-build, because it always does, there’s something solid to check it against instead of a target that keeps sliding around.

This is why we don’t take on a technology project without running a proper discovery phase first, no matter how confident the client already is going in, and why the evaluation that follows looks at what fits the business rather than what’s easiest to sell. There’s no vendor paying for that recommendation, so it holds up regardless of which platform the business ends up choosing.

What a Properly Sequenced Project Looks Like

A project run this way looks almost boring from the outside, which is kind of the point. The team knows what they’re building and why. Requirements don’t shift every other week, because they were gathered properly instead of guessed at. By the time the project wraps, there’s a straight answer to whether it actually solved the problem, not just whether the system shipped on schedule.

Skipping straight to execution isn’t usually carelessness. It’s a business in a hurry, staring at something that already looks like a solution, with discovery feeling like the thing standing in the way of it. Most businesses only make that mistake once.