Project Rescue

Software projects fail in predictable patterns. What starts as optimistic planning ("we'll launch in 6 months for £200k") deteriorates into a nightmare of missed deadlines, scope creep, budget overruns, technical problems, team conflict, and mutual blame between client and vendor. By the time organizations seek help, they've often sunk £300k-£800k into a project that's 60% complete, 18 months behind schedule, and fundamentally broken.

According to the Standish Group's 2025 CHAOS Report, 31% of software projects are cancelled before completion, and 52% are "challenged" — delivered late, over budget, or with significantly reduced functionality. The average cost overrun for challenged projects is 189% of the original budget. For a £300,000 project, that means an actual cost of £867,000 — if it completes at all.

Project failure rarely happens suddenly. It's a gradual accumulation of problems: unclear or changing requirements, poor architectural decisions made early and compounded, inadequate testing leading to mounting technical debt, communication breakdown between stakeholders and development team, vendor capability mismatch (promised expertise not delivered), unrealistic estimates and aggressive timelines, and missing project governance and quality gates.

By the time failure is acknowledged, emotions run high, trust has evaporated, and rational decision-making is difficult. Should you continue with the current vendor? Start over with someone new? Salvage what exists or rebuild from scratch? How much will recovery actually cost? Can you trust any estimate after being burned once?

Project rescue services provide independent, objective assessment and intervention — identifying what's salvageable, what must be rebuilt, quantifying realistic completion costs and timelines, and either stabilizing the existing project or managing an orderly transition to recovery.

Why software projects fail (and when rescue is needed)

1. Technical debt accumulation makes progress impossible

The scenario: Property management software is 14 months into an 8-month project. Initial velocity was strong — first 3 months delivered visible features. Then progress slowed dramatically. New features that should take days are taking weeks. Bug fix creates two new bugs. Developers constantly fighting mysterious issues. The team reports "technical debt" but management doesn't understand the severity. Eventually progress effectively stops — the last feature took 7 weeks to deliver and still has major bugs.

Investigation reveals: No automated testing (test coverage 0%), so every change risks breaking existing functionality. Developers spend 60% of time debugging regressions. 12,000 lines of duplicated code copied-and-pasted across the application. Database design fundamentally flawed — missing foreign key constraints, no indexing strategy, schema doesn't match business logic. Code complexity averaging 38 (maintainable code: <10), making any modification time-consuming and error-prone. No code review process — each developer wrote code in completely different styles.

The cost: £420,000 spent (original budget £180,000), project 65% complete after 14 months (planned 8 months), current burn rate £30,000/month with minimal forward progress, technical debt so severe that realistic options are: (1) continue struggling (estimated £180,000+ more, 12+ months, uncertain outcome), (2) major refactoring (£140,000, 6 months pause in feature development), or (3) rebuild critical modules from scratch (£220,000, 8 months).

When rescue is needed: When velocity collapses despite team working full-time. When bug fixes create more bugs. When estimates become wildly inaccurate because no one understands the codebase complexity. When developers openly say "we need to rebuild this."

2. Vendor capability gap destroys client confidence

The scenario: Financial services company contracts development agency to build trading platform based on impressive portfolio and strong sales presentation. Six months in, the platform is fundamentally broken: data synchronization fails regularly causing pricing discrepancies, performance is unusable (12-second page loads, 40-second API responses), security audit reveals critical vulnerabilities (SQL injection, authentication bypass), and delivered code quality is amateur (no error handling, hardcoded credentials, no logging). Client reviews code and discovers agency outsourced to offshore team with no relevant experience.

The trust breakdown: Client loses confidence in vendor's capability but is £280,000 invested with partially completed platform. Vendor insists issues are minor and "nearly ready for production." Client knows platform is nowhere near production-ready. Communication deteriorates into defensive arguments. Client faces choice: continue with vendor hoping for improvement, fire vendor and lose £280k investment, or bring in rescue team for independent assessment.

The cost: £280,000 spent on fundamentally flawed platform, 8 months behind schedule (planned 12-month project now 20 months with no production launch), business opportunity window closing (competitor launching similar product in 3 months), team morale destroyed by constant disappointment and broken promises, and contractual dispute brewing (vendor claims 80% complete, client assessment: 40% complete and what exists must be rebuilt).

