And How Yours Doesn't Have To
Most procurement software rollouts disappoint the people who paid for them. A contractor who hesitates before starting another one is not being timid; they are reading the odds. McKinsey has found that roughly 70% of large change efforts fall short of their goals and the reason is rarely the software itself. Rollouts fail because they get treated as a technology install when they really are a change in how people work. That is the hard part, and it is also the opening: how you run the rollout is the variable you control.
The fear is well-earned, because contractors already live with slippage as a baseline, where only 31% of projects come within 10% of their original budget and 98% face delays. A leader who expects a rollout to add to that pile is not being negative. That expectation comes from having watched it happen. The job is not to talk them out of the fear, but to change the conditions that justify it..
When a rollout collapses, the post-mortem sounds the alarm on the technology.. More often the tool was fine, and the rollout asked too much of the organization all at once. A big-bang go-live flips the whole company to a new way of working on a single date, before anyone has built the processes, habits, or the trust to absorb it. The classic example is outside construction: Hershey tried to switch its entire order and distribution system at once, timed the cutover to its busiest season, and spent the holiday unable to ship orders it had taken.
The pattern repeats because the failure is organizational, not technical. People revert to the system they know and trust the moment the new one gets hard, and a big-bang rollout makes the new one hard everywhere simultaneously. This is a systems problem. The crew that goes back to phone calls is not being stubborn; they were handed a change with no room to learn it.
The specific ways it can go wrong are predictable.The scope balloons until the go-live touches every team at once. Training gets compressed into a week nobody remembers, and data from the old system is imported in the new system messy enough to erode trust in the new numbers on day one. The field, the people who will spend the most time in the system, get consulted last or not at all. Each of those is a decision about how the rollout was run, not a flaw in the software, which means each of them is something a contractor can choose to do differently.
Frame the last failed rollout that way and the path forward gets clearer, because the thing that broke was the approach, and the approach is changeable.
A contractor has an advantage a corporate ERP buyer does not: a natural unit to roll out against. You do not have to flip the whole company. You can start with one job, or one crew, prove the system there, and expand as it earns belief and trust.
Pick a job with a foreman who is willing, a purchaser who is engaged, and enough material volume to be a real test. Run the new system on that job while the rest of the company keeps working the way it always has. When the foreman on that job is ordering from the field without calling the office, and the purchaser is closing the loop without re-keying, you have something better than a vendor promise. You have a reference your own people trust, on a job they recognize. That proof is what carries the next crew, and the one after that.
Define what "done" means for that first job before you start it, so the phase has a finish line instead of drifting. A reasonable bar: the field is ordering through the system without falling back to the phone, the purchaser is not re-keying anything, and the job's material costs reconcile cleanly at the end. Hit that, capture the numbers, and you have earned the next phase. Miss it, and you have learned what to fix while the blast radius is one job rather than the whole company.
This is slower to start than a company-wide switch, and that is the point. Each phase produces a visible win before the next one begins, so trust builds instead of resistance. The early job absorbs the rough edges while the stakes are contained, and by the time the rollout reaches the skeptics, it is not a pitch anymore. It is how the last three jobs already ran.
A procurement rollout lives or dies in the field, and the field is a tough audience. 42% of construction firms say their workforce is not prepared for digital technology, and crews who have been doing it by phone and email for decades will not adopt a tool that slows them down, no matter what the office decides. If the system is harder than the phone call it replaces, the phone call wins.
So design the rollout around the field rather than the office. The test is whether a foreman can do the thing they need in fewer steps than the old way, on the device they already carry. Contractors who get this right describe a low bar to entry rather than a training marathon. The win shows up as quiet adoption: orders moving through the system because it is genuinely easier than the phone call, with no memo required.
Part of making it easier is removing the friction that was hidden in the old way. A foreman thinks in terms of what a part looks like and what they call it on the job, rarely in terms of a manufacturer's catalog number, so a tool that demands a SKU lookup pushes the work back onto the field and allows translation errors to creep in. A system the field will adopt lets them search the way they already talk, in slang and images, so the request is correct before it reaches purchasing. When the new tool beats the phone call on speed and accuracy, adoption stops being a mandate and becomes a preference.
A rollout can fail even when adoption goes fine, if what gets adopted is the old chaos in a new interface. Software makes whatever process you feed it faster, and a broken purchasing process running at speed is worse than a slow one. If duplicate orders happen because nobody checks on-hand stock, automating the order does not fix the duplication. It just produces duplicates faster.
Use the phased rollout to fix the workflow, not only to host it. On the first job, watch where the old processes leaked: the part that got ordered twice, the price nobody verified, the request that took three calls to pin down. Then design the new flow to close those gaps rather than reproduce them. The result of the first job should be a better process, not the same process on a screen. Get that right and you scale the operation without scaling the chaos.
A rollout often stalls when the vendor closes the sale, hands over a login, and goes away quietly until renewal. The contractors who have successful roll outs describe the opposite: a vendor who stayed and worked with them. As O'Connell Electric's procurement lead put it, "You didn't just assign us one person, you assigned us a team... we weren't handed a piece of software and then we're on our own to understand it." Interstates had product changes made "within a day or two of requesting them" when something did not fit their workflow, the kind of responsiveness that keeps a rollout moving when the field hits a snag.
Treat that as a requirement you can demand. Ask a prospective vendor who will be in the room during your first job, how fast their response time is when the field hits a wall, and whether they will adjust the system to your process or expect you to bend to theirs. A vendor that treats your rollout as their problem too is one of the strongest predictors that it will stick.
In practice that means being fully present during the first job instead of logging a ticket queue. Someone who sits with the purchaser the first week, who is reachable when a foreman hits a wall on a Friday afternoon, and who adjusts the system when your workflow does not match the default. The vendors who treat onboarding as a box to check disappear right when the rollout needs them most, in the messy middle of the first job where adoption is still fragile. The ones who treat it as a shared project are the ones whose customers are still using the software a year later.
Running the old process and the new one side by side is not free. It means living with two systems for a while, and that overlap has real friction: duplicate steps, a foreman working one way while another works the other, the temptation to declare victory before the rollout reaches the hard cases. A phased rollout that loses momentum can stall in the middle and quietly never finish, which is its own kind of failure.
The discipline that prevents that is finishing each phase before starting the next, and holding the line on a real completion date for the whole effort even while the pace is gradual. Phased does not mean indefinite. It means sequenced, with each step closed out and adopted before the next begins. A contractor who treats the parallel-running period as permanent gets the cost of phasing without the payoff. The teams that succeed keep the phases short and the momentum visible.
The rollout you were right to fear becomes the one that sticks when you prove it on a single job. Win the field because the tool is genuinely easier, and keep the vendor in the work the whole time. A platform built for that, like Remarcable, is designed for the field-to-office workflow and backed by hands-on onboarding, so the first job becomes the reference that carries the rest. Start with one crew, prove the system on that job, and let the result make the case for the next.
