90-Day Salesforce Recovery for Global Fashion Retailer

Situation

A global fashion retailer with €800M in annual revenue had been attempting a Salesforce Sales Cloud deployment for 18 months. The original go-live date was 14 months prior. The project had consumed €2.4M in SI fees against an original budget of €900K. The current implementation partner had billed 40% more in “scope change” fees than the original contract value, yet delivery remained incomplete.

The business was operating under significant operational impact. The sales team was managing pipeline in Excel because the Salesforce deployment was not trusted: too many data errors, too many performance issues. Management had lost confidence in both the project and the implementing partner. The Salesforce investment was being questioned at board level.

The relationship with the SI had broken down completely. Escalations to the SI’s account management had produced SLAs and apologies but no delivery. The client had served legal notice to the SI. The engagement had transitioned from a technology project to a legal dispute, with the SI protecting their position rather than delivering.

The client needed an independent architect to assess the damage, determine what could be salvaged, and deliver the remaining requirements against a hard 90-day deadline set by the incoming CFO.

Challenge

The first two weeks were entirely diagnostic. No changes were made to the org or the project plan until the full picture was clear.

The technical assessment documented the current org state against the original requirements specification. Of the 87 functional requirements in the original scope, 34 were fully delivered, 28 were partially delivered (functional but incomplete), and 25 were not started. The 34 “fully delivered” requirements included 11 that were delivered with known defects the SI had logged as “backlog items”: effectively delivered on paper but broken in practice.

The data model had fundamental architectural problems. The Account hierarchy had been modelled incorrectly for the client’s B2B wholesale structure, creating a constraint that prevented multi-territory account ownership. The lead conversion process had been customised in a way that created data integrity issues on every conversion. Record-Triggered Flows had been written without governor limit considerations, causing bulk operation failures. Test coverage was 42%, well below the 75% Salesforce requires and the 80% that production workloads require.

The process and governance picture matched the technical one. There was no proper change control. Requirements changes were agreed verbally with the SI project manager, never formally documented, often interpreted differently by client and SI. The “scope change” fees represented legitimate additional work in some cases and SI mistakes in others, but without formal change orders there was no way to adjudicate. There was no UAT process either. The client had accepted deliverables on the basis of SI-run demos, without a structured user acceptance test against written test cases. Users had not been involved in any testing until after each release, meaning defects were discovered in production rather than in testing.

Of the 28 partially delivered requirements, 19 could be completed with targeted development. The 9 remaining had been built using architecturally wrong approaches and needed to be rebuilt. The 25 unstarted requirements were all achievable within 90 days given the right team and methodology. The data model issues needed architectural fixes first; otherwise the new requirements would have landed on a broken foundation, and the rescue would have failed the same way the original did.

What I told the CFO at the end of the diagnosis phase

We cannot deliver eighty-seven requirements on a broken account hierarchy. Two weeks to repair the architecture, eight weeks to deliver everything. That is the only path that holds.

Action

Every requirement had a written acceptance criteria document, drafted by the business owner and signed off before development started. Every completed item was tested by the business against that criteria before being marked as done. That eliminated the ambiguity that had let the original SI claim delivery on requirements the client did not accept.

Result

All 87 requirements were delivered to production within 90 days, including the 25 that had never been started when the engagement began. The sales team migrated fully from Excel to Salesforce within three weeks of go-live, with no critical incidents in the first 30 days of production operation.

The architectural foundation (rebuilt account hierarchy, clean data model, governor-limit-safe automation, 84% test coverage) gave the business a platform they could build on rather than one they had to work around. The reporting layer ran on the same model the sales team entered. The pipeline metrics the CFO needed for the quarterly review existed for the first time in two years.

The CFO deadline was met. The legal dispute with the original SI was resolved on terms favourable to the client. The technical assessment documentation provided an objective record of what had and had not been delivered, which strengthened the client’s position in settlement negotiations.

More importantly, the organisation recovered its confidence in Salesforce as a platform. The 18-month stall had created genuine scepticism at board level about whether Salesforce could work for the business. A functioning, adopted deployment, with a roadmap for expanding to Service Cloud and eventually Data Cloud, rebuilt that confidence.

Reflection

This pattern works when the failure mode is architectural and procedural, when leadership accepts that diagnosis must precede change, and when the business owners are willing to sign written acceptance criteria. It is the right call whenever a stalled programme is approaching a hard deadline and the original SI relationship has broken down: a rescue with a clean foundation is cheaper and faster than starting over.

It works less well when the prior implementation has crossed a structural threshold, for example when the data model has been so heavily customised that migration cost exceeds rebuild cost, or when the org’s customisations have been undocumented for so long that diagnosis is itself a multi-month project. At that point, a controlled restart is the honest answer.

Worth doing earlier: the written acceptance criteria. The single change that most consistently prevents the failure mode this engagement repaired is forcing every requirement to have a business-owner-signed definition of done before development starts. That change is free, sits inside the client’s authority, and would have prevented at least half the scope dispute that consumed the original 18 months.