When rescue is needed: When you've lost confidence in vendor's capability. When delivered code quality is far below professional standards. When vendor repeatedly misses deadlines and makes excuses. When you suspect fundamental competency gap but aren't technical enough to assess objectively.

3. Scope creep and requirement changes derail project

The scenario: E-learning platform project starts with clear 6-month scope and £150,000 budget. During development, stakeholders repeatedly request changes: "can we add live video streaming?", "actually we need mobile apps not just responsive web", "we should integrate with our existing CRM", "users should be able to create courses not just consume them." Each request seems reasonable in isolation. Developer raises concerns but stakeholders insist changes are essential. No formal change control process. Twelve months later: budget exhausted, project 55% complete, team demoralized, and original launch deadline missed by 6 months with no end in sight.

The scope creep impact: Original scope: 40 features across 8 modules. Current scope: 87 features across 14 modules (118% scope increase). Original budget: £150,000. Spent to date: £240,000 (60% over budget). Original timeline: 6 months. Current timeline: 12 months elapsed, estimated 6 months remaining (200% timeline overrun). Developer blames client for constant changes. Client blames developer for not flagging budget/timeline impact clearly. Project governance completely absent — no change request process, no impact analysis for requested changes, no stakeholder signoff on revised scope/budget.

The cost: £240,000 spent (£90,000 over original budget), project only 55% complete, team exhausted and considering quitting, business case no longer valid (market conditions changed during delay, competitor launched similar platform), and relationship between client and vendor toxic with mutual blame.

When rescue is needed: When scope has grown significantly beyond original plan with no corresponding budget/timeline adjustment. When project has no effective change control process. When team is demoralized by constantly moving goalposts. When budget is exhausted but project far from complete.

4. Poor architecture creates unfixable scalability problems

The scenario: SaaS company launches successfully with MVP supporting 200 users. As growth reaches 2,000 users, performance degrades severely. At 5,000 users, platform becomes nearly unusable — 8-15 second page loads, API timeouts, database crashes multiple times daily. Development team attempts optimizations but each fix helps marginally while uncovering deeper architectural problems. Database design doesn't support required queries efficiently. Application architecture assumed single server (no horizontal scaling capability). No caching strategy. Session state stored in-process (can't load balance across multiple servers).

The architectural crisis: Platform experiencing rapid growth (200 → 5,000 users in 6 months, target 25,000 in 12 months), but architecture cannot scale beyond current load. Options considered: (1) Vertical scaling (bigger servers) — diminishing returns, cost prohibitive at scale (£12,000/month vs current £2,400/month, only supports 8,000 users max). (2) Optimization attempts (database indexes, query optimization, code-level improvements) — team has tried for 3 months, achieved 15% improvement, nowhere near enough. (3) Architectural refactoring — enable horizontal scaling, implement caching, redesign database schema — estimated £180,000, 6 months, high risk of introducing bugs.

The business impact: Customer churn accelerating due to performance issues (9% monthly churn vs 3% pre-performance crisis), unable to onboard new customers (sales paused due to platform instability), investor concerns (Series A funding round jeopardized by technical problems), and team spending 100% of time firefighting vs building new features.

When rescue is needed: When you hit fundamental scaling limits that can't be solved by simple optimization. When architectural decisions made in MVP phase prevent growth. When the cost of continuing with current architecture exceeds cost of major refactoring or rebuild.

5. Project becomes "zombie" — not cancelled but not progressing

The scenario: Legal practice management software is 22 months into development. Originally planned 12-month, £240,000 project. Client has spent £440,000. Software is 80% complete but has been "80% complete" for 6 months. Remaining 20% includes complex features (matter costing, multi-office accounting, integration with court filing systems) that are proving much harder than anticipated. Developer continues working at reduced pace, delivering small fixes and minor features, but major features remain incomplete. Client reluctant to cancel (too much invested) but frustrated with lack of progress. Project has become a zombie — not alive but not dead.

The stagnation: Monthly burn rate: £18,000 for minimal visible progress, latest estimate to complete: "4-6 months" (same estimate given 6 months ago), developer morale low (original team members left, replaced by less experienced juniors), client relationship strained but functional (no open conflict but no trust), business impact: law firm staff still using old manual processes (opportunity cost of delayed efficiency gains), and project governance: weekly status calls that report "good progress" with little evidence.

