Why Projects Fail Before They Start: The Requirements Problem

Here's an uncomfortable truth that most project managers learn the hard way: by the time you realise a project is in trouble, the seeds of failure were often planted in the first few weeks.

The Standish Group's research consistently shows that incomplete requirements and lack of user involvement are among the top causes of project failure. Yet organisations continue to rush through requirements gathering, eager to start "real work."

The Requirements Iceberg

When stakeholders describe what they want, they typically share about 20% of the actual requirements. The rest sits beneath the surface:

• Assumed requirements — things so obvious to stakeholders they don't mention them
• Conflicting requirements — different stakeholders want different things
• Evolving requirements — needs that will emerge once they see the solution
• Implicit constraints — technical, regulatory, or organisational limitations

Your job isn't just to document what people say. It's to uncover what they haven't said.

Signs You're Heading for Trouble

Watch for these red flags during requirements gathering:

1. Everyone agrees too quickly

If stakeholders nod along without debate, they're probably not engaged. Real requirements discussions involve friction — different departments have different priorities, and surfacing those conflicts early is essential.

2. Requirements are solution-focused

"We need a SharePoint site" isn't a requirement — it's a solution. The requirement might be "we need a central place to share documents with external partners." One opens options; the other closes them.

3. No one can explain the "why"

If stakeholders can't articulate why they need something, you're documenting wishes, not requirements. Every requirement should trace back to a business objective.

4. Key stakeholders are "too busy"

If the people who'll use the system can't make time for requirements sessions, you're building for ghosts. Their absence now means surprises later.

A Better Approach

Start with problems, not solutions. Ask stakeholders:

• What's painful about how things work today?
• What would success look like in six months?
• Who else cares about this, and what do they need?
• What would make this project worthless to you?

That last question often reveals requirements no one thought to mention — the non-negotiables that only surface when explicitly asked.

Document for Reality, Not Formality

Requirements documentation should be a communication tool, not a compliance exercise. If your stakeholders won't read a 50-page requirements spec, write something they will read.

User stories, process flows, and prototypes often communicate requirements better than traditional documents. The format matters less than whether it creates shared understanding.

The Validation Test

Before declaring requirements "complete," ask:

• Can every requirement be tested?
• Do stakeholders agree on priority?
• Have we identified conflicts and resolved them?
• Can someone new understand what we're building and why?

If you can't answer yes to all four, you're not ready to proceed.