ERP Governance Best Practices for Long-Term Success

Most ERP projects have a steering committee. Fewer have governance. The two get treated as synonyms, and that mix-up is part of why so many implementations run into trouble somewhere between kickoff and the moment the system starts paying for itself.

A steering committee is a group of people. Governance is a system: who decides what, how fast a decision has to move, what happens when people disagree, and how all of that changes as the project moves from planning into execution and then into everyday operation. You can have a well-staffed steering committee and still have weak governance, because nobody wrote down what the steering committee is actually supposed to decide versus what should be handled two levels down.

This article is about that system. If you want the deep dive on building and running an effective steering committee itself, that’s covered in our other blogs. Here, we’re zooming out to the structure the committee sits inside.

What a Governance System Should Include

A governance plan is a document, and it should exist before implementation begins, not get assembled retroactively once something goes wrong. At minimum, it needs to answer a handful of questions plainly enough that a new project team member could read it and understand how decisions get made without asking around.

The plan should define:

• A charter — what the governance structure exists to do, and what it explicitly does not cover
• Decision rights — who can approve what, at what dollar or scope threshold, without escalation
• Escalation paths — what happens when a decision exceeds someone’s authority or two stakeholders disagree
• Meeting cadence — how often each governance body meets, and what changes that cadence
• Reporting structure — what gets reported up, in what format, and how often
• Change control — how scope changes get evaluated, approved, and documented

The steering committee is one piece of this, usually the body that handles the highest-stakes decisions and cross-functional conflicts. But it’s not the whole system and treating it as the whole system is where a lot of governance plans fall short. If the steering committee is the only defined decision-making body, every decision of any size ends up funneled to a monthly meeting, which is a slow and expensive way to run a project.

Decision Rights Before You Need Them

The fastest way to stall an ERP implementation is to leave decision authority ambiguous until the moment a decision actually needs to be made. At that point, someone has to figure out who’s allowed to say yes, usually under time pressure, and the answer often becomes “let’s ask the steering committee” by default, whether or not the decision warrants that level of involvement.

A decision-rights framework fixes this before it becomes a bottleneck. It doesn’t need to be complicated. For most ERP projects, three tiers cover the majority of decisions:

• Project manager level — day-to-day configuration choices, minor timeline adjustments, resource scheduling within an approved plan
• Sponsor or project lead level — moderate scope changes, budget variances within a defined range, cross-team prioritization conflicts
• Steering committee level — major scope changes, budget increases beyond the sponsor’s authority, go/no-go decisions at key milestones, and anything that shifts the business case

Writing these thresholds down and getting sign-off on them early does two things: it keeps small decisions moving without waiting on a committee calendar, and it protects the steering committee’s time for the decisions that actually need executive judgment. Teams that skip this step tend to swing to one of two extremes: either everything gets escalated and the project crawls, or nothing gets escalated and scope drifts quietly until someone notices the project has changed shape.

Transformation is not easy, but it doesn’t have to be impossible. Take control of your project’s success today and schedule a free 30-minute consultation to find out how Victoria Fide can equip you for transformational success.

Governance That Changes Shape Across the Lifecycle

A governance plan written on day one shouldn’t look identical to the governance plan in use six months later. The structure needs to flex as the project moves through its phases, and organizations that treat governance as a static document tend to find it stops fitting the work.

Early on, governance work is mostly foundational: writing the charter, defining decision rights, identifying who sits on which body, and setting the initial cadence. This is also when readiness gaps tend to surface, so governance and readiness assessment work often happen in parallel.

Once execution is underway, the cadence typically tightens. Change requests start arriving more frequently, cross-functional conflicts become more common as teams hit real constraints, and the steering committee usually shifts from monthly check-ins to something closer to biweekly, at least during the more demanding stretches. This is also where the change control process gets put to the test, since scope pressure tends to show up here rather than earlier.

Then comes the phase that often gets the least governance attention of the three: the period after go-live, when the system is running but the organization is still adjusting to it. This is where governance most often quietly stops functioning altogether.

Why Governance Erodes After Go-Live

The project team that built and ran the governance structure typically disbands shortly after go-live. The steering committee stops meeting or meets far less often. The governance plan, if anyone still has it open, gets treated as a closed document rather than a living one. And for a while, this doesn’t seem to matter, because the system is live and things appear to be working.

The problems show up later, usually when decisions that used to have a clear owner start falling into a gap. Nobody is quite sure who approves a configuration change six months post-go-live. Workarounds that were supposed to be temporary don’t get revisited because no governance body is checking on them. We’ve written about this failure pattern in detail, including how it tends to compound with adoption erosion, in a previous piece on why transformation initiatives fail after go-live.

The fix doesn’t require keeping the full project governance structure running indefinitely. It requires a deliberate handoff to a lighter, ongoing version: a named system owner, a reduced-cadence forum (quarterly is usually enough) to review outstanding decisions and system health, and an escalation path that still exists even though the original project team has moved on. Governance shouldn’t disappear after go-live. It should downsize on purpose, rather than disappear by neglect.

Bringing It Together

None of this exists separately from how we think about the broader arc of a transformation. In Prepare, governance gets defined alongside everything else that sets the project up to succeed. In Execute, it gets tested and, ideally, holds. And in Sustain, it has to survive the handoff from a dedicated project team to whoever owns the system day to day going forward. Governance that only works during Execute isn’t really governance. It’s a temporary structure that happened to be in place while people were paying close attention.

Governance Plan Checklist

Before your next ERP implementation kicks off, or if one is already underway and governance feels informal, a few things worth confirming:

• A written governance plan exists that is more than an org chart
• Decision rights are documented across at least three tiers, with clear thresholds
• Escalation paths are defined, not assumed
• Meeting cadence is set for each governance body, with a plan for how it changes across phases
• A change control process exists and is being used, not just referenced
• A post-go-live governance model is defined before go-live, not after

If you’re not confident on several of these, our DX Implementation Risk Assessment evaluates governance readiness alongside five other domains that consistently influence implementation outcomes and provides you with specific action plans to mitigate the risks.

Strong governance doesn’t happen by accident, and it’s one of the areas we see organizations underinvest in most consistently. If you want help building a governance structure that holds up from kickoff until well past go-live, explore our ERP Project Management & Governance services.