The call comes at 11 PM on a Sunday. A client's VP of Engineering, voice tight with stress: "We're eight months into a twelve-month platform migration. We've spent $4 million of a $6 million budget. And we just realized the new system won't handle our transaction volume."
This is the moment where most consulting engagements focus on damage control. How do we optimize the new platform? Can we add capacity? Should we extend the timeline and increase the budget?
These are the wrong questions.
The right question is: What problem were we actually trying to solve, and does this migration solve it?
That question—asked eight months too late—revealed that the migration was solving a problem that no longer existed. The original justification was scaling limitations in the legacy system. But in the two years between initial planning and project kickoff, the legacy vendor had released updates that solved those limitations. The migration had become an institutional commitment divorced from business reality.
The project was cancelled. The $4 million was written off. The legacy system, with some relatively minor upgrades, handled their growth for the next three years.
This is first principles thinking in crisis mode: the willingness to question everything, even sunk costs and institutional momentum.
The Failure Spiral
High-stakes projects fail in predictable patterns. They start with ambitious goals and reasonable plans. Then reality intrudes—technical complications, scope creep, changing requirements, vendor issues, key personnel departures.
The response is almost always incremental adjustment. Add resources. Extend timelines. Adjust scope. Bring in specialists. These interventions sometimes work for minor deviations. But when a project is fundamentally off track, incremental fixes create a spiral:
- Added resources increase coordination overhead
- Extended timelines allow requirements to drift further
- Adjusted scope creates inconsistencies in design
- Specialists optimize local components while the system as a whole deteriorates
A healthcare company came to us eighteen months into a three-year digital patient experience platform. The project had:
- Tripled the original budget
- Expanded from 14 to 43 team members
- Gone through four project managers
- Missed every major milestone by 3-6 months
- Generated exactly zero production deployments
The organization's response had been classic spiral management: more people, more process, more oversight, more vendor escalations. The status reports were novels. The org chart was Byzantine. And the project was dying.
The First Principles Audit
We spent the first week not looking at project plans or technical architectures. We interviewed patients, front-desk staff, nurses, and physicians. We asked a simple question: What actually needs to be better?
The answers were remarkably consistent and remarkably modest:
- "I need to be able to message my doctor without playing phone tag."
- "I need to know when I have appointments without digging through paperwork."
- "I need my test results explained in language I can understand."
- "I need prescription refills to not take three days."
The eighteen-month, tens-of-millions-of-dollars platform they were building? It would eventually do all of those things. It would also do 200 other things that nobody asked for and nobody needed.
We went back to first principles:
What is the fundamental need? Reduce friction in patient-provider communication.
What is the minimum viable solution? A secure messaging system with appointment reminders and results notifications.
What is the core technical challenge? Integration with existing EMR systems and compliance with HIPAA security requirements.
What are we assuming that might not be true? That we need to build a comprehensive platform rather than targeted solutions. That all patient interactions need to flow through a single system. That we need feature parity with consumer apps.
That last assumption was killing them. The requirements document compared their platform to Uber, Amazon, and banking apps. But patients aren't ordering rides or products. They're navigating healthcare—a fundamentally different mental model and usage pattern.
The Rebuild Decision
First principles thinking in crisis leads to three possible outcomes:
Optimize: The project is fundamentally sound but execution has drifted. Streamline, refocus, and continue.
Pivot: The goal is right but the approach is wrong. Change strategy while preserving the objective.
Abandon: The premise is flawed. Cut losses and either restart from scratch or solve the problem differently.
The hardest part isn't the analysis—it's the organizational courage to act on it. Sunk cost fallacy is powerful. Political capital is invested. Careers are attached to outcomes.
The healthcare platform got a pivot decision. We carved out the messaging, appointments, and results notification functions into a standalone application. Everything else—the patient portal redesign, the billing integration, the insurance verification features—went into a backlog for future consideration.
They deployed the stripped-down version in eight weeks. Patient adoption hit 40% in the first three months. Provider satisfaction improved measurably. The project that was drowning in complexity became a success by doing less.
Pattern Recognition
After salvaging dozens of failing projects, we've identified recurring patterns that signal when first principles questioning is needed:
The solution is bigger than the problem. If your implementation has orders of magnitude more complexity than the issue it's addressing, something has gone wrong. Often what happens is "while we're at it" scope expansion. "While we're rebuilding the inventory system, let's also modernize purchasing and integrate with accounting." Each addition seems logical in isolation but compounds risk geometrically.
Nobody can articulate why anymore. Ask ten team members why the project exists and you get ten different answers. This signals that the original vision has fragmented into contradictory goals.
A financial services firm was building a "next-generation trading platform." When we asked why, we got:
- "To reduce infrastructure costs" (IT)
- "To enable new product types" (Product)
- "To meet regulatory requirements" (Compliance)
- "To improve trader productivity" (Trading desk)
These are fundamentally different objectives that require different technical approaches. The platform was trying to be all things and succeeding at none.
The original assumptions are out of date. Technology changes, markets change, competitors change, regulations change. A project conceived two years ago is executing against a reality that no longer exists.
A retail client was building an inventory optimization system based on 2019 assumptions about customer behavior. Then COVID hit. Buying patterns fundamentally changed. Store traffic collapsed. E-commerce exploded. But the project continued building for the old world because the requirements were locked and changing them felt like failure.
By the time they brought us in, they had a sophisticated system optimized for a business model that no longer existed.
The Turnaround Protocol
When we're brought in to salvage a failing project, we follow a consistent protocol:
Week 1: First Principles Immersion
Ignore the project entirely. Talk to the people who will benefit from success and suffer from failure. What do they actually need? How do they work today? What are the real pain points, not the ones in the business case?
Document assumptions. Every project is built on assumptions about user behavior, technical capabilities, market conditions, and organizational readiness. Make them explicit and test them against current reality.
Week 2: Constraint Mapping
What can't change? Regulatory requirements, budget ceilings, deadline commitments, technical dependencies. These are your immovable objects. Everything else is negotiable.
A manufacturing client had committed to regulatory agencies that their new quality control system would be operational by a specific date. That constraint was real—missing it meant losing certifications and shutting down production.
Everything else—features, scope, team size, vendor selection—could flex. Knowing that one immovable constraint clarified every other decision.
Week 3: Minimum Viable Success
Define the smallest thing that would constitute success. Not the aspirational vision, not the comprehensive solution—the minimum that solves the core problem.
This is psychologically difficult for organizations. It feels like giving up on ambition. But it's the opposite—it's choosing to deliver something real over continuing to pursue something impossible.
Week 4: Decision Point
Present three options, always:
- Continue: Project is sound, needs execution fixes
- Pivot: Change approach, preserve core objective
- Stop: Cut losses, solve differently or not at all
Include honest cost and risk assessment for each. The continue option is almost never "just keep going." It's "here's what has to change fundamentally about how this project operates."
The Political Reality
First principles thinking in crisis is technically straightforward and politically brutal. Projects accumulate stakeholders, interests, and political capital. Questioning fundamentals threatens people's credibility and decision-making.
We've learned to navigate this carefully:
Frame as learning, not failure. "We've learned things during execution that change the optimal approach" is easier to accept than "we were wrong from the beginning."
Provide face-saving pivots. If the project needs to be killed, find ways to preserve the valuable components and credit the team for those contributions.
Show the counterfactual. Model what continuing the current trajectory looks like versus the alternative. When leadership sees that "success" on the current path means delivering something obsolete or unusable, stopping becomes rational.
A telecommunications company had a network management platform that was two years late and 3x over budget. Leadership was considering killing it, which would mean writing off $40 million and explaining it to the board.
We modeled the completion scenario: another 18 months, another $30 million, to deliver a system that would be technologically outdated on day one and would require replacement within three years.
Total cost: $70 million for three years of use.
Alternative: License a modern SaaS platform for $8 million/year, customize it for their needs for $5 million, deploy in six months.
Total cost: $29 million for three years, with ongoing improvement and no technical debt.
The project was cancelled. The $40 million was written off. But the decision was easy once the counterfactual was clear.
The Discipline of First Principles
The most important lesson from salvaging failing projects: first principles thinking is a discipline, not a one-time intervention.
The projects that end up in crisis are the ones where assumptions went unquestioned for too long. Requirements got locked down before they were validated. Technical approaches were chosen before the problem was fully understood. Momentum became more important than learning.
High-performing organizations build first principles review into their project governance:
Quarterly assumption audits: Are the assumptions we built this on still true?
Milestone reality checks: Does what we've built actually solve the problem we intended to solve?
User truth sessions: Put real users in front of real features and watch what happens, without prompting or explanation.
These practices feel like overhead when projects are going well. But they're the immune system that prevents small misalignments from becoming catastrophic failures.
The Courage to Question
The hardest part of first principles thinking in crisis isn't intellectual—it's emotional. It requires admitting that time and money and effort might have been spent pursuing the wrong thing.
But the alternative is worse. Delivering something that doesn't solve the problem, that won't be used, that creates new problems while claiming to solve old ones.
The most successful project salvages we've done all had a moment where someone senior had the courage to say: "We need to question everything, including whether we should continue at all."
That moment of radical questioning is uncomfortable. It's also the only way to turn a failing project into something valuable.
Because the sunk cost is already spent. The only question that matters is: what do we do from here?