If you are a local government procurement team moving to an eProcurement system, my short answer on change management is this: treat adoption as the project and the software as one input to it. The agencies I have seen succeed redesign their purchasing process before they configure anything, earn buy-in from departments and vendors early by showing each group what gets easier for them, train people on the work they actually do rather than on screens, and measure whether purchasing is really moving through the new system instead of assuming it is because the go live date came and went.
I say that after more than a hundred engagements with public agencies, and the pattern holds whether the organization is a small city or a large county. The technology is rarely what decides the outcome. What decides it is whether the people who request, approve, and fulfill purchases find the new way of working simpler than the old one, and whether leadership is willing to stop supporting the old way once the new one is ready.
Why do eProcurement implementations struggle with adoption?
In my view most adoption problems are designed in long before launch. A procurement office buys a platform to solve real pain, such as paper requisitions, slow approvals, and solicitations that are hard for small vendors to find, and then it configures that platform to mirror every step of the process it already had. The result is a digital version of the same bottlenecks, and departments notice right away that nothing got faster for them. When the people on the front end of a purchase see extra clicks and no benefit, they find workarounds, and those workarounds quietly become the real process.
The other common struggle is that eProcurement touches far more people than procurement staff. Every department that requests goods, every approver in the chain, finance, legal, and the entire vendor community all have to change how they work. If the change plan only covers the procurement office, the system will look healthy inside that office and stall everywhere else.
Should we redesign the procurement process before choosing software?
Yes, and I would go further and say this is the single most important decision you will make. Before you look at demos, sit down with procurement, finance, and a handful of the departments that buy the most, and map how a purchase actually moves today, from the moment someone realizes they need something to the moment the vendor is paid. You will almost always find approvals that exist out of habit, forms that ask for information nobody uses, and thresholds that have not been revisited in years.
Clean that up first. Decide which approvals truly add judgment and which ones simply add delay, agree on what each threshold should trigger, and write down the policy decisions the system will need to enforce. When you do this work before selection, your requirements describe the process you want rather than the one you are trying to escape, and you can evaluate vendors on how well they support it. I have watched agencies skip this step because it feels slower, and they almost always end up doing the same redesign later, under more pressure, in the middle of an implementation.
How do we get departments and vendors to buy in?
Buy in comes from people seeing something in it for themselves, so I would start by asking each group what frustrates them about purchasing today and then show them, specifically, how the new process addresses it. Department heads usually care about knowing where a request stands and getting what they need without chasing approvals. Approvers care about having the right information in front of them at the moment they decide. Finance cares about cleaner coding and fewer surprises at month end. If your change plan speaks to each of those concerns in their own terms, you will find people who are willing to champion the system inside their departments.
Vendors deserve the same attention, and in local government they are easy to overlook. Many of your suppliers are small and local businesses, and some of them have never registered in a supplier portal. If registration feels confusing or the first solicitation they see is hard to respond to, you risk shrinking your competition and frustrating the very businesses your community wants to support. I would plan vendor outreach as its own workstream, with clear instructions, a few open help sessions, and a real person they can call during the first months. I would also be transparent about the timeline, so vendors know when paper or email submissions will stop being accepted.
What does good eProcurement training look like?
Good training is built around roles and real tasks rather than around the software’s menus. A department requester needs to know how to create a request, attach what is required, and track it, and they need to practice that with examples that look like their own purchases. An approver needs to know how to review and act quickly, ideally from wherever they actually work. Procurement staff need deeper training on solicitations, evaluations, and contract records, and they need it early enough that they can support everyone else.
I would also time training close to when people will use it, because skills fade fast when there is a long gap between a classroom session and go live. Short job aids, recorded walkthroughs, and a visible place to ask questions will do more for adoption in the first ninety days than a long training manual nobody opens. Finally, I would identify super users in the departments that buy the most, give them extra time with the system, and let them be the first line of help for their colleagues, because people are far more likely to ask a coworker down the hall than to file a ticket.
How do we measure eProcurement adoption?
Go live is a milestone, not proof of adoption, so decide before launch what adoption will look like and how you will see it. The measures I find most useful are simple: how much purchasing activity is flowing through the system compared with outside it, how long requests and approvals take now compared with your baseline, how many vendors are registering and responding to solicitations, and how often people are reaching for workarounds like emailed approvals or off system purchases. If you capture a baseline during the process redesign, you will be able to show real change rather than anecdotes.
Then use those measures to manage, not just to report. When one department lags, find out why, because the answer is often a process gap or a training gap you can fix quickly. When a workaround keeps appearing, treat it as feedback that the system or the policy needs adjusting. And at some point leadership has to retire the old path, because as long as the paper form still works, some people will keep using it.
My view on getting this right
eProcurement can genuinely make purchasing faster, more transparent, and more open to local vendors, but only when the organization changes along with the technology. Whether you land on a commercial platform or bespoke software built around your process, the work that determines success is the same: redesign first, bring departments and vendors along, train for real work, and measure honestly. If you are starting that journey and want to begin from the process rather than the product, I would invite you to explore how we approach it at Start at Zero.
Planning your next move? Write to us.