Running ERP Projects: Governance, Not Gantt Charts

Sixty percent of ERP projects run over budget, and the reason usually isn't the software — it's that nobody was assigned to say no. A mid-market manufacturer with an original $1.8 million budget watched that number climb to $2.6 million over fourteen months because change requests kept getting approved in hallway conversations instead of a change control board. The project manager's actual job on an ERP rollout isn't tracking a Gantt chart. It's governance: deciding what's in scope, who can change that, and what happens when a deadline and a budget disagree.

The steering committee is not a status meeting

Most ERP steering committees devolve into a monthly slide deck where the PM reports green/yellow/red and nobody makes a decision. A steering committee that works has three things: real decision authority (can approve budget changes up to a defined threshold, say $50,000, without going back to the CFO), a fixed cadence tied to the project's rhythm (biweekly during design and build, weekly during testing and cutover), and mandatory attendance from people who can actually commit resources — not delegates who have to "check with their boss." If your steering committee can't approve a two-week schedule slip in the room, it's not a steering committee, it's an FYI meeting.

RAID logs that get read, not filed

Every ERP project has a risk register. Most of them are spreadsheets nobody opens after week three. The difference between a RAID log (risks, assumptions, issues, dependencies) that works and one that's decoration is ownership: every line needs a named individual, not a department, and a due date, not "ongoing." At the manufacturer above, the risk that eventually blew the budget — "legacy inventory data has no reliable unit-of-measure conversion table" — sat in the RAID log for six weeks with the owner listed as "IT" before anyone actually assigned a person to resolve it. Review the RAID log as the first agenda item in every steering committee meeting, five minutes, no exceptions, and closed items get archived, not deleted, so you can show auditors and future project teams what actually happened.

Change control: the discipline that saves the budget

Scope creep on ERP projects rarely arrives as one big decision. It arrives as forty small ones: "can we also track serial numbers on this SKU category," "can the approval workflow have a fourth tier," "can we keep the old report format just for this one department." Each one sounds reasonable in isolation and each one costs configuration or custom development hours. A functioning change control process requires every request to go through a one-page impact assessment — hours, cost, schedule effect, and which requirement it maps to — before anyone touches the system, and a defined approver (usually the steering committee for anything over a set dollar threshold, the PM for anything under it). Track the count: if you're seeing more than roughly one approved change request per week during the design phase, that's a sign requirements gathering was rushed, not that users are being difficult.

Managing the systems integrator, not just the software

If you're using an implementation partner, the PM's job includes managing that relationship as a vendor contract, not a friendship. Fixed-bid contracts protect your budget but create an incentive for the SI to minimize hours on your requirements; time-and-materials contracts protect quality but put budget risk back on you. A hybrid — fixed bid for defined phases (design, configuration) with T&M for a change order pool — tends to work best because it forces both sides to nail down scope early while leaving room for the inevitable adjustments. Hold 10-15% of each milestone payment until user acceptance testing passes for that phase, not just when the SI says it's done; "done" and "working" are not the same claim.

The resourcing mistake almost everyone makes

The single most common governance failure isn't a vendor problem, it's an internal one: subject matter experts get assigned to the project at 50% time while their manager still expects 100% of their regular job. Nobody adjusts the SME's actual workload, so the ERP work happens in evenings and gets rushed, and requirements gathering suffers for it. Before the project starts, the PM needs a written, signed resourcing plan naming each SME, their percentage commitment, and — critically — what gets taken off their plate to make room. If their manager won't sign that document, that's a steering-committee-level risk, not something to quietly absorb.

Budget tracking and the contingency reserve

Track spend against budget by workstream, not just in total — a project that's 5% over overall but 40% over on data migration specifically is telling you something the aggregate number hides. Hold a contingency reserve of 15-20% of total project cost, separate from the line-item budget, and require steering committee approval to draw from it. That reserve exists precisely for the RAID items that turn real (the unit-of-measure conversion problem, the vendor's underestimate on a complex integration) and it should never get quietly absorbed into workstream budgets before the project even hits testing.

The communication plan nobody writes down

Executives want a monthly risk-adjusted summary. End users want to know when their screens are changing and what training looks like. IT wants technical details on integration timing. Treating all three audiences with one weekly status email is how you end up with a factory floor supervisor blindsided by a go-live date nobody told them about. Write a one-page communication plan mapping each audience to its cadence, channel, and level of detail, and assign a named owner for each — the PM shouldn't be personally drafting the floor-level training announcements the night before cutover because nobody else owns that channel.

Five governance artifacts to have before kickoff

1. A RAID log with named owners, reviewed weekly
2. A change control form and a defined approval threshold
3. A signed resourcing plan for every SME, with backfill commitments
4. A steering committee charter defining decision authority and cadence
5. A milestone payment schedule tied to user acceptance testing, not vendor sign-off

None of these require project management software. They require someone willing to say no to a reasonable-sounding request in week nine because it wasn't in the original scope, and a governance structure that backs that decision up.

Governance doesn't end at go-live

Most ERP project governance structures — the steering committee, the RAID log, the change control board — quietly dissolve the week after go-live, right when a different kind of governance is actually needed most. The 30-60 day hypercare period generates its own stream of issues: workarounds users adopted during testing that turn into bad habits, configuration gaps that only show up under real transaction volume, and a wave of "can we just add this one field" requests from users now that they're actually living in the system daily. Keep a lightweight version of the same governance running through hypercare — a reduced RAID log, a weekly check-in, and the same change control discipline for post-launch requests — rather than treating go-live as the end of the PM's real job. The manufacturer whose $1.8 million project grew to $2.6 million during build made a second, quieter mistake after go-live: it disbanded the change control board immediately, and absorbed another $140,000 in "small" post-launch customization requests over the following four months with no formal review process at all.

The other governance gap at this stage is ownership transfer: the external PM or SI project lead typically rolls off within weeks of go-live, and unless an internal system owner has been explicitly named and trained during the project — not appointed as an afterthought once the consultant's contract ends — institutional knowledge about why the system was configured a certain way leaves with them.