Enterprise resource planning replacements in local government have a poor delivery record: extended timelines, substantial change orders, and go-lives that stabilise a year later than planned. The causes recur with enough regularity to be treated as a checklist, and most of them are locked in before implementation begins.
Cause one: requirements written as a feature list
Requirements documents assembled by asking each department what the current system does produce a specification for the current system. Vendors respond that they can do all of it — usually truthfully, via configuration or customisation — and the entity purchases a re-implementation of a twenty-year-old process design at modern prices.
The alternative is to specify outcomes and constraints: what must be produced, what statutory and audit requirements apply, what integrations are non-negotiable, what data must migrate. Then require vendors to demonstrate the entity's own scenarios — a real payroll cycle with its actual bargaining unit rules, a real close, a real budget adoption — using the entity's data rather than a scripted demonstration.
Cause two: underestimating data migration
Migration is routinely allocated a fraction of the effort it consumes. The reasons are consistent: chart of accounts restructuring that turns out to be a redesign rather than a mapping; historical data whose quality is unknown until someone attempts to load it; sub-ledgers reconciled to the general ledger in aggregate but not in detail; and fixed asset records that have not been physically verified in a decade.
Practical mitigation is to begin data profiling during procurement, before a vendor is selected. Knowing that eleven per cent of vendor records lack a valid tax identifier changes the scope conversation materially, and it is discoverable in a week.
Decide the customisation posture and write it down
Every customisation is a permanent cost: it must be retested at each upgrade and it constrains future options. Entities that do not set an explicit posture accumulate customisations one reasonable request at a time. A defensible rule is that customisation requires a documented statutory or bargained requirement that configuration cannot meet, approved by the steering committee, with the ongoing cost stated. Preference is not a reason.
Cause three: no dedicated staffing
Backfill is the most reliable predictor of schedule performance and the most frequently cut line in the budget. Subject matter experts who are expected to design, test and migrate while also closing the books each month will do the second and defer the first. The consequence appears at user acceptance testing, which becomes the first genuine review of configuration decisions made months earlier.
A realistic estimate is that key functional leads are needed at fifty to eighty per cent of their time for the duration. If the entity cannot fund backfill, the schedule should be extended to reflect the capacity that actually exists.
Cause four: governance without authority
Implementations generate a steady flow of decisions that cut across departments — chart of accounts structure, approval hierarchies, whether a long-standing departmental practice will continue. A steering committee that can only escalate rather than decide converts each of these into a delay. The committee needs a chair with authority to decide over departmental objection, and a standing decision log.
Cause five: testing treated as a phase
Testing compressed into the weeks before go-live becomes a confirmation exercise. The alternative is continuous: unit testing as configuration proceeds, integration testing at each milestone, at least two full parallel payroll cycles, and a complete mock close on migrated data. The mock close is the most informative single test and the one most often skipped for lack of time.
Cause six: no plan for the year after
Go-live is the beginning of the difficult period. Reports that existed in the legacy system do not exist yet; users are slower; the first close takes twice as long; and the first audit under the new system generates questions about migrated balances. Budgeting for post-go-live support at a level comparable to the implementation year, and setting expectations with the governing body accordingly, prevents the project being declared a failure during its normal stabilisation.
What good procurement looks like
- Scenario-based demonstrations using the entity's data, scored by the people who will use the system.
- Reference checks with entities of comparable size and complexity, including at least one implementation that went badly.
- Implementation partner named and key personnel committed contractually, with substitution rights.
- Payment milestones tied to acceptance, not to elapsed time.
- Data migration scope and responsibility stated explicitly, including who cleanses.
- Total cost of ownership over ten years, including hosting, support, upgrades and the entity's own staffing.
This publication is general information and is not legal, accounting, audit or financial advice. See our Disclaimer. Found an error? Write to [email protected] — we correct in place and note what changed.