Diagnosing Failed Prior Initiatives: Learn Why the Last Project Stalled Without Making Anyone Defensive

If the problem you are discussing is worth solving, the prospect has probably tried before. An internal build was started and quietly abandoned. A previous vendor was selected, deployed and never adopted. Whatever happened, the people in the room remember it, and some of them were responsible for it. If you do not understand why it failed, you will be judged against it without knowing the rules.

Diagnosing failed prior initiatives is the discovery skill of exploring why previous internal builds or vendor implementations stalled, without making the prospect defensive. Done well, it tells you exactly which risks your proposal must address and earns trust because you asked.

The problem it solves

• The need: buyers carry hidden objections from past failures, and those objections surface late if they are not discussed early.
• Who faces it: SEs in discovery with organisations that have tried and failed to solve the same problem.
• Stage: discovery and qualification, once the problem is agreed and before solution design.
• Decision it supports: which risks to design out, which stakeholders carry scar tissue, and whether the conditions for success exist now.
• Success looks like: a clear, blame-free account of what went wrong, and an agreed answer to “what would need to be different this time?”

Why this conversation is delicate

Someone sponsored the previous initiative. Someone built it or chose the vendor. They may be in the meeting. Questions that sound like “what went wrong?” can feel like “who got it wrong?” The skill is in framing the past as a source of lessons, not a search for fault.

A blame-free sequence

1. Acknowledge, do not assume. “Many organisations have tried to tackle this before. Has your team looked at it in the past?”
2. Start with what worked. “What did that effort get right?” People open up when their earlier work is respected.
3. Ask about conditions, not people. “What changed during the project: priorities, budget, people, scope?” Most failures are about conditions.
4. Ask about the moment it stalled. “When did it become clear it would not continue?” The answer usually names the real cause.
5. Ask what must be different now. “If we were to try again, what would need to be true this time?” Their answer is your list of requirements for success.

Common root causes to listen for

• Scope expanded until the effort could not finish.
• The users who had to adopt it were not involved in shaping it.
• A hidden integration or data dependency was discovered too late.
• The sponsor left, and nobody else owned the outcome.
• Success was never defined, so nobody could declare it.

Each cause points to a specific action you can take: tighter scope, early user involvement, deeper integration discovery, multi-threading, and explicit success criteria.

Adjusting to the situation

• A skeptical engineering VP: if their team built the last attempt, credit the constraints they worked under before asking what they would change.
• A prospect burned by unused software: adoption is the scar. Ask what the users did instead of using it, and make adoption evidence part of your plan.
• A competitive displacement against an entrenched incumbent: ask what the incumbent was originally chosen to solve and what it never delivered, without criticising the vendor.
• An inherited late-stage deal: ask the account team what was already said about past failures before raising the topic again with the buyer.
• A merger scenario: each organisation may have its own failed attempt; ask both sides separately.

Common mistakes

• Criticising the previous vendor or internal team. It makes the buyer defend their past decision.
• Assuming your product avoids the failure automatically. Most failures were not about product features.
• Hearing the lesson and not changing the plan.

How you know it worked

• You can state the main reason the last initiative stalled, in the prospect’s words.
• Your proposal or evaluation plan addresses that reason explicitly.
• The people involved last time are now supporting, not resisting, the new effort.

Where this skill sits in the deal

Upstream: current-state workflow mapping shows what was left behind by the last attempt. Parallel: root-cause objection isolation handles the doubts the past failure creates. Downstream: the lessons shape success criteria, scope and the mutual action plan.

Practice it before the live call

Talking about failure without blame is one of the most transferable skills an SE can build: part of the 80% of Solution Engineering. SE Ignite teaches discovery conversations like this as free, tech-agnostic micro-skills you can rehearse safely before using them with a buyer.