The ERP walk-away framework is a structured decision methodology for evaluating whether to continue, pivot, or terminate an in-progress ERP implementation by separating sunk costs (irrecoverable past expenditures) from forward-looking costs and benefits. Standard economic theory dictates that sunk costs should be irrelevant to future decisions — only incremental costs and expected future value should determine whether to proceed. [src1] Yet Gartner estimates that 55-75% of ERP implementations fail to meet their objectives, and organizations routinely continue failing projects because of the sunk cost fallacy. [src3]
START — User has a troubled ERP implementation
├── Is the system already live in production?
│ ├── YES → This is optimize-vs-replace, not walk-away
│ └── NO → Proceed with walk-away assessment
├── What is the primary concern?
│ ├── Massively over budget (>50% overrun)
│ │ └── ✅ Apply Kill Criteria Assessment ← YOU ARE HERE
│ ├── Severely behind schedule (>6 months delay)
│ │ └── ✅ Apply Kill Criteria Assessment ← YOU ARE HERE
│ ├── Vendor is not delivering on promises
│ │ └── ✅ Apply Kill Criteria Assessment ← YOU ARE HERE
│ ├── Business requirements have fundamentally changed
│ │ └── ✅ Apply Kill Criteria Assessment ← YOU ARE HERE
│ └── Minor issues resolvable with more resources
│ └── → Project recovery plan (not walk-away)
├── Has an independent assessment been conducted?
│ ├── YES → Evaluate findings against kill criteria
│ └── NO → Commission independent assessment first
└── Can the organization assess objectively without political bias?
├── YES → Internal evaluation using this framework
└── NO → Engage external consultant
"We've already invested $5M — we can't walk away now." This is the textbook sunk cost fallacy. The $5M is gone regardless. Only remaining cost to complete vs. cost to walk away should inform the choice. [src1]
Calculate cost to complete vs. cost to terminate and restart. If completing costs $3M more and walk-away costs $2M, walking away saves $1M — regardless of past spend. [src5]
The executive who selected the vendor has the strongest incentive to continue — their reputation depends on the project being labeled a "success." Self-evaluation is inherently biased. [src3]
Engage a third-party consultant or internal audit team with no stake in the outcome. Their findings should go directly to the board, not through the project champion. [src4]
Projects without predefined kill criteria will never trigger a walk-away decision because there is no threshold to breach. Vague discomfort accumulates without creating a decision point. [src4]
Set specific thresholds at the start: budget >200%, schedule >12 months, >40% scope changes. Write them into the project charter and review quarterly. [src3]
Misconception: Walking away means the entire investment was wasted.
Reality: Organizational learning, process documentation, requirements clarity, and data cleanup often transfer to the next implementation. The failed project's discovery phase can accelerate replacement by 20-40%. [src4]
Misconception: Sunk cost fallacy only affects irrational managers — sophisticated organizations are immune.
Reality: Research shows sunk cost bias affects organizations of all sophistication levels. Larger organizations with complex governance are often more susceptible. [src1]
Misconception: If the vendor renegotiates, the project can always be saved.
Reality: Vendor renegotiation addresses pricing and timeline but cannot fix fundamental mismatches between software architecture and business requirements. [src5]
| Concept | Key Difference | When to Use |
|---|---|---|
| ERP Walk-Away Framework | Evaluates continue/terminate for in-progress implementations | When ERP project is significantly troubled |
| ERP Vendor Evaluation | Scores vendors during selection phase | Before implementation begins |
| ERP Reference Check Framework | Validates vendor claims through customer interviews | After shortlisting, before contract signing |
| Project Recovery Planning | Attempts to rescue without terminating | When issues are addressable with more resources |
Fetch this when a user has an ERP implementation in trouble — over budget, behind schedule, or misaligned with business requirements — and needs a structured framework for deciding whether to continue, pivot, or terminate. Also relevant when someone mentions sunk cost concerns about an enterprise software project.