ERP programme governance: keeping your project on course

Three months before the planned go-live, your project manager reports: “We are on schedule.” The steering committee nods. Four months later the project is five months behind schedule and well over budget. How is that possible if everything was “on schedule”?

Behind that overrun there is no single incident. There is a pattern underneath, and there are people underneath. A project manager who reports “on schedule” while his gut says otherwise. A team leader on the floor who raised the signals, but never saw them reach the top. A director who only hears what is going on once correcting course has already become expensive. The project did not drain away in a single day. It drained away in the silence between what people knew and what the steering committee heard.

This is the core problem of ERP programme governance in most organisations. Not the technology. Not the implementation partner. Not the chosen package. The management layer that is meant to check whether the project is heading in the right direction rarely has the information, the mandate or the independence to steer for real.

ERP projects almost never fail on a technical problem. They fail on a governance problem: oversight that intervenes too late, ownership that no one claims, escalation paths that exist on paper but are never used.

What is ERP programme governance?

ERP programme governance is the management layer that determines who takes which decisions in an ERP project, how oversight is organised and how escalation works when the project drifts off course.

This is what distinguishes governance from project management. Project management focuses on day-to-day delivery: activities, schedules, deliverables, teams. Programme governance focuses on the management layer: have the right decisions been taken, are the risks sufficiently visible, is the project still aligned with the organisation’s goals?

A steering committee that meets monthly for a progress update from the project manager is not exercising governance. It is receiving reports. Governance means actively steering on risk, ownership and course correction, throughout the entire project.

ERP programme governance has three components:

Decision-making structure: who takes which decisions, with what mandate, on the basis of what information?

Oversight structure: who checks whether the project is on course, what are the escalation paths, and how is the counterweight organised?

Accountability structure: who is ultimately responsible when things deviate, and how is that arranged contractually and internally?

If one of these three components is missing, you have a governance gap, even when your steering committee formally exists and meets regularly.

Four management gaps that cause ERP projects to stall

Drawing on our experience, with 265+ specialists active in ERP projects, we see four patterns that recur structurally in organisations whose ERP project overruns or stalls.

1. Progress versus risk

Project managers report what they can measure: activities completed, budget consumed, milestones reached. What they report less well: which decisions have been postponed, which requirements are still unclear, which dependencies fall outside the scope.

A steering committee that only receives progress reports has a distorted picture of reality. It sees what has been done. It does not see what is still needed to succeed.

2. Delegating versus letting go

In many organisations, ERP projects are delegated entirely to a project team. The management team has “confidence in the team” and does not want to micromanage. That is understandable. But there is a fundamental difference between delegating and letting go.

Delegating means: a team with a mandate to lead the project, within clear boundaries and escalation points. Letting go means: the team is busy, and you hear something about it at the quarterly report.

Many ERP projects that stall begin with the second.

3. Missing counterweight

Project teams are under pressure to meet deadlines and respect budgets. That leads to optimistic reporting, sometimes unconsciously. A healthy management layer has a deliberate counterweight built in: someone who questions the project information critically, reads the risk log and probes further, and picks up signals from outside the project team, from users, department heads and future system managers.

Without a counterweight, governance drifts into a nodding exercise.

4. No working escalation path

What happens when a project manager has a critical finding that the steering committee would rather not hear? What if a supplier has made unrealistic commitments and no one wants to name it officially?

In too many projects: nothing. There is no formal escalation path for management issues that fall outside day-to-day progress. Those issues disappear into the wings, until they become unavoidable.

The five governance roles that complete your steering committee

Effective ERP programme governance does not call for a larger steering committee. It calls for the right roles with the right mandate.

Role	Responsibility	Pitfall
Project sponsor	Ultimate accountability, GO/NO-GO decisions, final escalation point	Too little availability; delegates everything to the steering committee
Steering committee chair	Agenda ownership, facilitating decisions, guarding the boundaries	Chairs meetings but does not steer on decisions
Independent overseer	Critical assessment of progress, risk signalling	Absent entirely, or drawn from the implementation partner
Project lead	Day-to-day control of the project team and supplier	Reports progress without escalating risk
Change management owner	Securing adoption, communication, user readiness	Appointed too late; not on the steering committee

If two roles sit with the same person, or one of the five is missing, you have a governance gap. The most common one: the independent overseer is missing, or that role is filled by a representative of the implementation partner, which creates a structural conflict of interest.

ERP programme governance does not begin with the steering committee. It begins with the question: who has the mandate to correct the supplier, even when that is a difficult conversation?

Programme governance check: eight questions for your steering committee

Answer the eight questions below for your current or upcoming ERP project. Every “no” or “I don’t know” is a concrete indication that your management layer needs strengthening.

Decision-making structure

Is there a RACI matrix that sets out exactly who takes which decision in the ERP project, including scope changes and budget overruns?
Is there a formal escalation path described for conflicts between the project team and the implementation partner?

Oversight and risk information

Does the steering committee receive, alongside progress reports, an explicit risk register, including mitigation status per risk?
Is there an independent party (internal or external) that periodically tests the project information for completeness and accuracy?

Ownership

Is there a single named person ultimately accountable, with the authority to drive decisions through to the GO/NO-GO point, including the power to hold the supplier to account contractually?
Is change management ownership explicitly assigned to a person with a mandate, separate from and independent of the technical project lead?

Supplier control

Do you have contractual agreements on reporting frequency, escalation obligations and the duty to correct deviations from the implementation partner?
Does a neutral party periodically assess the output of your implementation partner, without a commercial interest in progress?

Scoring guide:

