How to Keep a Public Sector ERP Project on Scope

Here’s how to keep a public sector ERP project on budget: lock the scope before you sign, and price every change before you approve it. Then make one person on the government’s side of the table answer for both. Almost every big overrun traces back to a decision nobody priced.

Birmingham City Council learned that the expensive way.

Its Oracle ERP started life as a £19 million project with a £1 million contingency. The latest forecast is £144.4 million, more than seven times the original estimate, and the system still isn’t fully working five years after its planned go-live.

Closer to home, Washington State’s auditor reports that the state’s One Washington program pushed its Workday launch from June 2022 to July 2025, on a modernization the state now plans to spend about $465 million on.

Most advice on this topic lists the risks and stops there.

You get “poor governance” and “scope creep” as bullet points, with no direction on what to do about them, and most of it is written for private companies that don’t answer to a council.

So this post gives you the 8 steps I’d follow from RFP to go-live, the early warning signs that your budget is slipping, and what to do if you’re already over.

If you’re mid-implementation and already worried, KCT’s public sector ERP implementation team steps into exactly that situation.

Why do public sector ERP project budget overruns happen?

Public sector ERP project budget overruns almost always trace back to decisions made without a price tag. Usually the scope was never pinned down, and nobody on the government’s side had the authority to say no.

The numbers back that up. In Panorama Consulting’s 2026 ERP Report, 30% of projects came in over budget. Among those, 54.9% needed unexpected additional technology, 51% expanded the original scope, and 35.3% had underestimated staffing in the original budget.

Government adds its own pressure on top. Guidehouse cites Gartner data showing roughly half of public sector ERP implementations fail. Four patterns explain most of it.

The low-bid trap

Public procurement often rewards the lowest credible price. That puts integrators in an awkward spot, as Panorama points out: price the full scope and risk losing, or price it lean and make it up in change orders later.

You can guess which one wins more bids. The gap between the bid and the real cost doesn’t disappear. It just shows up months later as a change order.

Siloed departments and requirements nobody owns

Finance, HR, utilities, courts, and public works each run their own processes, and each sees the ERP as a fix for their own pain. Guidehouse flags this directly: without a clear future-state vision, stakeholders keep adjusting scope to meet shifting requirements.

Nobody is wrong to ask. The problem is that no one has the authority to say “not in this phase.”

“Adopt” quietly turning into “adapt”

Almost every government ERP starts with a promise to use the software as designed. Then departments push back, and the project starts bending the system around old processes.

Birmingham planned to implement Oracle out of the box. Its own council report later admitted that officers had shifted from adopting the system to adapting it, which badly damaged the implementation.

One of those customizations, a bank reconciliation build, failed so badly the council bought a separate product to replace it.

West Sussex County Council tells a similar story. Its SAP-to-Oracle move went from a £2.6 million estimate to nearly £40 million, and the restarted program now runs on an “adopt not adapt” model.

Key insight: Every customization is a scope decision, and you keep paying for it at every upgrade. Price it like one.

Council approvals and fiscal-year boundaries

Private companies can approve extra spend in a meeting. A city needs a council vote, sometimes a budget amendment, and often a new appropriation in the next fiscal year.

So every slip costs more. Miss a go-live date, and you’re often paying for another year of legacy licenses while staff run two systems side by side. Savings the budget already counted on don’t show up either. Birmingham wrote off £69 million in expected savings when its system didn’t deliver.

Vermont shows the US version of the same trap. The state signed its Workday contract in 2022 and paid for a year of the software before implementing it, while a legislative IT consultant warned the final cost of the $70-million-plus project could run well above the estimate.

Inexperience compounds it. As GFOA notes, most governments only replace their ERP every 10 to 15 years, so the people running the project have usually never done one before.

What is public sector ERP scope creep?

Public sector ERP scope creep is the gradual expansion of what an ERP project must deliver, such as extra modules, custom reports, new integrations, or rebuilt legacy processes, without a matching change to budget, timeline, or council approval. Creep rarely shows up as one big decision. It arrives one reasonable-sounding request at a time.

Not every change is creep, though. A change is fine if it’s actually required and someone has put a price on it.

Before anyone argues about whether a request is a good idea, ask two questions: is it required, and what will it cost in dollars and days? A request that can't answer both isn't ready for a decision.

How to keep a public sector ERP project on budget in 2026: 8 steps

To keep a public sector ERP project on budget, control scope at three points: before the RFP, in the contract, and during the build. Here are the 8 steps in order.

