Hiring an ERP consultant: what a fair scope looks like

Why agencies bring in outside help

Most finance directors and city managers replace an ERP once in a career. Vendors do it every month. That gap in experience is what a consultant is meant to close — not to take the decision away from you, but to make sure the decision is yours and not the vendor's.

A fair engagement has three distinct stages, and each one should appear in the scope as its own line of work: needs assessment, selection support, and implementation oversight. Public RFPs from cities across the country describe this same three-phase pattern, because it matches how the work actually unfolds.

Stage one: needs assessment

Before anyone looks at software, the consultant should document how work moves today — how invoices get approved, how payroll runs, how utility bills are calculated and corrected, what reports the council and auditors actually ask for.

The output of this stage is a requirements document written in your agency's language, not a vendor's feature checklist. If a consultant proposes skipping this stage and going straight to demos, that is the first red flag.

• Interviews with the staff who do the work, not only department heads
• A written inventory of current systems, integrations, and manual workarounds
• Requirements ranked by what breaks if they are missing
• A data-readiness note: what records exist, where, and in what condition

Stage two: selection support

Here the consultant helps you write the RFP, score proposals, and run demonstrations. The key word is helps. Scoring criteria should come from your requirements document, and your staff should sit in every demo with scripted scenarios from their own daily work.

Watch for consultants who steer toward one vendor early, or who receive referral fees they do not disclose. Ask directly how the firm is paid and whether it has any relationship with the vendors on your shortlist. A fair scope states the answer in writing.

Stage three: implementation oversight

Once a vendor is selected, the consultant's job changes. Now they sit on your side of the table during implementation: reviewing the vendor's plan, checking that migrated data reconciles, and flagging scope drift before it becomes a change order.

This stage is where agencies most often under-scope. Implementation is where the money is spent, and it is where an independent set of eyes pays for itself. A fair scope includes regular checkpoints, data reconciliation sign-offs, and a clear definition of what done means.

What a fair scope includes, in writing

However the engagement is structured, the written scope should answer these questions before you sign:

• Which stages are included, and what each one costs separately
• Who does the work — named people, not just a firm name
• What the deliverables are for each stage, and what format they take
• How the consultant is paid, and whether any vendor relationship exists
• What happens if the project pauses or the vendor relationship fails

Red flags

A scope that jumps straight to software demos. A consultant who cannot name the people who will do the work. Deliverables described as activities rather than documents you can hold. And any hesitation when you ask about vendor relationships.

None of these mean a firm is dishonest. But a fair scope survives these questions easily, and a firm that welcomes them is telling you something useful about how the engagement will go.