Public Sector ERP Implementation SOW: 12 Things to Check
Most public-sector ERP projects that go sideways were set up to fail the day the statement of work got signed. Go-live and data conversion just happen to be where the damage shows up.
A solid public sector ERP implementation SOW does six things. It lists deliverables instead of activities, gives each one objective acceptance criteria, and ties every payment to acceptance. It also names both sides’ responsibilities, spells out data migration and every integration by name, and pushes changes through a governed change-order process.
Miss any of those and the integrator’s reading of the document becomes your scope.
Grand Rapids, Michigan, is a recent reminder. In November 2025, city staff told commissioners the Oracle ERP implementation had picked up roughly $4.8 million in change orders, pushing the overall project toward $9.5 million.
Most SOW guides online don’t help much with this. They’re written by implementers, for private companies. They skip council approvals, fiscal-year cutovers, audit exposure, and finance staff who are running the city and the project at the same time.
So here’s the 12-point checklist I’d want any city, county, or school district to run in 2026 before signing. I’ve also included the vague phrases worth striking from a vendor’s draft, plus my pick for the safest pricing model.
Let’s get into it.
ERP SOW checklist: 12 checks before your agency signs
Work through them in order. The first four make the rest enforceable.
- Define scope by module, process, and phase, with a written list of exclusions.
- List deliverables as tangible work products, not activities.
- Give every deliverable objective acceptance criteria and a review window.
- Tie each payment to accepted deliverables, with retainage held until go-live.
- Write down your own responsibilities and staffing assumptions.
- Name the vendor's key personnel and limit how they can be swapped out.
- Specify data migration by object, years of history, mock loads, and reconciliation.
- List every integration by name and say who builds each side.
- Define testing phases, defect severity levels, and exit criteria, including parallel payroll.
- Set a change-order process with approval authority, a rate card, and a council threshold.
- Tie training and change management to your real configuration.
- Cover cutover, support through the first fiscal close, and knowledge transfer.
What is a public sector ERP statement of work?
A public sector ERP statement of work is the contract document that defines exactly what an implementation partner will deliver for a government agency: scope, deliverables, acceptance criteria, responsibilities, timeline, and payment terms. It sits under the master agreement and becomes the baseline every change order, invoice, and dispute gets measured against.
People mix up the SOW with the other paperwork in an ERP deal all the time. Here’s how they fit together:
Swipe sideways to see the full table →
| Document | What it covers | Who usually drafts it |
|---|---|---|
| RFP | Your requirements and how vendors should respond | The agency, often with an advisor |
| Master agreement (contract) | Legal terms: liability, data ownership, termination, insurance | Attorneys on both sides |
| Statement of work (SOW) | The actual work: scope, deliverables, acceptance, staffing, schedule, payment | The vendor drafts; the agency should redline hard |
| Change order | An amendment to the SOW's scope, cost, or schedule | Either side requests; the agency approves |
| Service level agreement (SLA) | Uptime, support response times, and hosting performance after go-live | The vendor, negotiated by the agency |
In government, the SOW usually rides along as an exhibit to the contract your council or board approves. So anything left out of it is, by default, extra money later.
Smart agencies don’t wait for the vendor’s draft. South Dakota attached a 33-page model statement of work to its ERP RFP, complete with minimum deliverables per section and a system acceptance checklist. That meant every vendor priced against the state’s expectations from day one.
If you’re still at the RFP stage, do the same. It’s a few weeks of drafting, and you won’t get that leverage back once a vendor is picked.
Why the SOW matters more in government than anywhere else
A government can’t absorb a weak SOW the way a private company can. Budgets are appropriated, overruns turn into public agenda items, auditors still expect a clean close, and the staff who’d catch problems are busy running payroll.
The Government Finance Officers Association made this point directly in its February 2026 Government Finance Review piece on statements of work. Its scenario: a local government with a delayed ERP project, unconfident staff, and multiple signed change orders. When someone finally pulls the SOW, it’s full of buzzwords and generic methodology, with nothing holding the vendor accountable for outcomes.
The extreme version played out in the UK. Birmingham City Council’s Oracle project saw expected costs grow from around £20 million to around £131 million. Auditors later found the system went live in April 2022 before the solution design was fully resolved.
Closer to home, Fort Lauderdale’s City Auditor flagged the city’s Infor ERP in a 2025 budget review for escalating costs, incomplete functionality, and delayed key components, years after Phase 1 went live in 2022.
Four things make public-sector SOWs higher stakes:
- Fiscal years don’t move. If go-live slips past July 1 or October 1, you could be closing the year in two systems at once.
- Change orders above the manager’s signing authority go on a public agenda.
- The new system has to produce auditable books and GASB-ready reports from its first close, finished or not.
- Your finance, HR, and payroll staff run the project on top of their day jobs.
Key insight: In government, the SOW is the document that decides who pays when the project goes off plan.
So give SOW review a named owner and a few weeks on the calendar, starting before the RFP closes. A quick legal read the week before the council meeting won’t catch most of what’s below.
What to look for in a public sector ERP implementation SOW: 12 checks
When you review a public sector ERP implementation SOW, look for language you could enforce in a dispute: named scope and exclusions, deliverables with acceptance criteria, payments tied to acceptance, named people, and written rules for data, integrations, testing, change orders, training, and go-live. Work through them in order, since the first four make the rest enforceable.
1. Scope by module, process, and phase, plus a written exclusions list
The SOW should name every module, business process, department, and phase in scope. Just as important, it should say what’s out.
Connecticut’s statewide ERP RFP is a good model here. It called out functions that were lower priority and might not make the first implementation effort, instead of leaving them vague. If something is Phase 2, the SOW should say so in writing. The same rule applies whether you’re implementing Tyler Technologies, Workday, Oracle, or Infor.
Good scope language looks like “procure-to-pay, including requisitions, three-way match, and P-card reconciliation,” not “Purchasing module.” Ask the vendor one question: what’s excluded? No exclusions section usually means a future dispute.
2. Deliverables, not activities
A deliverable is a work product you can review and formally accept. An activity is just effort.
Iowa’s state SOW checklist draws the line clearly: “configure system” is an activity, while “configuration guide completed” is a deliverable. The same guide rules out things like a kickoff meeting counting as a deliverable.
A few rewrites that make the difference obvious:
- “Conduct design sessions” becomes “signed future-state process design document for each module.”
- “Perform data conversion” becomes “mock conversion report reconciled to the GL trial balance.”
- “Provide training” becomes “role-based training materials and a completed session for each listed user group.”
Go line by line. If you couldn’t hand it to an auditor as proof of work, it’s an activity.
3. Objective acceptance criteria and a review window for every deliverable
Every deliverable needs criteria that someone outside the project could check, a named person who accepts it, and a set number of days to review.
Iowa’s guidance is blunt: without acceptance criteria, the agency has no footing to reject poor work. Georgia’s technology authority builds the same idea into its SOW template, asking for criteria, an accepting owner, and an agreed delivery date for each deliverable.
Watch for “deemed acceptance” language, where silence for a few days counts as approval. Set a review window your staff can actually meet while doing their day jobs, and spell out what happens after a rejection.
4. Payment tied to acceptance, with retainage held until go-live
Payments should follow accepted deliverables. Nothing gets paid at signing, and nothing gets paid just because another month went by.
Iowa doesn’t allow payment upon SOW signing and tells agencies to use “payment upon acceptance” instead of “payment upon completion.” Madera County’s SOW guidelines push departments to make sure the SOW gives them a way to withhold payment.
On top of that, hold back a meaningful percentage of each payment until final acceptance after go-live. Once the build is done, retainage is about the only leverage you have left.
5. Your responsibilities and staffing assumptions, in writing
The SOW should list what your team must provide (people, decisions, data, system access) and by when. Vendors bury these in an “assumptions” section for a reason.
Nanaimo, British Columbia ran into exactly this. Its council added $1.9 million to the ERP budget, bringing it to $5.1 million, partly because the city couldn’t fill the dedicated project roles in the original plan. Staff ended up splitting time between operations and the project.
Read every staffing assumption, like “client provides two full-time payroll SMEs,” and decide honestly whether you can meet it. If you can’t, budget for backfill now or renegotiate.
6. Named key personnel and a turnover clause
The people in the proposal should be the people on the project. Name them in the SOW.
When Grand Rapids explained its ERP cost growth, staff pointed to turnover on the implementation team slowing knowledge transfer. Put that risk in the contract, because a status report can’t enforce anything.
Ask for named key roles (project manager, functional leads, technical lead), your right to approve replacements, an overlap period at the vendor’s cost, and your right to request removal of someone who isn’t working out.
7. Data migration by object, history, mock loads, and reconciliation
The SOW should list every data object being converted, how many years of history come over, how many mock conversions happen, and how the results are proven.
“Data conversion” on its own means almost nothing. Spell out the objects: chart of accounts, GL balances, vendors, open POs, employee master, pay history, fixed assets, utility accounts. Then say who extracts, who cleanses, who maps, and who loads.
The ERP SOW guidance from Hyperbots recommends measurable acceptance criteria for migrated data. Require each mock load to reconcile to your legacy trial balance and payroll registers before it’s accepted. “Client responsible for data cleansing” is fine only if you know how many staff hours that really means.
8. Every integration listed by name, with an owner for each side
Integrations are where public-sector projects get surprised. The SOW should list each one by name, not as “standard interfaces.”
Grand Rapids saw this firsthand when a bank merger disrupted interfaces to the city’s systems mid-implementation. Outside parties change, and your SOW has to say who absorbs that work.
For each integration (bank and positive pay, state retirement and tax reporting, utility billing, courts, permitting, GIS, timekeeping, P-card), the SOW should state:
- The direction and frequency of the data flow
- The format, whether file-based or API
- Who builds the ERP side and who builds the other side
- Who tests it, and what counts as passing
9. Testing phases, defect severity levels, and exit criteria
The SOW should define each testing phase, what a defect is at each severity level, and the exit criteria for moving on.
At minimum, look for system integration testing, user acceptance testing, and at least one parallel payroll run comparing old and new systems to the penny. South Dakota’s model SOW even includes a system acceptance checklist as an appendix.
Push for written severity definitions (what makes something a Severity 1 versus a Severity 3), a retest process, and exit criteria like “no open Severity 1 or 2 defects.” Without them, “testing complete” means whatever the vendor’s calendar says.
10. A change-order process with approval authority, a rate card, and a council threshold
The SOW should spell out exactly how scope changes are requested, priced, approved, and tracked.
Iowa’s guidance calls a change order an amendment that should be used sparingly, with foreseeable work written into the SOW up front. Grand Rapids’ roughly $4.8 million in change orders shows what happens when that doesn’t stick.
A governed process includes:
- Who can request a change, on both sides
- A written impact estimate covering cost, schedule, and staff time
- Approval levels that match your purchasing ordinance and council threshold
- A rate card locked for the life of the project
- No work on a change before written approval
- A running change log reported at every steering meeting
Key insight: Every ERP project needs some change orders. The costly ones are the ones nobody had to justify in writing first.
11. Training and change management tied to your real configuration
Training should run on your configured system, using your own data. Generic sandbox demos don’t prepare anyone for go-live.
Birmingham’s auditors flagged a lack of effective and timely engagement with the operational teams who’d be end users during design and business change. That’s a scope gap, and an SOW can close it.
Check how many users and roles get trained, who builds the materials, whether “train-the-trainer” is the only model offered, and whether readiness checks happen before go-live. If the vendor only trains your trainers, plan for who trains everyone else.
12. Cutover, support through the first fiscal close, and knowledge transfer
The SOW should define go/no-go criteria, the cutover plan, and how long post-go-live support lasts. Tie that support to real events on your calendar instead of a fixed number of days.
Birmingham went live before its solution design was fully resolved. Written go/no-go criteria in the SOW give you the standing to say “not yet.”
Good hypercare language runs through your first month-end close, your first few payroll cycles, and ideally your first fiscal year-end. Add a defect warranty period, configuration documentation, and admin training so your team can run the system without the vendor in the room.
Red-flag phrases that mean the SOW isn’t ready to sign
Vague wording is the clearest sign an SOW will cost you later. The phrases below are common in vendor-drafted SOWs, and each one shifts risk from the vendor to you.
Swipe sideways to see the full table →
| Phrase you'll see | What it really means | Ask for instead |
|---|---|---|
| "Per [vendor] standard methodology" | The scope lives in a document you didn't sign | The specific tasks and deliverables written into the SOW |
| "Standard interfaces" | Only the integrations the vendor already has are included | A named list of every integration and its owner |
| "As needed" or "as required" | No limit on effort, so no commitment either | A fixed quantity: sessions, hours, mock loads, users |
| "Client will provide clean data" | All cleansing risk and cost is yours | A shared cleansing plan with named responsibilities |
| "Commercially reasonable efforts" | No obligation to actually hit the outcome | Measurable acceptance criteria |
| "Train-the-trainer" (and nothing else) | Your staff train everyone else | A user count and role list the vendor trains directly |
| "Deemed accepted after 5 days" | Silence during a busy week means approval | A realistic review window and written acceptance only |
| "Estimated hours" with no cap | Time-and-materials with no ceiling | A not-to-exceed amount tied to deliverables |
The GFOA’s 2026 guidance describes exactly this pattern: buzzwords and a generic methodology in place of a defined scope.
When you find one of these, don’t just strike it. Replace it with the specific language in the third column, and get the vendor to agree in writing.
Fixed fee vs. time-and-materials vs. deliverables-based: which protects a city best?
A deliverables-based fixed fee, paired with a small capped pool for approved changes, protects a public agency best. It ties every dollar to accepted work while still leaving room for the changes every ERP project has.
Swipe sideways to see the full table →
| Pricing model | How you pay | Who carries the risk | Best fit |
|---|---|---|---|
| Time-and-materials (T&M) | Hours worked × hourly rates | Mostly the agency | Small or genuinely undefined work, like a change pool |
| Fixed fee (lump sum) | One set price, usually on a calendar schedule | The vendor on paper, the agency through change orders | Narrow projects with fully defined scope |
| Deliverables-based fixed feeMy pick | A fixed price for each accepted deliverable | Shared, and tied to acceptance | Most public-sector ERP implementations |
Pure T&M gives you flexibility for scope changes, which is how the ERP contract review checklist from Top Dynamics Partners frames its main upside. The catch is that costs float with every requirement change, and nothing in the model rewards finishing on time.
A plain lump sum sounds safer than it is. When the price is fixed but the scope is fuzzy, every gray area becomes a change order, and that’s how a fixed-price project ends up nowhere near its fixed price.
My pick is the hybrid. Use a fixed price per accepted deliverable, hold retainage until stabilization, and set a not-to-exceed T&M pool for approved changes at locked rates. Your council sees one predictable number, and the vendor only gets paid for work your team has signed off on.
Who should review the SOW before it goes to council?
At least five people should read the SOW before it reaches your council or board, and one of them should have no stake in the sale.
- Finance director or controller. Checks GL, budget, and year-end close scope, plus the payment schedule.
- HR and payroll lead. Checks pay rules, parallel payroll runs, and benefits and retirement integrations.
- IT lead. Checks integrations, security, hosting, and who owns each technical task.
- Procurement and the city attorney. Check alignment with the master agreement, your purchasing ordinance, and change-order authority.
- An independent advisor. Reads it from your side of the table. A state and local government ERP consultant with no reseller or integrator ties fits this seat.
That last seat matters more than it looks. The GFOA’s ERP advisory practice, for example, treats statement of work development as its own service, separate from software selection.
Timing matters too. The best time to shape the SOW is during the RFP and shortlisting, not after you’ve picked a vendor and lost your leverage. KCT’s vendor-neutral ERP selection advisory works at that earlier stage, and the ERP Tools Directory is a quick way to compare the platforms your shortlist is built on.
Already signed and the project’s slipping? A clear-eyed SOW review is usually the first step of an ERP recovery, because it shows exactly what the vendor owes you.
FAQs
What should be included in an ERP statement of work?
An ERP statement of work should include scope by module and phase, deliverables with acceptance criteria, both parties’ responsibilities, named key personnel, data migration and integration details, testing and exit criteria, a change-order process, training, cutover, and post-go-live support. Every payment should be tied to an accepted deliverable.
What’s the difference between an SOW and a contract?
A contract, or master agreement, sets the legal terms: liability, warranties, data ownership, and termination. The statement of work defines the actual work, meaning what gets built, delivered, tested, and paid for. In government ERP deals, the SOW is usually an exhibit to the contract, so the two are binding together.
Who writes the SOW for a government ERP project?
The vendor or system integrator usually writes the first draft, since it knows its own methodology and pricing. The agency should shape it early, ideally by attaching a model SOW to the RFP. Then finance, IT, legal, and an independent advisor should redline the vendor’s draft line by line.
How long should an ERP implementation SOW be?
An ERP implementation SOW should be as long as it takes to define every deliverable and acceptance test. South Dakota’s model SOW for a statewide ERP ran 33 pages. Specificity matters more than length, though. A short SOW with named deliverables beats a long one padded with methodology.
Can you change an SOW after it’s signed?
A signed SOW can be changed through a change order, which is a formal amendment to scope, cost, or schedule. The SOW itself should define how change orders are requested, estimated, approved, and logged. In the public sector, changes above a set dollar threshold often need council or board approval.
How long does a public sector ERP implementation take?
A public sector ERP implementation typically runs 12 to 24 months, depending on the number of modules, data complexity, and integrations. Timelines slip most when scope and data migration are underestimated in the SOW. A realistic schedule starts with a realistic, fully written scope.
What are the biggest red flags in an ERP SOW?
The biggest red flags in an ERP SOW are vague phrases that shift risk to the agency, like “per vendor methodology,” “standard interfaces,” “as needed,” “client will provide clean data,” and deemed-acceptance clauses. Each one lets the vendor decide what was promised. Replace them with named lists, fixed quantities, and measurable acceptance criteria.
Where to start
Once the build starts, nobody goes back to the sales demo. The statement of work is what your integrator is actually held to, and every vague line in it gets paid for with public money later.
So before your next ERP contract goes to council, run the SOW against these 12 items. Rewrite anything that reads like an activity, a methodology, or an “as needed.” If it isn’t written down, assume it isn’t included.
And if you’d rather have someone on your side of the table hold the integrator to that SOW from kickoff through your first fiscal close, take a look at KCT’s full-spectrum ERP implementation service. A 30-minute discovery call is enough to find out where your SOW is exposed.