Why You Fix the Process Before the System Rollout, Not Alongside It
I've rolled out CRM three times: at an agency, at a seasonal corporate-gifts manufacturer, and at an online-booking platform. Three companies, three industries, three teams. One thing was the same everywhere: in every case, the first version of the configuration was the existing way of working, carried over into fields and statuses as-is.
That is exactly the point where the project's fate gets decided. If the process before the rollout contained optional fields, manual exceptions, and "here we usually just call and work it out," all of that moves into the system and gets the status of the norm. From there, fixing it gets more expensive: now the mess has a configuration, integrations, and trained users behind it.
A system doesn't clean up a process — it fixes it in place. Anything not decided before the rollout turns into a configuration setting, an exception, or a user habit, and the cost of fixing it later jumps by an order of magnitude. So before the project starts, three things need to be closed out: the list of mandatory data, the calculation rules, and the handoff points between roles.
What a system actually locks in
The claim that "a system locks in the mess" sounds like a metaphor until you break it down into concrete mechanisms. There are four of them, and each one is visible within the first few weeks after go-live.
An optional field stays permanently empty. At configuration time, the argument "let's make it optional or people won't fill it in" almost always wins. A quarter later, it turns out the field is empty on 80% of records and you can't build a report off it. The decision about which data is mandatory is a process decision, not a technical one, and making it after go-live is too late — now you have to backfill it retroactively.
An exception turns into a status. "We do it differently for this client" looks trivial at rollout time, so a separate status or a separate deal type gets created for it. A year later there are twelve such statuses, and no employee can explain the difference between four of them. Every status is a branch in reporting, in access rights, and in onboarding a new hire.
A manual arrangement becomes invisible. Where two colleagues used to settle something by talking, the system now shows nothing: the request sits in a status while the work actually happens. Formally the process is being executed; in reality it's running around the system, and the data in it stops reflecting reality. From there, the manager makes decisions off a report that describes something other than what's happening.
A calculation done from memory moves into a free-text field. If the calculation rules aren't formalized before the rollout, the system ends up with an "amount" field that a manager types a number into. The system looks implemented, but the arithmetic stays manual — with all the errors it produced before.
| What wasn't decided before the rollout | What it turns into | When it surfaces |
|---|---|---|
| Which data is mandatory | An empty field on most records | On the first attempt to build a report |
| What counts as an exception | A dozen statuses with no real differences | While onboarding a new employee |
| Where the handoff between roles happens | Work runs around the system | When the report diverges from fact |
| What rule the amount is calculated by | A free-text field for manual entry | During reconciliation with accounting |
| Who owns the process | Whoever asks loudest changes the settings | All at once, two or three quarters later |
What all five rows have in common is the moment of discovery. None of these problems shows up during the project; they all surface after its formal close, once the rollout team has already disbanded and the budget is spent.
How common this pattern actually is
Enterprise system rollouts are measured regularly, and the picture is consistent: the problem isn't the technology or the vendor.
More than a quarter of organizations that rolled out ERP reported exceeding the project budget, and almost a quarter reported missing planned timelines.
A caveat is warranted here, and I'll make it myself: this is a report from a consulting firm that sells ERP rollout support services. The sample isn't random — respondents opted into an invitation, so a skew toward the firm's own clients and subscribers is likely. The figure works as an order of magnitude, not as a market measurement.
On average, only 48% of enterprise-wide digital initiatives meet or exceed their planned business outcomes. For the group of companies analysts identify as digital transformation leaders, the same figure is 71%.
This is a press release, not the full report: the survey instrument, collection period, and exact question wording aren't publicly disclosed. What matters here isn't the share itself but the 23-percentage-point gap between leaders and everyone else — it shows that the outcome is determined not by whether a system exists, but by how the work around it is organized.
What we started doing before the project starts
After the third rollout, the set of upfront decisions became fixed. It's short and requires no analyst and no budget — just the process owner's time.
The first decision is the most unpleasant one, because it's about saying no. A mandatory field means someone won't be able to finish their work the way they're used to, and that will trigger pushback. But mandatory fields are exactly what produces the reporting the system was bought for in the first place — the same mechanism was behind the effect we got from our proposal generator.
The second decision strips free-text entry out of the system wherever a calculation is possible. As long as the amount is typed in by hand, there's no automation — just an electronic form for manual work.
The third decision is about handoffs between roles. Every handoff should be an event in the system, not a verbal agreement. If work passes between two people by voice, the system will show one thing while something else happens.
Separately, on what isn't on this list. It doesn't include a twenty-page as-is process diagram. That kind of documentation almost always gets produced, almost never gets read, and doesn't help make any of the three decisions above: it captures observed behavior, while the decisions are about the norm. On our third rollout we skipped the full as-is documentation and spent the freed-up time on two days of working through mandatory fields — that turned out to be the only preparation step that actually affected the outcome.
The second thing missing from the list is platform selection. It's not meaningless, but it's secondary: all three decisions are framed the same way regardless of which mainstream system you pick, and none of them depends on the vendor. Choosing the system first and discussing the process second guarantees that the conversation about the norm will happen in the terms of one product's constraints, rather than in the terms of the business.
Why fixing it after go-live costs more
The price difference isn't a feeling — it's dependency arithmetic. Before go-live, a decision changes in a document. After go-live, the same decision touches the configuration, accumulated data, integrations, reports, and user habits, and each of those layers requires separate work.
Across a sample of 1,471 IT projects, the average budget overrun was 27%, but one in six projects turned into a "black swan" with an average overrun of 200%. The risk is concentrated in the tail of the distribution, not in the average.
I cover this same work in more depth in the article on effort-estimation error. One aspect of it matters here: the overrun isn't distributed evenly. Projects where scope was defined by what the system could do, rather than by process decisions, land in that exact tail — because every deferred decision resurfaces as unplanned work.
Four questions to answer before a rollout project starts
Without which data does a record have no meaning
A list of three to five fields. If it's longer, you're describing what's desired, not what's mandatory.
What does the system calculate here
Every amount, deadline, and status that can be derived from other data should be derived, not entered.
Where does work change owner
List the handoffs. Each one should become an event: who passed it on, who accepted it, when.
Who can change the configuration
One person with the authority to say no. Without that, a year later the configuration will reflect the history of requests, not the logic of the process.
If there's no answer to all four questions, the rollout project hasn't started yet — what's happening is procurement.
Questions people ask most often
Do you need to document the process before a CRM or ERP rollout?
Documenting it in full isn't necessary, but making three decisions is: which data is mandatory, what the system calculates instead of a person, and where the handoffs between roles happen. These three decisions take a few working sessions with the process owner and determine more than the choice of platform does. Full process documentation without them doesn't save the project, and with them it's usually not needed.
Can you fix the process in parallel with the rollout?
You can, but you'll pay twice: first for configuring around the old order, then for reconfiguring around the new one along with migrating the accumulated data. Running in parallel is justified when the process can't be understood without a working system — but then it's more honest to call the first stage a pilot with a rebuild built into the plan, not a rollout.
What do you do if the system is already live and there's still no order?
Don't reconfigure everything at once. Take one report the manager actually uses, and walk it bottom-up: which fields feed into it, how many records have them filled in, where the values come from. It usually turns out that making two or three fields mandatory and removing one free-text field is enough to make the report start reflecting reality.
Who should make these decisions — IT or the business?
The process owner — the person accountable for the outcome, not for the system. The sign of a correct split: IT answers "how do we build this," the process owner answers "what do we count as the norm." If a contractor is the one deciding which fields are mandatory, then no one has actually been asked what the norm is.
The claim that "three rollouts out of three started by carrying the existing process over as-is" refers to CRM rollouts at three companies run by the author: a digital agency (Megaplan as the system of record), a seasonal corporate-gifts manufacturer, and an online-booking platform. The list of upfront decisions and the process staging come from the client-interaction procedures of the same period. These are internal materials from the author's companies; they haven't been independently verified and are presented as an illustration of the mechanics. The list of five deferred decisions and the point at which each surfaces has been reconstructed from experience with these rollouts.
- Panorama Consulting Group. The 2026 ERP Report (survey of 170 organizations, January 2025 – January 2026). panorama-consulting.com
- Gartner. Survey Reveals That Only 48% of Digital Initiatives Meet or Exceed Their Business Outcome Targets. Press release, October 22, 2024. gartner.com
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, September 2011. hbr.org