The hidden costs: Direct costs: £440,000 spent vs £240,000 budget (83% overrun). Opportunity cost: staff continue using inefficient manual processes costing estimated £8,000/month in lost productivity (£176,000 opportunity cost over 22 months). Morale cost: staff frustrated by promised system that never arrives, senior lawyers questioning technology leadership decision. Alternative cost: a fresh start with new vendor would cost £180,000 and 9 months, meaning continuing with failing project for 6 more months costs £108,000 — nearly 60% of complete rebuild cost.

When rescue is needed: When project is perpetually "almost done" but never finishes. When team is still working but not delivering meaningful progress. When you're unsure whether to persist or cut losses. When opportunity cost of delay exceeds cost of alternative approaches.

Core project rescue services

1. Independent project assessment and health check

Objective, comprehensive evaluation of project status, technical quality, team capability, and realistic path forward. Independent assessment by senior engineers with no vested interest in defending previous decisions or vendor relationships. Provides leadership with accurate information to make informed decisions.

Assessment scope: Project status audit (actual completion vs reported completion, quality of delivered work, technical debt quantification), codebase review (architecture assessment, code quality metrics, security vulnerabilities, maintainability analysis), requirement analysis (original scope vs current scope, scope creep quantification, requirement clarity and completeness), team capability evaluation (skill match to project needs, team morale and dynamics, vendor competency assessment), financial analysis (budget spent vs value delivered, realistic cost to complete, sunk cost vs prospective cost analysis), and timeline evaluation (realistic completion timeline, critical path analysis, resource constraints).

Assessment deliverables: Executive summary (non-technical, decision-focused, 3-5 pages), detailed technical assessment report (architecture, code quality, security, technical debt with evidence), financial analysis (cost to date, realistic completion costs for multiple scenarios), risk assessment matrix (technical risks, team risks, timeline risks, business risks), recommendations with options (continue/remediate/rebuild/replace) with pros/cons and cost-benefit analysis, and vendor performance evaluation (if applicable).

Typical timeline: 2-3 weeks for comprehensive assessment, 1 week for rapid triage assessment.

2. Project stabilization and immediate remediation

Emergency intervention to stop the bleeding — addressing critical issues, establishing basic project governance, and creating stable foundation for recovery. Focus on immediate problems that are causing the most pain or risk.

Stabilization activities: Critical bug triage and fixing (address show-stopper issues blocking progress), security vulnerability remediation (fix critical security holes identified in assessment), basic testing implementation (establish automated tests for critical paths to prevent regressions), technical debt quick wins (address highest-impact technical debt items with reasonable effort), infrastructure stabilization (fix reliability issues causing downtime or data loss), and team restructuring if needed (replace ineffective team members, add missing expertise, establish clear roles and responsibilities).

Governance establishment: Project steering committee (establish decision-making authority and meeting cadence), change control process (formal process for scope changes with impact analysis), status reporting (honest, evidence-based reporting with clear metrics), risk register (identify, track, and mitigate project risks), and quality gates (establish acceptance criteria and definition of done).

Stabilization outcomes: Stopping the downward spiral (preventing further degradation), establishing accurate visibility (knowing actual status, not reported status), creating foundation for recovery (basic quality processes, testing, governance), and rebuilding trust through transparency and accountability.

3. Recovery roadmap and execution

Detailed plan to complete the project or transition to alternative approach, with realistic timelines, costs, and milestones. Recovery execution under our management or in advisory capacity supporting client's chosen approach.

Recovery options analysis:

Option A: Remediate and continue — Fix critical technical debt, improve code quality, establish proper processes, complete remaining features. Best when: 60-80%+ genuinely complete, core architecture is sound, team is capable but processes were lacking. Typical cost: 40-80% of remaining budget estimate, timeline: 60-120% of remaining timeline estimate.

Option B: Partial rebuild — Salvage working components, rebuild problematic modules from scratch, establish proper architecture. Best when: 40-60% genuinely complete, some components are solid while others are fundamentally flawed, timeline pressure isn't severe. Typical cost: 50-120% of remaining budget estimate, timeline: 80-150% of remaining timeline estimate.

Option C: Complete rebuild — Start fresh with lessons learned, proper planning, and experienced team. Best when: <40% genuinely complete or delivered work is unsalvageable, fundamental architectural problems, faster and cheaper than trying to fix existing codebase. Typical cost: 60-90% of full project cost (benefit from clarified requirements and lessons learned), timeline: 70-85% of original timeline.

