Why software projects fail before engineering starts

01 · The direct answer

Why software projects fail before engineering starts

Software projects often fail before engineering starts because the organization has not aligned on the problem, user, operating change, decision rights, success measure, or evidence needed to justify the solution. Engineering then receives scope that looks precise but rests on untested assumptions.

A detailed requirements list can hide fundamental disagreement. Discovery is successful when it reduces the uncertainty that matters, including the possibility that software is not the next useful move.

For two useful external lenses, compare How the discovery phase works from GOV.UK Service Manual with Product discovery from Silicon Valley Product Group. A public service standard for understanding users, constraints, existing services, and whether a project should proceed. A practitioner perspective on addressing value, usability, feasibility, and business viability risks before delivery.

The useful decision is the one your team can carry into daily work. Define the outcome, make ownership explicit, and choose the smallest next move that produces trustworthy evidence.

02 · A practical framework

Work through the decision in four parts.

The framework is strengthened by What is a product brief? and Using outcomes to guide product work. An outcome-oriented artifact for aligning the problem, audience, goals, evidence, and early scope. A useful distinction between shipping outputs and creating measurable business and product outcomes.

Write down the answers and the evidence behind them. A visible decision is easier to challenge, improve, and hand to the people responsible for delivery.

03 · Failure modes

Watch for the shortcuts that move risk downstream.

• 01

  Starting with a preferred solution and reverse-engineering the problem statement.

• 02

  Treating stakeholder consensus as evidence of user value.

• 03

  Handing requirements to engineering while the business decision-maker disappears.

The failure patterns are worth testing against Product discovery, product strategy, and empowered product teams and UX prototypes: low fidelity vs. high fidelity. A long-form conversation with Marty Cagan about discovery, strategy, and empowered product teams. How different prototype fidelities support different questions and stages of validation.

These problems rarely remain technical. They surface later as stalled adoption, operating workarounds, fragile ownership, or investment that cannot be tied to a business result.

04 · Decision checklist

Questions to take into the next working session.

• 01

  Can the team explain the problem without naming a feature?

• 02

  What evidence supports expected value?

• 03

  Which business process changes with the software?

• 04

  Who resolves tradeoffs during delivery?

• 05

  What finding would cause the project to stop?

Before committing, use Build versus buy and What is story mapping? to challenge the answers. A strategic framework for comparing third-party products with the total cost and responsibilities of building. A practical method for organizing work around the journey a user takes to complete a goal.