Why a retrospective rather than a case study
A conventional case study describes a problem, an intervention and a result, and every one of them is written to make the firm look competent. They are not lies, but they are selected — and a reader learns very little from a story in which nothing went sideways.
This is the same engagement written differently: what we would keep, what we would sequence differently, and the one thing we should have pushed harder on. The client is anonymised under confidentiality, as all our case work is.
The situation
A specialty lending business running high-velocity deal flow through a CRM that had drifted a long way from how deals actually moved. Underwriting, sales and servicing each kept their own records. Pipeline reporting required manual assembly. Stage data was unreliable enough that leadership had no defensible view of conversion or capacity.
Deal velocity is the business model in specialty lending. Every hour of manual reconciliation and every mis-staged deal was constraining funded volume directly.
What we would keep
- Data model before interface. We rebuilt the deal record and its lifecycle before designing a single screen. It felt slow to the client for three weeks and saved months later — every screen built afterwards was building on something settled.
- Two parallel-run cycles, not one. We ran the new system alongside the old for two full deal cycles before cutover. One cycle would have looked sufficient and would have missed the edge cases that only appear at month-end.
- Joint design with underwriting and sales in the same room. Sequential design — sales first, underwriting later — was the obvious efficiency and would have been a mistake. The handoff between them was where the actual friction lived.
- Migration validation gates. No batch moved without a reconciliation check that had to pass. Slower, and the reason nobody spent the following quarter hunting for missing records.
What we would sequence differently
We ran the stage-definition work as a workshop during discovery — a good workshop, with the right people, that produced a clear document. Then we started building.
In hindsight the definitions were not an input to the build; they were the build's critical path. Two of the three schedule slips traced back to a stage whose exit criteria turned out to mean different things to underwriting and to sales, discovered when the automation encoding it behaved 'wrong' for one of them.
What we would do now: treat stage definitions as a deliverable with its own sign-off gate, and have two leaders independently write the criteria before comparing. Where the two lists diverge is the real specification, and it is cheaper to find in week two than in week nine.
The decision we would argue harder about
The client wanted to migrate seven years of historical deals. We raised the cost, they weighed it, and we migrated it. That was a defensible call on the information available.
What we know now is that almost none of it has been queried since. The reporting that matters looks at eighteen months. The historical data added meaningful time to the migration, meaningful risk to the validation, and produced very little.
We would now push a specific alternative rather than simply flagging cost: archive everything older than two years to cold storage, migrate the rest, and agree a defined path to retrieve archived records if anyone ever needs them. Nobody has, on any engagement since, in our experience.
What actually changed for the business
Outcome categories observed, in the format we publish all client results — directional, not invented:
- One deal record and one lifecycle shared across sales, underwriting and servicing
- Automated handoffs replacing email-and-spreadsheet coordination between the three functions
- Executive pipeline reporting produced by the system rather than assembled around it
- Stage data leadership was willing to make capacity decisions from
Where exact figures are not approved for publication we do not invent them. That constraint is why the retrospective format is more useful than the numbers would have been anyway.
The transferable lesson
If you take one thing: the expensive part of a CRM rebuild is almost never the software. It is the organisational agreement the software forces you to reach. Most of what looked like project risk on this engagement was actually unresolved process disagreement surfacing under deadline pressure.
Which means the cheapest thing you can do before any rebuild — bespoke or platform — is get two leaders to write the stage criteria independently and compare. It costs a morning. It tells you whether you have a systems problem or an alignment problem, and those need very different projects.