Option D: Replace with COTS — Abandon custom development, implement commercial off-the-shelf software with configuration. Best when: custom development not essential, acceptable COTS alternatives exist, time-to-market critical. Typical cost: 30-60% of custom development cost, timeline: 40-60% of custom development timeline.

Recovery execution: Detailed project plan (features, timeline, milestones, resource allocation), risk mitigation strategy (addressing known risks from failed attempt), quality assurance process (automated testing, code review, acceptance testing), communication plan (stakeholder reporting, transparency, expectation management), and delivery management (agile sprints, regular demos, iterative delivery).

4. Vendor transition and knowledge transfer

Managing transition from failing vendor to recovery team (our team or client's chosen replacement), ensuring knowledge preservation and continuity. Critical for minimizing disruption and preventing knowledge loss.

Transition activities: Knowledge extraction from outgoing vendor (architecture documentation, code walkthrough, infrastructure documentation, requirement documentation), intellectual property and access transfer (source code, credentials, cloud accounts, domain registrations), legal and contractual management (coordinating with legal counsel on vendor termination, managing handover obligations, ensuring clean separation), environment setup for new team (access provisioning, development environment setup, CI/CD pipeline establishment), and stakeholder communication (managing messaging to internal teams, customers, and other vendors/partners).

Knowledge preservation: Architecture documentation (creating documentation if none exists), code and database documentation (explaining business logic, data models, integration points), operational runbooks (deployment procedures, troubleshooting guides, incident response), requirements documentation (formalizing requirements for incomplete features), and decision rationale (documenting why choices were made, what was tried that failed).

Transition timeline: Typical vendor transition: 3-6 weeks depending on project complexity and vendor cooperation level.

5. Post-rescue project delivery and support

After stabilization and recovery planning, delivering the completed project to production, or providing ongoing support to ensure rescued project succeeds long-term.

Delivery phase: Completing remaining features (following revised scope and timeline), quality assurance (comprehensive testing, user acceptance testing), deployment to production (phased rollout, monitoring, support), training and documentation (user training, administrator training, comprehensive documentation), and warranty period (post-launch support, bug fixes, stabilization).

Post-delivery support: Ongoing maintenance (bug fixes, security patching, minor enhancements), performance monitoring (proactive issue detection), infrastructure management (if applicable), team augmentation (supplementing client's internal team), and technology advisory (guidance on future development, architecture evolution).

Our project rescue approach

Phase 1: Emergency assessment (Week 1-3)

Rapid but thorough assessment to understand actual project status, problems, and options. Provides executive leadership with accurate information to make decisions.

Activities: Stakeholder interviews (client leadership, project team, users, vendor if still engaged), codebase and architecture review (automated analysis, manual review by senior engineers), financial and timeline analysis (spend to date, realistic completion costs), requirement documentation review (scope, changes, gaps), risk assessment (technical, team, timeline, business risks), and scenario analysis (remediate vs rebuild vs replace with cost-benefit analysis).

Deliverables: Executive summary report (decision-focused, non-technical), detailed assessment report (technical findings with evidence), financial analysis (spend vs value, completion costs by scenario), risk assessment matrix, recommendations (preferred approach with rationale), and presentation to leadership (findings, options, recommendations, Q&A).

Phase 2: Stabilization and planning (Week 3-6)

If decision is to rescue rather than abandon, we immediately stabilize critical issues while developing detailed recovery plan.

Stabilization: Fix critical bugs and security vulnerabilities, implement basic automated testing for critical paths, establish project governance (steering committee, change control, reporting), address immediate technical debt causing most pain, and rebuild team trust through transparency and quick wins.

Planning: Detailed recovery project plan (features, timeline, milestones, resources), risk mitigation strategy, quality assurance process definition, vendor transition plan (if changing vendors), and stakeholder communication strategy.

Deliverables: Stabilized project with stopped deterioration, recovery project plan with realistic timeline and budget, risk register and mitigation plan, governance processes established, and team aligned on path forward.

Phase 3: Recovery execution (Month 2-9 typical)

Executing the recovery plan — whether that's remediating existing codebase, partially rebuilding, or completely rebuilding. Regular communication, transparency about status, and iterative delivery.

Execution approach: Agile methodology with 2-week sprints, regular demos showing working software (not just status reports), continuous automated testing (preventing regressions), code review and quality gates (ensuring quality this time), and transparent reporting (actual status, risks, issues, not optimistic fiction).

Communication: Weekly status reports to steering committee, bi-weekly demos to stakeholders, monthly detailed progress review with financial reconciliation, immediate escalation of issues or risks, and monthly stakeholder survey (measuring confidence and satisfaction).

Quality focus: Automated testing (aiming for 70-80% code coverage), code review (all code reviewed before merge), security scanning (automated vulnerability detection), performance testing (load testing before production), and user acceptance testing (involving actual users in testing).

Phase 4: Delivery and transition (Final 1-2 months)

Final push to production, deployment, training, and handover to ongoing support team (client internal team, managed service, or ongoing engagement with us).

Final activities: User acceptance testing and feedback incorporation, production deployment with phased rollout, monitoring and support during initial production period, comprehensive documentation (user, administrator, technical), training delivery (end users, administrators, technical staff), warranty period (30-90 days post-launch bug fixing and stabilization), and handover to support team (knowledge transfer, operational runbooks, support procedures).

Success criteria: Application in production serving users, defined functionality delivered and working, performance and reliability meeting targets, users trained and able to use system, documentation complete and maintained, and support arrangements in place for ongoing maintenance.

Case studies: Successful project rescues

Case study 1: Healthcare patient portal rescue — saved £380k investment

Client: Private healthcare provider, 8 clinics, 32,000 patients

Failure scenario: 18 months and £520,000 into custom patient portal development (original budget £180,000, original timeline 9 months). Project with original vendor was failing catastrophically:

Delivered application was fundamentally broken — critical features (appointment booking, prescription requests, secure messaging) either didn't work or had major bugs. Security vulnerabilities were severe — SQL injection, exposed patient data, no encryption at rest. Performance was unusable — 12-18 second page loads, frequent timeouts and crashes. GDPR compliance was completely absent — no data protection impact assessment, no consent management, no right to erasure implementation. Vendor relationship had collapsed — vendor claiming 85% complete, client assessment: 30% complete and what exists is unsalvageable.

Client considering abandoning the project entirely, writing off £520,000, and starting fresh with new vendor (estimated £240,000, 12 months).

Our rescue engagement: Conducted 3-week emergency assessment revealing: approximately 35% genuinely complete with usable quality, core architecture was actually sound despite poor implementation, database design was good, most problems were code-quality and security issues rather than fundamental architectural flaws, and estimated rescue cost: £180,000 over 6 months vs £240,000 for complete rebuild over 12 months.

Recommendation: Rescue and remediate rather than rebuild. Why: Core architecture and database design were solid. Problems were fixable (security vulnerabilities, code quality, performance optimization) rather than fundamental. 35% genuinely complete represented £180,000+ of salvageable value. Rescue timeline 6 months vs 12 months to rebuild (6-month faster time-to-value).

Rescue execution: Fixed all critical security vulnerabilities (2 weeks emergency sprint), implemented comprehensive automated testing (achieved 78% coverage), refactored code for performance (page loads 12-18s → 1.2s average), completed remaining features (appointment booking, prescriptions, secure messaging, lab results, billing), achieved GDPR compliance (DPIA, consent management, data subject rights), achieved CQC compliance for digital patient services, and delivered full documentation and training.

Results: Project rescued and delivered in 7 months (including 3-week assessment), total cost: £180,000 rescue + £520,000 previous investment = £700,000 total vs £760,000 for complete rebuild (£60,000 savings), time-to-market: 7 months vs 12 months rebuild (5 months earlier revenue realization), application successfully launched supporting 32,000 patients, first 6 months post-launch: 89% patient satisfaction, 76% adoption rate, £240,000 annual operational savings from reduced administrative overhead, and avoided writing off £520,000 investment (salvaged £180,000 of value).

ROI: Rescue cost £180,000. Saved £60,000 vs rebuild, saved 5 months time-to-value, and preserved £180,000 of previous investment. Effective savings: £240,000 (direct cost savings + time value).

Case study 2: Fintech trading platform — prevented £1.2M loss

Client: Financial services startup, algorithmic trading platform

Failure scenario: 16 months into development with offshore vendor, £680,000 spent (original £320,000 budget, original 10-month timeline). Platform fundamentally broken and nowhere near production-ready:

Data synchronization failures causing pricing discrepancies (critical in trading), performance completely inadequate (40-second API response times, need <500ms), security audit revealed 23 critical vulnerabilities including authentication bypass, FCA compliance absent (no audit trails, inadequate data retention, missing regulatory reporting), code quality extremely poor (no error handling, no logging, hardcoded configuration, no tests), and vendor capability gap obvious (promised senior developers, delivered juniors with no financial services experience).

Client position: Lost confidence in vendor, considering legal action for breach of contract, evaluating two options: (1) write off £680,000 and start over with new vendor (£450,000 estimated, 12 months), or (2) attempt rescue but worried about throwing good money after bad.

Our rescue assessment: 3-week assessment with brutal honesty: approximately 25% genuinely complete at production quality, core architecture completely wrong for low-latency trading (synchronous processing, no caching, inefficient database queries, no message queuing), security so poor that complete security refactoring needed, FCA compliance gaps too numerous to patch — need systematic compliance-by-design approach, and vendor delivered code quality indicates fundamental lack of financial services domain expertise.

Recommendation: Hybrid approach — salvage some components but essentially rebuild core trading engine and compliance systems. Estimated cost: £380,000, timeline: 9 months. Rationale: Complete write-off would waste any salvageable components. Some non-critical modules (user management, basic UI components, reporting) could be salvaged with refactoring (saving ~£80,000). Core trading engine, data pipelines, compliance systems needed complete rebuild with proper architecture. Hybrid approach was 16% cheaper and 25% faster than complete rebuild.

Rescue execution: Rebuilt core trading engine with proper architecture (asynchronous processing, message queuing, Redis caching, optimized database design), implemented FCA-compliant audit trail and regulatory reporting, fixed all security vulnerabilities and implemented secure-by-design patterns, salvaged and refactored suitable components (user management, basic UI, some reporting), achieved <300ms API response time target (vs 40s previously), implemented comprehensive automated testing (82% coverage), and passed external security audit and FCA compliance review.

Results: Project delivered in 9 months vs 12-month complete rebuild estimate (25% faster), total cost: £380,000 rescue + £680,000 previous spend = £1.06M vs £1.13M complete write-off + rebuild (£70,000 direct savings), platform launched successfully meeting all performance and compliance targets, first 3 months trading: processed £180M transaction volume with 99.97% uptime, regulatory approval granted (FCA review passed), and investor confidence restored (Series A funding round proceeded — £4.2M raised).

ROI: Rescue investment £380,000. Prevented complete loss of £680,000 investment (salvaged £180,000 of value). Enabled 25% faster time-to-market (critical in competitive fintech market). Regulatory approval and investor confidence enabled £4.2M funding round that was at risk. Total value preservation: estimated £800,000+ (salvaged investment + time value + strategic value).

Hidden value: Platform architecture is now production-ready for scale (original vendor's architecture would have failed at production scale requiring another rebuild). Security and compliance foundation will support future regulatory expansion.

Pricing and engagement models

Emergency assessment (rescue feasibility)

£12,000 - £28,000 | 2-3 week engagement Rapid assessment of failing project including codebase review, architecture assessment, team evaluation, financial analysis, realistic completion cost estimation, recommendations (continue/remediate/rebuild/replace), and executive presentation. Deliverable: assessment report with options and recommendations. Critical first step for informed decision-making.

Project rescue and stabilization

£35,000 - £85,000 | 6-12 week engagement Emergency stabilization of failing project including critical bug fixes, security vulnerability remediation, basic testing implementation, project governance establishment, vendor transition if needed, detailed recovery roadmap with realistic costs and timeline. Stops the bleeding and creates stable foundation for recovery.

Full project rescue and delivery

£80,000 - £350,000+ | 3-9 month engagement (varies significantly) Comprehensive rescue including assessment, stabilization, recovery planning, execution of recovery (completing/rebuilding project), quality assurance and testing, deployment to production, documentation and training, post-launch warranty period. Pricing depends on project size, complexity, and percentage requiring rebuild. Typical range: 60-120% of realistic remaining completion cost.

Vendor transition management

£15,000 - £35,000 | 4-8 week engagement Managing transition from failing vendor to new team including knowledge extraction from outgoing vendor, intellectual property and access transfer, legal/contractual coordination, environment setup for new team, documentation of existing system, handover to replacement team. Often bundled with rescue services but can be standalone if client has chosen replacement vendor.

Project governance and oversight (advisory)

£4,500 - £9,500 per month | Ongoing Ongoing advisory and oversight for at-risk project including monthly project health assessment, governance process establishment, vendor performance monitoring, risk identification and mitigation, stakeholder reporting, escalation support. For organizations wanting expert oversight without full project takeover.

Technical debt assessment and remediation

£25,000 - £75,000 | 4-10 week engagement Addressing technical debt crisis in delivered but problematic system including comprehensive technical debt audit and quantification, prioritized remediation roadmap, critical debt reduction implementation, automated testing implementation, code quality improvements, performance optimization. For completed projects with severe technical debt impacting maintainability and reliability.

When you need project rescue

You need project rescue services if:

1. Project significantly behind schedule — 30%+ timeline overrun with no clear end in sight, or perpetually "almost done"
2. Significant budget overrun — 50%+ over budget with unclear remaining costs, or continuous requests for more funding
3. Lost confidence in vendor — Suspect fundamental capability gap, promises not delivered, quality concerns
4. Zombie project — Not cancelled but not progressing, stuck in perpetual "almost complete" state
5. Technical crisis — Critical security vulnerabilities, performance problems, scalability limits, architectural failures
6. Communication breakdown — Vendor-client relationship deteriorated, mutual blame, defensive posturing
7. Quality concerns — Delivered code quality far below professional standards, technical debt crisis
8. Considering write-off — Evaluating whether to abandon investment but want objective assessment first

Why iCentric for project rescue

Senior expertise: Project rescue requires experience and judgment, not junior developers following processes. Our rescue teams include architects and senior engineers with 15-20 years experience who've seen every type of failure pattern. We understand why projects fail and how to recover them.

Brutal honesty: We provide objective assessment with no sugar-coating. If your project is unsalvageable, we'll tell you directly and explain why, even if that means smaller engagement for us. You need truth, not optimism. Our recommendations are evidence-based and focused on your best interests.

Vendor-neutral: No vested interest in defending previous vendor or decisions. We assess objectively based on evidence. If your vendor is actually competent but project just needs better governance, we'll say so. If vendor has fundamental capability gap, we'll provide evidence.

Financial transparency: Realistic cost estimates backed by detailed analysis. We quantify technical debt, completion percentages, and realistic remaining costs. You'll understand what you're buying and why it costs what it costs. No surprising bills halfway through rescue engagement.

Rescue experience: We've rescued 40+ failing projects across healthcare, finance, e-commerce, professional services, SaaS, and government. Experience with projects that were 20% complete to 95% complete. Projects failing for technical reasons, team reasons, requirement reasons, or combinations thereof.

Fixed-price rescue options: For suitable projects, we offer fixed-price rescue delivery (after assessment phase). This eliminates risk of rescue engagement itself running over budget. Not all projects are suitable for fixed-price (too much uncertainty), but for many we can commit to fixed delivery price after proper assessment.

Accountability: We tie our compensation to delivery. Assessment phase is straightforward time-and-materials, but rescue execution can include success-based fee components (fee reduction if we miss our own timeline/budget, fee bonus if we beat it). We're accountable for our own estimates.

Next steps: Emergency project assessment

If your project is failing or at risk, start with an emergency assessment. Fast-track engagement (can start within 3-5 business days of contact) providing objective evaluation and clear recommendations.

Emergency assessment includes:

• Stakeholder interviews (understanding history, issues, objectives)
• Technical code and architecture review
• Financial analysis (spend vs value, completion cost scenarios)
• Team and vendor capability evaluation
• Risk assessment (technical, team, timeline, business)
• Options analysis (continue/remediate/rebuild/replace with cost-benefit)
• Recommendations with rationale
• Executive presentation and Q&A

Timeline: 2-3 weeks from kick-off to delivery

Investment: £12,000-£28,000 (fixed price based on project size)

Get started: Contact us for emergency project assessment →

For immediately critical situations (production system failure, vendor abandonment, imminent regulatory deadline), we offer 48-hour emergency response — initial triage assessment and stabilization plan delivered within 48 hours of engagement.