1. Define the project scope and future-state processes before you issue the RFP.
2. Build a total-cost budget that includes staff backfill, data, integrations, and post-go-live support.
3. Write scope, assumptions, and change-order rates into the contract.
4. Commit to "adopt, not adapt" and require a formal case for every customization.
5. Set up a change control board with clear approval limits and a path to council.
6. Hold contingency centrally and report how fast it's being spent.
7. Inventory integrations and test data migration early, through repeated mock loads.
8. Put one accountable owner on the government's side, with backfilled staff behind them.

Step 1: Define public sector ERP project scope before the RFP

Your scope should be written down and agreed internally before a single vendor sees your RFP. If you let vendor proposals define scope, you'll end up comparing bids that each describe a different project.

MNP's review of government ERP failures found governments often start without clear scope, objectives, or success measures. GFOA treats the RFP itself as the tool for defining scope and accountability, which only works if you know what you want first.

Vermont is a live example of what's at stake. A consultant to the legislature's Joint Fiscal Office criticized the state for not running a gap analysis before choosing Workday, so it couldn't be sure which functions the software would replace. The state says it ran several gap analyses. Either way, that's an argument you want settled before the contract is signed.

Before you write the RFP, get these on paper:

• Future-state process maps for each department, showing how work should run in the new system, not how it runs today.
• An in-scope and out-of-scope list covering modules, departments, interfaces, years of history to convert, and reports.
• A phasing plan. Core financials, HR, and payroll usually go first; everything else waits for Phase 2.
• Success measures that council can check, like a first clean month-end close within a set number of days.

If you'd rather have vendor-neutral help building this before you go to market, that's what KCT's ERP selection advisory covers.

Still comparing platforms? KCT's vendor-neutral ERP tools directory lays out the public sector options side by side.

Step 2: Build a government ERP project budget around total cost

A government ERP project budget has to cover everything it takes to go live and stay live. Licenses and vendor services are the easy part; the costs that sink budgets are the ones nobody wrote down.

Staffing is the classic miss. In Panorama's 2026 data, more than a third of over-budget projects had underestimated staffing. Washington State's auditor named staff turnover and vacancies as one of three problems its Workday program still had to solve before launch.

Build the number in three passes, the way ERP project cost guidance from Smart Business suggests: a rough order of magnitude, then a detailed estimate, then a definitive budget. Expect each pass to go up, and take the final one to council.

Step 3: Write scope into the contract

The vendor's proposal is a sales document. Scope only protects your budget once it's in the statement of work, with the vendor's assumptions spelled out.

Texas saw this coming in its statewide ERP planning. Its risk register lists scope creep from approved modifications to the baseline software as a direct threat to the timeline and future upgrades.

Make sure your contract includes:

• Deliverables per phase, tied to your in-scope list from Step 1.
• Written assumptions behind the price: number of interfaces, years of data converted, count of custom reports, training sessions.
• Who pays when an assumption is wrong. If the vendor assumed 5 interfaces and you have 12, the contract should already say what happens.
• Pre-agreed rates for change orders, so every change isn't a fresh negotiation.
• Acceptance criteria tied to payments, so you pay for working deliverables, not elapsed time.

Step 4: Commit to "adopt, not adapt"

The default answer to a customization request should be no. Change the process to fit the software unless the law, or a real operational need, says otherwise.

Birmingham and West Sussex both started with out-of-the-box plans and drifted into customization. Both are now starting over, and West Sussex's new program is built around adopting the standard system. Even outside government, Panorama has long advised customizing only where it creates a real advantage.

Make every customization earn its place. Require a short written case that answers four questions:

• Is this required by law, regulation, or a grant condition?
• Was the standard process tried first, and why didn't it work?
• What will it cost to build, test, and maintain through future upgrades?
• Who decided, and when?

The department asking for the customization shouldn't be the one approving it. That decision belongs to the change control board in Step 5.

Step 5: Set up a change control board with real authority

Every change should go through one board and arrive with a price and a schedule impact attached. If the vendor hasn't estimated it, the board doesn't vote on it.

Without that, changes get absorbed quietly. Panorama's public sector consultants note that budget pressure usually gets resolved by slipping the schedule or cutting capabilities, which is exactly what a board is there to decide on purpose. MNP recommends a project charter that blocks scope creep and customization unless a change adds concrete value.

Set approval limits up front, in dollar amounts that match your own purchasing policy:

Give every change request the same short form, so the board compares like with like:

• Requested by, and which department it serves
• What changes and why, in two or three sentences
• Required by law, regulation, or a grant condition? Yes or no, with the citation
• Cost, priced by the vendor at the contract's change-order rates
• Schedule impact in days, and which milestone moves
• Knock-on effects on testing, training, and data conversion
• Can it wait for Phase 2? Yes or no
• Decision, approver, and date, recorded every time

