Implementation and change management: why the vendor isn't the whole story

There is a pattern that runs through nearly every government software post-mortem, across every category: the software was fine, and the rollout was not. Great software fails on a bad implementation far more often than bad software fails on a good one, and yet almost all of a buyer's energy goes into choosing the vendor and almost none into preparing to receive what the vendor delivers. The product you select sets a ceiling on what is possible; your implementation determines how much of that ceiling you ever reach. This is the most cross-cutting truth in the whole buyer-side thesis — the buyer's own readiness matters more than the logo.

That reframing has a practical consequence. The questions that most determine success are not 'which vendor,' but 'have we staffed this, who sponsors it, how are we phasing it, and how do we manage the risk that the services get delivered by people we have never met.'

Staff the project with your best people, backfilled

The most reliable predictor of a failed implementation is a project run off the side of everyone's desk. These systems have to be configured by the people who understand the actual work — the senior finance analyst, the veteran permit tech, the billing supervisor who knows every rate exception — and those are exactly the people the organization can least afford to free up. Cities that assign their best subject-matter experts to the project on top of their day jobs get the predictable result: the experts stay busy keeping the old system alive, decisions stall, and the integrator fills the vacuum with assumptions that surface as defects at go-live.

The fix is unglamorous and it costs money: backfill. Free your key people from enough of their operational load that they can genuinely own configuration and testing, whether by temporary staff, overtime, or deferring other work. A buyer who will not fund backfill is, in effect, choosing to have the vendor make the organization's decisions for it — and to discover which decisions those were only after the system is live.

Executive sponsorship is what breaks the ties

Cross-departmental systems generate cross-departmental conflict: whose process changes, whose exception gets dropped, who has to work differently after go-live. Without a senior sponsor with the authority to make those calls stick, every contested decision escalates into a stalemate, and stalemates are what push implementations past their timelines. The sponsor's job is not ceremonial. It is to say 'we are changing this process, not rebuilding it in the new system,' and to have the standing to make that hold when a department pushes back.

This is also where the discipline of not paving the cow paths gets enforced. The pressure to replicate every quirk of the old system as a 'requirement' comes from the departments that own those quirks, and only someone with organizational authority can decide when to adopt the vendor's standard process instead. A successful rollout is as much a business-process redesign as a software install, and redesign without a sponsor is just a wish.

Phase the rollout to match your capacity to absorb change

Big-bang cutovers — every module, every department, live on one date — concentrate all the risk into a single moment and give you nowhere to stand if it goes wrong. Phasing by module, by department, or by geography spreads the risk, lets the organization build competence and confidence on a smaller first success, and creates a real chance to learn before the highest-stakes pieces go live. The right phasing depends on your organization's genuine capacity to absorb change, which is almost always less than the project plan optimistically assumes.

Some cutovers should never be big-bang regardless of appetite. A CIS should bill in parallel with the old system and reconcile before cutover; a payroll should run in parallel before it is trusted with real paychecks. Where an error lands directly on a resident's bill or an employee's paycheck, the parallel-run period is among the most protective things a buyer can insist on in the contract, and its cost is trivial against the crisis it prevents.

Manage the services-delivery risk you can't see at signing

You evaluate and sign with the vendor's sales and solution team. You are delivered to by an implementation team — sometimes the vendor's own, sometimes a third-party integrator, sometimes offshore, and almost always people you never met during the sale. The quality and continuity of that delivery team is one of the largest risks in the entire engagement, and it is nearly invisible in a standard evaluation. Ask, before you sign: who specifically will run our implementation, are they the vendor's staff or a subcontractor, what is their experience with organizations like ours, and what happens if key people roll off mid-project. Where you can, meet the proposed project lead before award.

Then write the delivery expectations into the contract instead of trusting them to goodwill. Define implementation as scoped deliverables with acceptance criteria, tie payment milestones to accepted work rather than elapsed time, and name the escalation path when the project drifts. Reference calls are where this risk gets exposed early — the gap between a peer's contracted timeline and their actual go-live date, and the story of what caused it, is one of the most honest numbers in the whole process. Ask every reference specifically about the implementation team and how the vendor behaved when things slipped, because that, far more than the feature set, is what you are actually buying.

The buyer-side takeaway

Pick a viable, well-fitting product — that part matters and the category guides exist to help you do it — and then spend the rest of your energy on the things that actually decide the outcome: staffing and backfill, an empowered sponsor, honest phasing, a parallel run where the stakes demand it, and a hard look at who will really deliver the services. The vendor is a necessary condition for success and nowhere near a sufficient one. The organizations that get value from government software are the ones that treated implementation as their project, not the vendor's.