The pattern in ERP failures
Enterprise resource planning implementations in state government fail for reasons that are well-documented and, by now, largely predictable. The federal Technology Transformation Services' De-risking Government Technology guide was developed precisely because the same failure modes appeared across federal and state projects: large upfront requirements documents that locked design before users had validated anything, single vendors accumulating technical knowledge the government side could not independently evaluate, and acceptance testing criteria defined by the party being evaluated.
Those are process failures, not product failures. The ERP software market offers mature platforms that state agencies in other jurisdictions operate successfully. When similar products produce different outcomes in different states, the explanation is usually in the state's organizational conditions at the time of procurement — not in the vendor's product catalog.
GAO's 2021 High-Risk Series on IT Acquisitions and Management documents that federal IT investments "too frequently fail or incur cost overruns and schedule slippages" and identifies management weaknesses — unclear requirements ownership, insufficient oversight capacity, and governance that cannot evaluate technical claims — as recurring contributors. These patterns translate directly to state ERP contexts.
The argument here is simple: an ERP contract has a vendor side and an agency side. Vendor selection and contract terms govern the vendor side. But the agency side — its organizational readiness to execute — is almost never part of a pre-procurement evaluation. That asymmetry is where failures begin.
Five organizational prerequisites
1. Data governance with a named owner
An ERP implementation requires the state to provide clean, consistent reference data before the vendor can configure anything. Chart of accounts, position classifications, vendor master files, agency identifiers, appropriation codes — these all require someone to make authoritative decisions about what the data should look like.
If no one has that authority before the project starts, the vendor becomes the de facto data governance authority by default. The project team makes data decisions to keep the timeline moving; those decisions accumulate into an architecture no agency executive has reviewed or approved. By the time inconsistencies surface in UAT or post-go-live reconciliation, the choices that created them are buried deep in configuration history.
A state ready to run an ERP modernization can name the person — a specific title with designated authority, not a committee — who owns each major data domain and can make binding decisions when disagreements arise. If that person doesn't exist before the contract is signed, data governance is a gap that the vendor cannot close.
2. Process authority above the project team
ERP systems standardize processes. That is their value proposition. Standardization across a state enterprise means some agencies will be required to change workflows, approval structures, and reporting practices they have run for years.
The project team will encounter resistance. That resistance requires someone with the authority to say: the new process applies to your agency, and exceptions require documented approval at a level above this project. Without that authority sitting clearly above the implementation, every agency that pushes back will find that resistance rewarded with a custom workaround — and the ERP's long-term maintenance complexity grows with each workaround added.
Process authority is not the same as executive sponsorship, though the two are related. An executive sponsor endorses the project; process authority means someone has the formal power to mandate compliance with standardized workflows across organizational boundaries. The project manager does not have this power. The agency CIO typically does not have it either. It usually requires a directive from the budget office, the governor's office, or statutory language. State agencies entering an ERP modernization should resolve whose signature can compel a reluctant department to accept a standard process before the vendor presents any design options.
3. Change management budget, separate from implementation
Vendor contracts include training. They do not include organizational change management in any meaningful way, nor should they — the vendor has no standing relationship with the state's workforce, no knowledge of which job families will be most disrupted, and no visibility into the informal knowledge networks that hold current processes together.
Organizational change management (OCM) covers the work of preparing the workforce for a fundamentally different set of tools and processes: identifying which roles change substantially, developing transition plans for those roles, communicating at the right intervals through the right channels, and sustaining momentum when the project hits a difficult stretch. This work requires people inside the organization who understand it.
State budget requests for ERP implementations routinely include line items for software licensing, implementation services, and infrastructure. Separate OCM funding appears infrequently, and when it does, it is often sized as a percentage of implementation cost without a grounded analysis of what the change actually requires. The predictable result is that implementation proceeds on technical milestones while the workforce preparation lags — and go-live becomes a crisis moment rather than a prepared transition.
A pre-procurement readiness question: does the state have an identified OCM program with dedicated staffing, a budget that was built from role-impact analysis rather than percentage allocation, and a timeline that begins well before system testing rather than at go-live? The honest answer to that question is a better predictor of ERP outcomes than the vendor's reference list.
4. Contract oversight capacity
An ERP contract that runs multiple years and significant budgetary commitment requires an agency team capable of evaluating what the vendor actually delivers. Not project managers who review status reports — people who can assess whether acceptance testing criteria are valid, whether delivered functionality matches requirements, and whether a claim of completion is supported by evidence.
This capability is not common in state agencies, and it is not something vendors are incentivized to help develop. Independent verification and validation (IV&V) contracts exist for this purpose; many large state IT procurements include them. But IV&V contractors are only useful if the state's governance structure is willing to act on what IV&V finds — and if the state program office has enough technical capacity to evaluate competing claims from the vendor and IV&V about the same deliverable.
A state that lacks in-house technical capacity to evaluate ERP work — or that has not procured independent IV&V with clear authority to escalate findings — is in a structurally weak position relative to any experienced systems integrator. The gap will surface at the first significant scope dispute.
5. Governance with technical representation
Major ERP implementations accumulate decisions that are simultaneously technical and programmatic: whether a proposed workaround is acceptable or creates long-term risk, whether a timeline slip requires recovery resources or a rescoped contract, whether a struggling program should be restructured or terminated. These decisions require a governance body that can evaluate technical claims.
Steering committees for state ERP programs often include agency finance directors, HR executives, and procurement officers. They are well-positioned to evaluate business process questions. They are typically not positioned to evaluate whether a vendor's technical explanation for a delay is credible, whether proposed architectural changes carry hidden risk, or whether the testing approach the vendor describes will actually validate what it claims.
Adding technical representation to ERP governance — an enterprise architect, a CTO, or a senior technical advisor with independent standing — does not slow governance down. It changes what governance can see. Decisions that would otherwise be made on vendor-provided framing can be made on the basis of an independent technical assessment. States that have this structure make different decisions at decision points than states that don't.
The pre-procurement assessment
An agency approaching an ERP modernization can use these five prerequisites as a structured readiness assessment before issuing a solicitation. The questions are direct:
- Data governance: Can you name the person who owns each major reference data domain and will make binding decisions? If the answer is a committee, data governance is a risk.
- Process authority: Can you identify the document, directive, or authority that compels every affected agency to adopt standardized workflows? If it requires negotiation at go-live, process authority is a risk.
- Change management: Is OCM funded as a discrete program with staffing and a pre-go-live timeline, or is it a percentage added to the implementation budget at the end? If the latter, OCM is a risk.
- Contract oversight: Does the state have internal capacity to evaluate vendor deliverables, or does it depend entirely on the vendor's own reporting? If internal capacity is absent, oversight is a risk.
- Technical governance: Does the steering committee include someone with the standing to challenge technical claims from the vendor? If not, governance is a risk.
None of these questions require the vendor's participation to answer. They are organizational questions about the state's own capacity, and they should be answered before a procurement strategy is finalized.
An agency that addresses gaps before the RFP is in a fundamentally different position than one that lists similar prerequisites as vendor deliverables. The difference is not whether the work gets done — vendors will fill organizational vacuums. The difference is whether the state retains the capacity to evaluate and govern what the vendor does.
Sources and further reading
- Technology Transformation Services, De-risking Government Technology — field guide for state and federal program managers on reducing IT project risk; includes the De-risking Custom Technology Projects handbook for state budget officers
- GAO, High-Risk Series: IT Acquisitions and Management (GAO-21-119SP) — 2021 High-Risk Series covering recurring IT management weaknesses across the federal government (patterns applicable to state ERP context)
- National Association of State Chief Information Officers (NASCIO), annual State CIO surveys — data on state priorities and capacity
—-
Spartan X has worked alongside state executive leadership at the program office level — assessing organizational readiness, structuring program governance, and helping agencies identify and close the precondition gaps that determine whether a major technology investment succeeds. The pattern in ERP modernization is the same pattern that appears across state technology program delivery: the technical selection is usually the smaller risk. The organizational conditions surrounding it are where outcomes are decided.