Keep a "Phase 2 list" for good ideas that aren't urgent. Departments are far more willing to accept "not now" than "no."

Key insight: If nobody can tell you who approved a change and what it cost, the board isn't doing its job.

Running a board like this is hard when your finance director is also closing the books every month. KCT's public sector ERP implementation team runs requirements, scope, and vendor governance from your side of the table, so change orders are governed instead of absorbed.

Step 6: Hold contingency centrally and report the burn rate

Contingency should belong to the project sponsor, not the vendor and not individual departments. It gets released only through the change control board, and its balance gets reported every month.

Birmingham's original plan carried a £1 million contingency on a £19 million budget. That reserve didn't stand a chance against the scale of change that followed.

Size your contingency to the risk. More interfaces, older data, more departments, and any planned customization all justify a bigger reserve. Then track three numbers at every steering meeting:

• Contingency remaining vs. percent complete. If half the reserve is gone at 25% complete, you have a problem.
• Change orders approved, pending, and rejected, with their total value.
• Earned value. Compare work completed against money spent, so you see overruns while they're small.

Step 7: Front-load data migration and integrations

Scope and test data and integrations in the first months of the project. That's where most "surprise" costs hide.

In a 2026 report, it stated that unexpected additional technology was the top reason projects went over budget. Organizations often discover fatal misfits late, then reach for extra technology, scope expansion, and custom builds.

In government, the usual suspects are bank, tax, utility billing, court and reporting interfaces, plus decades of general ledger, vendor and payroll history. To get ahead of them:

• List every interface during scoping: each system that sends or receives data, with an owner and a rough build estimate.
• Start data cleanup the day the contract is signed. The vendor's conversion phase is too late.
• Run mock conversions again and again, reconciling each one to the general ledger until the numbers tie out.
• Test integrations in the first build cycles. Leave them for final user acceptance testing, and they come back as change orders.

Step 8: Put one accountable owner on the government's side

One senior person on the government's side should own scope and budget and hold the vendor to the contract. They need the authority to make calls and actual hours in their week to do it.

San Diego's Independent Budget Analyst flagged this risk early in the city's ERP planning, listing insufficient staff resources and lack of budget control among the reasons projects miss budget and schedule.

Leadership churn makes it worse. Vermont's Workday project has cycled through multiple Agency of Digital Services secretaries since the contract was signed, and every handover resets priorities and institutional memory.

What that looks like in practice:

• Name a project owner, ideally full-time, with a clear mandate from the city manager or sponsor.
• Backfill their day job. A finance director running the city and the ERP at the same time will shortchange one of them, and it's usually the ERP.
• Keep oversight separate from delivery. Your integrator builds the system, so someone independent should check their work for you.

That last point is the gap most governments leave open. The integrator ends up managing the integrator, and nobody is positioned to push back.

Early warning signs your public sector ERP budget is slipping

A public sector ERP budget rarely blows up overnight. The warning signs show up in your status reports months before the overrun reaches a council agenda, if you know where to look.

Washington State's auditor spotted several of these on One Washington. Repeated delays had squeezed the time left for testing and training, with training landing right on top of year-end close. Contingency plans weren't finalized either. Its fix is worth copying: set clear go/no-go decision points in the schedule before you need them.

What to do if you're already over budget

If you're already over, stop adding scope and re-baseline the project once, honestly, rather than asking for more money in installments.

Birmingham shows the cost of the installment approach. Its approved budget reached £131 million in 2024, and the forecast has since climbed to £144.4 million. Every new estimate costs the project more credibility with council and residents.

A real re-baseline covers four things:

1. An independent assessment of where the project actually stands: contract, vendor plan, data, integrations and internal capacity.
2. A scope triage that separates what's legally or operationally required for go-live from what can wait for Phase 2.
3. A contract review, using the written assumptions from Step 3 to decide which costs belong to the vendor.
4. One honest number to council, with a revised timeline and the contingency to back it.

That's the work KCT's ERP recovery and stabilization service is built for, when a program has already slipped and needs someone independent to reset it.

FAQ

The bottom line

Birmingham, West Sussex and Vermont all ran into the same thing: decisions made without a price tag, by people who didn't own the outcome.

If you're still planning, the cheapest fixes happen before the RFP, starting with a written scope and one accountable owner. If you're mid-project, pull your contingency balance and change-order log this week and compare them to percent complete. That comparison will tell you more than any status report.

And if you want a senior, vendor-neutral team holding scope and budget from your side of the table, take a look at KCT's public sector ERP implementation service, or book a discovery call to talk through where your project stands.