If you’ve worked on a transformation that failed — and almost everyone reading this has — there’s a high probability the failure mode was the same: the platform was chosen before the process was redesigned, and the implementation spent the next 18 months automating workflows that should have been eliminated entirely.
This is the single biggest reason transformations fail. It’s also the most preventable. The fix isn’t complicated. But it requires discipline most consulting engagements don’t enforce — including, often, our competitors’.
Here’s the framework we use. We call it Process Before Platform because the order matters, and because the order is what gets compromised first when timelines tighten.
The pattern we keep seeing
Every failed transformation we’ve been brought in to recover looks something like this:
- A leader recognizes a problem. The financial close takes 10 days. The pipeline forecast is unreliable. The legacy ERP can’t scale.
- A vendor evaluation kicks off. NetSuite vs. Workday. Salesforce vs. HubSpot. Boomi vs. MuleSoft.
- A platform is chosen. The contract is signed. Implementation begins.
- The implementation team asks “show us how you currently do X.” They configure the new system to replicate the current process.
- Go-live happens. The new system does exactly what the old one did — slightly faster, with prettier dashboards.
- Six months later, leadership wonders why the promised business outcomes never arrived.
The whole sequence skipped a step that should have happened between steps 1 and 2: redesign the process. Without that step, the new platform is just a more expensive version of the old one.
Why this happens
Three reasons, mostly:
Vendors don’t get paid to redesign processes. They get paid to implement platforms. So every conversation with a vendor — including the pre-sale conversation — is structured around their platform’s capabilities, not your business’s reality.
Process redesign feels slow. It can take 8–12 weeks to do properly. That feels like a delay. Leadership wants to “make progress” — which usually means “see something configured.” So the work gets compressed or skipped.
The current process is invisible. The people who do the work every day don’t have a complete picture of it. The leaders who sponsor the project have a sanitized version. Nobody has documented the actual end-to-end workflow with all the workarounds, exceptions, and shadow systems. Without that map, you can’t know what to change.
The framework: four phases, in order
Phase 1: Understand (2–3 weeks)
Map the actual current-state process — not the intended one. This means shadowing the people who do the work, interviewing the people who manage them, and documenting what really happens. Including the parts that aren’t supposed to happen.
Key outputs:
- End-to-end process map with timing for every step
- Inventory of shadow systems (the spreadsheets, scripts, and workarounds that keep things running)
- Decision rights map (who actually approves what, vs. who’s supposed to)
- Pain inventory (where the process breaks, where time is wasted, where errors happen)
Don’t skip this phase. It’s the foundation everything else builds on.
Phase 2: Optimize (3–6 weeks)
Design the future-state process before considering technology. The question to answer is: “If we were redesigning this from scratch today, knowing what we know now, what would it look like?”
Apply three lenses:
- Eliminate — what steps don’t add value and can be removed?
- Automate — what steps are mechanical and should be done by software, not people?
- Restructure — what steps are in the wrong order, or assigned to the wrong role?
The future-state process is platform-agnostic. It describes what should happen, not which tool should do it. This is the deliverable that lets you evaluate platforms against your actual needs instead of vendor demos.
Phase 3: Select (2–4 weeks)
Now — only now — evaluate platforms. With the future-state process in hand, the platform evaluation becomes structured. You can ask vendors: “Show us how your platform supports this specific workflow.” The answers are concrete. The differences between platforms become legible.
This phase often surprises clients. Sometimes the platform they were planning to buy turns out to be over-engineered for their actual future-state process. Sometimes a platform they hadn’t considered turns out to fit perfectly. When Salesforce is the wrong answer walks through specific examples of this in CRM selection.
Phase 4: Implement (varies by scope)
Implement the platform to serve the future-state process. Configure features that the process requires. Don’t configure features that aren’t part of the redesigned workflow. Resist the temptation to “turn on everything because we paid for it.”
This is also where adoption work begins — and continues for six months past go-live. The people doing the work need to be trained on the new process and the new tool simultaneously, not in sequence.
The discipline that makes this work
The hard part of Process Before Platform isn’t the methodology. It’s the discipline to stick with it when the pressure mounts to move faster.
The pressure will mount. Stakeholders will ask why you’re “still talking about process” in week 6. A vendor will offer an aggressive discount if you sign by month-end. A board member will say “we just need to pick something.” A team member will insist that “we already know how this should work, let’s just start building.”
Holding the line — finishing the optimize phase before starting the select phase, finishing the select phase before starting the implement phase — is what separates transformations that deliver from transformations that don’t.
This is why we structure every Mercury Consulting engagement around this framework, and why our contracts include a hold point between phases. We’re not willing to skip the work that determines whether the engagement succeeds.
What success looks like
When Process Before Platform is executed properly:
- The platform implementation comes in on time or ahead of schedule, because the requirements were clear before configuration started
- Adoption rates exceed 90% within 6 months of go-live, because the new process was designed with the people who use it
- The business outcomes promised in the original business case actually materialize
- The CFO/CRO/CIO sponsoring the transformation gets credibility for delivering — not for “implementing a system”
That last point matters. The currency of an executive sponsor is delivered outcomes, not completed implementations. The framework is how you protect that currency.
Read more: Why Financial Close Projects Stall After Go-Live — what happens when process-before-platform isn’t followed in a finance context. Or The RevOps Maturity Model — the same principle applied to revenue operations.