Every failed CRM implementation I’ve ever autopsied died of the same cause: the company bought the sequence in reverse.
The reverse sequence goes like this. Reality is messy — undefined stages, unagreed definitions, handoffs running on folklore. Rather than fix that (slow, unglamorous, requires admitting things), the company buys a system and assigns it the fixing. *We’ll define our processes during implementation.* The tool as forcing function. The software as therapist.
It sounds efficient. Here’s what actually happens.
—
Implementation turns out to be the worst possible room for organizational truth-telling.
There’s a vendor timeline, so every open question has a deadline measured in days. There’s sunk cost, so nobody wants to pause the project to have the real argument about what “qualified” means. Configuration decisions get made by whoever attended the workshop — not by the people who live in the process — and every ambiguity the company carried in gets hard-coded under deadline pressure. The system ships on time, technically. What shipped is the company’s confusion, now with required fields.
Then adoption fails, because the coded process never matched the real one, and people do what people always do with systems that don’t match reality — Chapter 6, every time: they route around it. Then the reports disappoint, because the data’s thin. Then the tool gets blamed — Chapter 10, every time — and eighteen months later the replacement ritual begins, and the same ambiguity gets migrated into a newer interface.
The company thinks it keeps buying the wrong software. It keeps buying software *at the wrong point in the sequence.*
—
Here’s the right order. It’s not complicated. It’s just not purchasable.
**First, fix the reality.** Get the definitions agreed — actually agreed, in a room, by the departments who have been quietly running different dictionaries. That’s the peace treaty from Chapter 7. Design the handoffs — entry criteria, payloads, acknowledgments, owners — Chapter 8’s exchange zones. Read your shadow systems for the specs they’ve been filing for years, Chapter 6. Put leadership’s version of the process and the team’s version in the same room and reconcile them — that room is what PBJ Sessions™ are for, and it costs less than one month of the software you were about to buy.
**Then build the system.** And here’s what changes: implementation stops being therapy and becomes *transcription.* You’re not discovering your process under vendor deadline — you’re recording a process that already exists, already works, and already has agreement underneath it. Configuration is fast because the arguments already happened. Adoption is high because the system finally describes work the way the workers actually do it. The data is trustworthy because the definitions feeding it are shared.
Same software. Opposite outcome. The only variable was the sequence.
—
The economics, since someone in your leadership meeting will ask: fixing reality first *looks* slower — weeks of unglamorous agreement-building before anything demos. Buying first looks fast and costs the full misdiagnosis tax: the implementation, the failed adoption, the replacement cycle, the years of decisions made on data nobody trusted. I have never once seen the reverse sequence come out cheaper. Not once. The slow way is the fast way. It’s just not the *announceable* way.
And when you do it in order, something quietly remarkable happens the first time you open the finished system.
You recognize your company in it.
The mirror from the start of this chapter stops being an accusation and becomes an instrument. That’s the whole arc: the CRM was never the problem, and it was never going to be the solution. It was always going to show you exactly what you built.
Fix the reality. Then build the system. The system will finally have something true to say.