The Real Cost of a Failed CCaaS Programme

Build the full cost baseline

Start with the approved business case, contract, implementation plan and current forecast. Separate costs already committed from remaining spend, then add the client-side work that is often spread across operational, technology, data, security, training, change and commercial teams.

The baseline should also show cost caused by delay: extended legacy contracts, parallel running, duplicate licences, temporary support, retained project teams, additional assurance and postponed benefits. These are not automatically supplier liabilities, but they belong in the decision.

Make customer and operational exposure visible

Programme reports can focus on milestones while the operational effect remains dispersed. Review representative customer journeys, service levels, complaints, avoidable transfers, repeat contact, reporting gaps and manual workarounds. Compare the current position with a reliable pre-change baseline where one exists.

Protect the live service before accelerating delivery. A recovery plan that meets a date by weakening testing, training, resilience or operational readiness can move cost from the programme into customer service after go-live.

Diagnose the cause, not only the delay

A revised timetable is not a diagnosis. Trace material issues back to requirements, scope, solution design, integrations, data, environments, supplier capacity, client dependencies, decision rights and acceptance criteria. Distinguish a late activity from the condition that made it late.

Use evidence that can be tested: decision logs, plans, contracts, design records, defect trends, test results, resource commitments and operational measures. This reduces blame and gives the programme a clearer basis for deciding what must change.

Revalidate scope and supplier commitments

Confirm what each supplier and the buyer agreed to deliver, what has changed and which assumptions were never resolved. Map priority requirements to design, configuration, integration, migration, test and acceptance evidence.

Where a capability depends on a third party, custom work, future release or buyer-side activity, make that dependency explicit. The programme can then decide whether to retain, resequence, simplify or remove scope without pretending that every original benefit remains intact.

Reset governance around decisions

Recovery needs a named accountable owner, clear decision forums and one integrated view of scope, cost, risk, dependencies and benefits. Escalation thresholds should identify when customer impact, spend, timetable or acceptance confidence requires an executive decision.

Supplier reporting should be challenged against contractual commitments and delivery evidence. The buyer still needs to own the business outcome, operational readiness and acceptance decision, even where a supplier leads implementation.

• Agree the evidence-based current position and remaining exposure.
• Protect critical customer journeys and live-service continuity.
• Assign owners and dates to unresolved decisions and dependencies.
• Rebaseline scope, cost, milestones, resources and benefits together.
• Define acceptance, cutover, rollback and early-life support criteria.
• Record what would trigger another reset, pause or stop decision.

Choose recovery, controlled completion or stop

Not every programme should continue in its current form. Compare a credible recovery plan with controlled completion, phased delivery, reduced scope, an interim operating option or stopping. Assess each option against customer continuity, total remaining cost, achievable benefits, contractual position and the organisation's capacity to deliver.

Treat prior spend as evidence, not a reason to commit further spend. The decision should be based on future cost, risk and value, with appropriate commercial and legal advice where contract rights or liabilities are material.

Keep the business case live after the reset

A reset changes assumptions. Update the cost model, benefit profile, delivery sequence and ownership so that the executive decision reflects what the programme can now achieve, not what was approved at the start.

After go-live, measure service performance, adoption, operating cost, defects and benefits against the revised baseline. Independent challenge is useful where internal or supplier reporting cannot provide a sufficiently joined-up view of the decision.