7 to 8 times yes: Governance foundation in place. Strengthen the independence of the overseer and the frequency of risk reporting.
4 to 6 times yes: Governance gaps present. Prioritise the escalation path and the organisation of independent oversight.
0 to 3 times yes: Structural governance risk. Immediate action required, before the next project phase begins.

When should you take action?

Eight signals that your ERP programme governance is insufficient:

Your steering committee hears about a problem for the first time at the point where it is already too late to solve it easily.
The project manager and the steering committee structurally hold different pictures of the project status.
Decisions on scope, budget or planning are taken by the project team without explicit steering committee approval.
Users informally indicate that the system does not fit their work process, but that never reaches the steering committee.
Your implementation partner sets the agenda for the steering committee meeting.
There is no register of open decisions with an owner and a deadline.
Risks are reported, but there is no explicit follow-up on mitigation measures.
No one in the organisation has the mandate to hold the supplier to account for deviations.

If you recognise three or more of these signals in your current project, then an external view of your management layer is probably the most valuable step you can take right now. Not because the project team is falling short, but because a neutral party sees what those closely involved no longer see.

When is external governance support not needed?

External oversight is not always the right step. For small ERP projects with fewer than twenty users, a single module and a duration under six months, a well-organised internal governance model is sufficient. For organisations that have already completed several successful ERP projects with the same internal team and a documented governance model, external support is an unnecessary layer of cost and control.

The question is not “do I want external governance?”. The question is: “does my organisation have the capacity to keep this project on course internally?” That capacity rests on three things: sufficient available time on the part of the accountable owner for active oversight, knowledge of the risk dynamics in ERP projects, and the willingness to take difficult decisions when the project team would rather avoid them.

If one of the three is missing, external support is not a weakness. It is a risk measure.

Internal, hybrid or external: a decision model

Situation	Recommended approach
First large ERP implementation	Hybrid or external independent oversight
Project team consists entirely of supplier specialists	External independent oversight required
Internal PM with limited ERP project experience	Supplement with external programme governance
A previous project stalled or significantly overran budget	External second opinion before restart
Repeat implementation with a proven internal model	Internal is sufficient; periodic external review optional
Steering committee structurally experiences an information lag	Independent governance scan advised

Internal governance is sufficient when the organisation has the three conditions: available capacity, ERP project knowledge and decisiveness. External support is advisable as soon as one of the three is missing, or the project is more complex than the internal capacity can handle.

Why independent oversight is a conviction for us, not a service

Our work is, first and foremost, human work. Behind every ERP project that overruns there are people: a project manager who saw it coming months ago, a team leader on the floor whose signals never reached the top, a director who heard too late what everyone below already knew. It is not the technology that fails. The connection between what people know and what the steering committee hears is what fails.

That is why we sit alongside a steering committee. Not to sell more hours, but because we have no stake in good news. An implementation partner does have that stake, however honest it is: showing progress is part of its role. We sell no software, no licences, no ties to a vendor. The only thing we deliver is an honest picture of the risks.

Our approach to ERP programme governance and assurance: we operate alongside the steering committee, not in its place. We decide nothing for you. We make sure you decide with the information you need. Independence is not a selling point for us; it is the reason our advice can be trusted.

What we see in practice

ERP projects that stall almost never begin with a technical problem. They begin with a governance problem: unclear ownership, weak escalation paths or a steering committee that gets involved too late in decisions that have already been made.

What we also see in our project experience with 265+ specialists: organisations that take governance seriously in the first phase of the project, even before contracting an implementation partner, run structurally less risk of scope creep, budget overrun and delayed go-live. The investment in governance pays for itself in recovery costs avoided, not in reduced productivity.

An independent director who operates alongside the steering committee, with no commercial interest in a particular solution or supplier, is able to deliver information the project team cannot give: an honest picture of the risks.

The best moment for a governance check is not when the project stalls. It is at the start of contracting, at the transition to a new project phase, or at the first sign that the information the steering committee receives and the information the floor holds no longer match.

Frequently asked questions about ERP programme governance

What is ERP programme governance?

ERP programme governance is the management layer that determines who takes which decisions in an ERP project, how oversight is organised and how escalation works. A steering committee that only receives progress reports is not exercising governance. Effective governance requires actively steering on risk, ownership and course correction throughout the entire project.

When does an ERP project need an independent overseer?

An independent overseer is advisable when the project team consists entirely of supplier specialists, when the internal sponsor has insufficient time available for active oversight, or when a previous project significantly overran. A neutral party with no commercial interest can deliver information the project team cannot give itself: an honest picture of the risks.

What is the difference between programme governance and project management in ERP?

Project management focuses on day-to-day delivery: activities, teams, schedules, deliverables. Programme governance focuses on the management layer: have the right decisions been taken, are the risks sufficiently visible, is the project still aligned with the organisation’s goals? A project manager has an interest in showing progress. A governance role has an interest in a complete and honest picture of reality.

How quickly can a programme governance check be carried out?

A first programme governance check, assessing the management structure, information flows and risk ownership, can usually be carried out in one to two working days. It gives organisations a concrete picture of the governance gaps and priorities, without the running project having to be halted.

Have your management layer independently assessed

Do you suspect that your steering committee has insufficient sight of the real risks in your ERP project? Or are you preparing a new ERP implementation and want to set up the governance layer properly before contracting?

We decide nothing for you. We make sure you decide with an honest picture, delivered by a party with no vendor interest. Sometimes that is the difference between a project that gets adjusted and a project that has to be rescued.

Let’s talk through your situation, with no obligation.

Request a programme governance check

Or contact our team directly at info@erpcompany.nl or call +31 85 0607 626.

ERP programme governance: the management layer that keeps your ERP project on course