Governance is the decision machine of an ERP program, and its only job is to make decisions fast and make them stick. A program spending $1M a month throws up a scope cut, a design conflict, or a date risk almost every week, and each one that sits unresolved is schedule you are buying twice. Good governance fixes who decides what before the first disagreement, sets a time limit on every open decision, and names the person who settles a tie when the client and the SI (systems integrator) disagree. The technology rarely sinks a program. The decisions nobody owned usually do.
The governance layers, and what each one decides
An ERP program needs four layers of decision-making, and each decides a different class of question. Push a decision up a layer and you lose a week waiting for a meeting; push it down a layer and it is made by someone without the authority to make it hold.
The executive sponsor owns the business case and every decision above the program manager: money, scope at the top level, and the date. The sponsor chairs the steering committee rather than sends a delegate, because the sponsor is the person who loses if the program goes live on a case it can no longer meet.
The steering committee owns the trade-offs between scope, date, and budget, in writing. It meets monthly in the year before go-live, and the test of whether it is governing is simple: a committee that meets for 40 minutes and records no decision has handed those calls one level down.
The client program manager owns the plan, the management of the SI, and the status the board sees. This person works for you, not the SI, because a status report is an opinion about a plan, and the firm running the plan should not also grade it.
Below the program manager sit the work-area leads: a business process owner for each core area (order-to-cash, procure-to-pay, record-to-report, plan-to-make), a data migration lead, an integration owner, and a security and controls owner. They decide inside their area and escalate what crosses areas or breaks the budget. The SI delivery lead runs the SI's own team beneath this line, and reports into the client program manager.
Decision rights and an escalation path with a clock
A decision right is a written answer to one question: when this type of choice arises, who makes the call. Without it, every choice becomes a meeting, and the program slows to the speed of its calendar. Set the rights by class of decision, not case by case, so the program knows in advance where each kind of question goes.
The escalation path is the same idea with a clock attached. A design conflict a work-area lead cannot settle goes to the client program manager; what the program manager cannot settle goes to the steering committee; what the committee cannot settle goes to the sponsor. The clock is what makes the path work. The rule the site recommends is that a work-area lead holds a decision no longer than 3 business days, the program manager no longer than 5, and the steering committee resolves anything that reaches it at its next monthly meeting or a called session inside 10 business days. A decision that sits for three weeks has already cost you three weeks, whatever it decides.
Write the open decisions into a single log with an owner and a due date against each one. The log is the instrument the sponsor and the independent assurance lead read to see whether governance is working, because a growing stack of decisions past their due date is drift you can measure before the status color admits it.
A responsibility matrix for the decisions that cause disputes
Most governance documents assign roles to tasks nobody argues about. The value is in the handful of decisions that reliably cause disputes between the client and the SI. A RACI matrix answers four questions for each one: who is responsible (does the work), who is accountable (owns the outcome and signs, and there is only ever one), who is consulted (gives input before the call), and who is informed (told after).
The decisions below are the ones that turn into change orders, delays, and audit findings when the rights were left vague. The accountable role is the one that matters most: it is the single name that carries the decision, and on every business decision it sits on your side of the table, not the SI's.
| Decision | Executive sponsor | Steering committee | Client program manager | Business process owner | Data migration lead | SI delivery lead |
|---|---|---|---|---|---|---|
| Scope change above the budget line | A | R | C | C | I | I |
| Design sign-off for a core process | I | I | C | A/R | I | C |
| Go/no-go at go-live | A | R | C | C | C | C |
| Custom-code approval | I | I | A | C | I | R |
| Data ownership and reconciliation sign-off | I | I | C | C | A/R | C |
| Phase gate release of the next payment | A | R | C | I | I | I |
Two points hold across the table. The accountable mark never sits with the SI delivery lead on a business decision, because the SI supplies the work and the recommendation, not the ownership. And design sign-off is accountable to the business process owner by name, not an IT delegate or an SI consultant, because a design signed by anyone else reopens the moment testing reaches it and returns as a change order the SI is right to charge for.
Phase and quality gates that must be passed before money moves
A gate is a point where the program stops, proves it met a defined standard, and only then releases the money and the mandate for the next stage. Gates are what stop a program buying its way into trouble one stage at a time. Tie a payment to each gate, so the SI has a reason to meet the standard rather than carry a known problem forward.
Four gates carry most programs: the end of design, the end of build, the end of integration testing, and go-live readiness. Each needs a written entry standard the sponsor can check. The end of design releases nothing until the business process owners have signed the core designs by name. The end of integration testing holds until the defect counts fall under an agreed ceiling, typically zero open critical defects and a small, named list of accepted lesser ones. Go-live readiness holds until at least three full-volume data mock loads have run, the second loading 95% of records cleanly, and the controller has signed the trial balance variance between the old ledger and the loaded one.
The end of design gate earns special attention because it is where an SI's efficiency claims become real or vanish, and it sits at only 10 to 20% of implementation hours, early enough to act on what it shows. Release the next payment at a gate only when the entry standard is met, not when the calendar says the stage should be over.
Vendor and SI governance
The SI is 40 to 60% of implementation cost, per ERP Research, so it needs its own governance, not just a line on the status report. Give the relationship a single owner on your side, the client program manager, who holds the contract, the named-personnel clause, and the monthly review. The SI delivery lead is the counterpart, and the two meet weekly.
Govern the SI against a performance scorecard the two sides agree at the start, read monthly, and both sign. Four measures carry it: schedule (gate dates met against plan), quality (open defects by severity and the test-pass rate), team stability (turnover in the SI's named roles, with a joint review triggered above 20% inside six months), and change orders (count and value against the baseline). A scorecard read from the source records, not the SI's own status color, is what lets you govern from evidence. Fund independent assurance at 1 to 2% of the program, reporting to the sponsor, to read those records week to week; on a $6M program that is $60,000 to $120,000.
Who decides when the client and the SI disagree
This is the question governance exists to answer. When the client and the SI disagree on scope, on whether a design is done, or on whether the program is ready to go live, the client decides, because the client is accountable for the business decisions, the data, and the readiness of its own people. The SI owns its work and its recommendation; it does not own the call.
The path is the one set above. A disagreement a work-area lead and the SI delivery lead cannot settle inside 3 business days goes to the client program manager. What the program manager cannot settle goes to the steering committee. A go/no-go split goes to the sponsor, who holds the business case and therefore the final say. The reason this holds is contractual as much as organizational: the SI's incentives are the date and the fee, and the client's incentive is a system that returns its case, so the tie must break toward the party who lives with the result for the next fifteen years. Write that line into the statement of work, so the authority exists before the first argument rather than being improvised during it.