An ERP implementation can have a detailed project plan and still drift if decisions are delayed, risks have no accountable owners, or teams move into the next phase before the required work is complete. Effective ERP project governance connects executive direction with day-to-day delivery controls. It defines who can make decisions, what evidence is needed to approve progress, and how unresolved issues are escalated.
Governance is not the same as adding more meetings. A useful model gives each forum a clear purpose and authority. It should help the organisation resolve cross-functional trade-offs, protect the approved scope and expose delivery risks early enough to act.
What ERP project governance should control
ERP programmes affect finance, operations, supply chain, sales, procurement, reporting and technology. Decisions in one area can create consequences elsewhere. Governance should therefore cover five connected areas:
- Business outcomes: confirm the programme remains tied to measurable operational and financial objectives.
- Scope and design: control process decisions, customisations, integrations and changes to requirements.
- Delivery performance: track milestones, dependencies, resource capacity, budget and forecast completion.
- Risk and assurance: manage data, security, compliance, testing, adoption and supplier risks.
- Readiness and transition: require evidence that users, processes, support teams and operations can move safely into production.
Microsoft’s Dynamics 365 project governance checklist recommends steering structures, actionable risk registers and milestone reviews with explicit entry and exit criteria. The same principles apply across ERP platforms, although the exact controls should reflect the programme’s size and risk.
Build governance around decision rights
Start by identifying decisions that can block delivery or change the business case. Examples include approving a process design that changes internal controls, accepting a data migration exception, authorising a custom development, changing a go-live date or approving additional implementation spend.
For each decision type, document:
- Who recommends the decision and who provides specialist input.
- Who has final approval authority and any financial or risk thresholds.
- What evidence must accompany the request.
- Where the decision is recorded and how affected teams are informed.
- How quickly the decision must be made and where it escalates if overdue.
A simple responsibility matrix is often sufficient. Avoid giving every stakeholder approval rights on every issue; that creates bottlenecks and diffuses accountability. Business process owners should own process decisions within agreed policy. The programme sponsor or steering committee should resolve cross-functional conflicts, material scope changes and exceptions outside delegated authority.
Use a small number of governance forums
Executive steering committee
The steering committee should include the executive sponsor, business leaders, IT leadership, programme leadership and other decision-makers required by the organisation. Its job is to set direction and resolve matters that cannot be settled within the delivery team.
Use the meeting to review:
- Progress against outcomes, milestones and the approved business case.
- Material risks, issues and decisions requiring executive intervention.
- Budget, forecast cost, resource constraints and supplier performance.
- Scope changes with implications for value, time, cost or risk.
- Readiness to pass major programme gates.
Do not spend the meeting reading a task-by-task status report. Circulate a concise dashboard in advance and focus discussion on exceptions, decisions and actions.
Programme delivery meeting
The programme manager, workstream leads, solution architect, data lead, testing lead, change lead and implementation partner should coordinate dependencies and delivery commitments. This forum should maintain the integrated plan, surface blockers, agree corrective actions and prepare escalations for the steering committee.
Design and change authority
A design authority or change board evaluates changes to the solution baseline. It should consider process fit, architecture, integration, data, security, reporting, supportability and lifecycle cost—not only whether a requested feature can be built. Record accepted decisions, rejected requests, assumptions and deferred items.
Define stage gates with evidence, not optimism
Stage gates are formal checkpoints between phases. They are useful only when the criteria are measurable and the organisation is prepared to hold a phase when evidence is incomplete. A typical ERP programme can use the following gates:
| Gate | Evidence to review | Decision |
|---|---|---|
| Initiation to discovery | Approved objectives, sponsor, funding, scope boundaries and named business owners | Authorise discovery and mobilise the team |
| Design approval | Validated process designs, fit-gap decisions, architecture, integration approach and data ownership | Approve the solution baseline or return unresolved items |
| Build to test | Configured scope, completed development reviews, test environments, migration rehearsal plan and traceable requirements | Begin formal testing |
| Test to deployment | UAT sign-off, critical defect disposition, reconciled migration results, cutover rehearsal and support readiness | Approve or defer go-live |
| Hypercare exit | Stable operations, open issue ownership, support handover, knowledge transfer and agreed service measures | Transition to business-as-usual support |
Gate approval should be conditional where appropriate. If a non-critical item remains open, document its owner, due date, business impact and accepted workaround. Do not label a gate “passed” simply because the target date has arrived.
Make the risk register actionable
A risk register is not a list of concerns. Each material risk needs a named owner, probability and impact assessment, mitigation, contingency, trigger and review date. Prioritise risks that can affect business continuity, financial control, regulatory obligations, data integrity, integration reliability or the critical path.
Keep risks distinct from issues. A risk may happen; an issue has already happened and requires action. Link both to the programme plan and decision log so that governance discussions lead to action rather than repeated reporting.
Use a decision-oriented status dashboard
A useful steering pack usually contains:
- Milestone status against baseline, including forecast dates and dependencies.
- Budget spent, estimate to complete and approved change requests.
- Top risks and issues, with owner, trend and required intervention.
- Scope changes and decisions awaiting approval.
- Testing, data migration, training and operational-readiness indicators.
- Actions from the previous steering meeting and overdue decisions.
Use consistent definitions for green, amber and red. For example, a milestone should not be green if it is forecast to miss the baseline but the team has not formally changed the date. Explain the cause and recovery plan instead of hiding variance behind subjective status labels.
Common governance failures to avoid
- Steering committee without authority: senior attendees receive updates but cannot resolve conflicts or approve exceptions.
- Unclear business ownership: the implementation partner makes process decisions that should belong to the customer.
- Too many approval layers: routine decisions wait for executive meetings and slow delivery.
- Gate criteria ignored: phases progress with unresolved defects, incomplete data or untrained users.
- Change requests assessed in isolation: small additions accumulate into significant cost, complexity and support burden.
- Metrics without action: dashboards show red indicators repeatedly without owners, deadlines or escalation.
How governance affects implementation cost and outcomes
Governance does not eliminate delivery uncertainty. It makes uncertainty visible and gives the organisation a controlled way to respond. A design change can affect testing effort, data migration, training, licensing, integrations and long-term maintenance. Assessing those consequences before approval protects the business case more effectively than relying on informal assurances.
When evaluating a delivery partner, ask how it will support the customer’s governance model, what decisions it expects the customer to make, how it reports forecast cost and schedule, and how it handles unresolved dependencies. Compare the proposed governance responsibilities with the implementation scope and commercial terms. Our guide to ERP implementation challenges provides further context on the delivery risks that governance should control.
ERP project governance checklist
- Executive sponsor and business process owners are named.
- Decision rights, approval thresholds and escalation routes are documented.
- Steering, delivery and design forums have distinct purposes.
- Stage gates have measurable entry and exit criteria.
- Risks, issues, decisions, assumptions and changes are logged and owned.
- Budget, schedule and scope are tracked against approved baselines.
- Testing, migration, adoption and support readiness are included in governance.
- Every major decision is recorded and communicated to affected teams.
Final consideration
The right governance model is proportionate to programme complexity and business risk. A smaller deployment may need a compact steering group and a disciplined decision log; a multi-entity transformation may need formal design authority, workstream controls and regional decision structures. In both cases, governance should make accountability clear, surface material risk early and ensure that progress is supported by evidence.
