Finance ERP programs are hard because they force the enterprise to make hundreds of decisions that cut across finance, operations, IT, and external partners—often while the business is still trying to hit quarterly targets. Success depends less on how many workshops you run and more on whether leadership creates an environment where decisions are made quickly, scope is controlled, quality is protected, and value is tracked like a business initiative rather than a technology project.
Program leadership and governance is how you institutionalize that environment. It defines who decides, how they decide, what evidence is required, how progress is measured, and what happens when reality diverges from the plan. Done well, governance accelerates delivery because teams stop relitigating decisions and stop hiding risks until they become schedule shocks. Done poorly, governance becomes “slideware”: steering committees review status, issues linger without owners, and the program drifts into late-stage rework.
Throughout this chapter, treat governance artifacts as living tools—charters, logs, dashboards, and readiness criteria—updated weekly. The objective is to make the program observable so leaders can act early and keep the program anchored on outcomes.
This chapter lays out a CFO-led governance model with clear decision rights, the practical mechanics of a high-performing ERP PMO, how to run an integrated workplan across Finance, IT, and the system integrator, how to manage risk and recover when the plan breaks, and how to keep benefits visible so “go-live” is not mistaken for success.
9.1 CFO-Led Governance Model and Decision Rights
A finance ERP program is a finance transformation with a technology backbone. That truth drives the first governance decision: finance must lead finance decisions. The CFO (or a delegated finance executive with real authority) must sponsor the program, chair the core steering routines, and protect the standardization intent when inevitable pressure arises to “just make an exception.” When the CFO is absent, decisions migrate to whoever is most available—often IT or the SI—and finance later discovers that its process model has been defined by convenience rather than controllership.
A CFO-led model does not mean the CFO decides everything. It means the CFO creates the decision system: the forums, roles, escalation paths, and evidence standards that make decisions fast and durable. Define three governance layers. Executive steering: sets direction, approves major scope and budget moves, resolves cross-functional tradeoffs, and holds leaders accountable for readiness and value. Design authority: owns global process standards, data definitions, controls, and fit-to-standard discipline. Delivery governance: runs weekly execution—workplan, dependencies, RAID, and change control.
Decision rights are the core of the model. Ambiguity creates two predictable pathologies: teams delay decisions until a steering meeting that meets monthly, or teams make decisions locally and ask forgiveness later. Both create rework. Write a RACI for the decision categories that most frequently cause conflict. Process decisions: end-to-end patterns, close calendar and cutoffs, approvals, and exception handling. Data decisions: chart of accounts, segment strategy, hierarchies, and master data ownership. Controls decisions: segregation of duties rules, workflow approvals, and evidence standards. Technology decisions: integration patterns, environment strategy, and release cadence. Assign decision owners and escalation owners explicitly.
A practical rule is “finance owns the ‘what’ and ‘why,’ IT owns the ‘how’ and ‘how safely.’” Finance defines process intent, control objectives, and reporting needs; IT defines architecture, integration standards, and technical risk boundaries; the SI proposes options and executes within those boundaries. Put this in writing and repeat it in every kickoff, because it will be tested quickly—especially around customization, local variants, and reporting design.
Governance also requires decision hygiene. Decision hygiene: making decisions with the minimum evidence required, documenting them once, and preventing re-litigation. In practice, define the owner and due date, capture options and consequences, record the decision and rationale, and publish it where all teams can find it. A well-run decision log becomes the program’s memory and prevents repeated debates.
Escalation is where governance proves itself. Define a two-step escalation model. Step one is resolution within the design authority by applying decision principles (fit-to-standard, minimize variants, design for reconciliation). Step two is escalation to executive steering with a short decision packet that includes options, impacts, and a recommendation. The CFO should insist on a recommendation, not a list of complaints.
Make governance meetings decision-centric by standardizing the agenda: program health, decisions, risks needing leadership action, then brief status for context. Require a short decision packet so leaders can decide quickly and teams can execute without rework.
- Decision statement: the choice to be made and the deadline.
- Options and impacts: 2–3 paths with cost, schedule, and control implications.
- Recommendation: the proposed option and rationale tied to decision principles.
- Approval needed: what is being approved today and what happens next.
To make steering effective, keep it outcome-driven. Review a small set of leading indicators each meeting: scope changes approved and pending, customization trend, data readiness, interface readiness, testing health (coverage and defect burn), change readiness (training completion and role impacts), and benefits trajectory. When leaders see these as health metrics, they intervene earlier and with more precision.
Use a governance charter to remove ambiguity. The charter should be short and operational. Include: purpose of each forum, membership, cadence, decision rights, escalation paths, and the artifacts that will be reviewed. Also include the rule that decisions are binding unless formally reopened through change control.
Finally, set the posture toward the SI and vendor. Partnership matters, but governance must be fact-based. Require transparent reporting, open access to plans and logs, and objective acceptance criteria. If performance slips, intervene early—through staffing changes, scope resets, or contractual levers—rather than waiting until late-stage failure is undeniable.
9.2 ERP Program Management Office
The ERP PMO is the program’s execution engine. It turns strategy into an integrated plan, makes dependencies visible, and creates the discipline that prevents late surprises. Many PMOs fail by focusing on status reporting instead of control. A high-performing PMO is less like a project secretary and more like air traffic control: it ensures workstreams do not collide, that the critical path is protected, and that decision-making is timely.
Define the PMO’s purpose in operational terms. PMO purpose: maintain a single version of the truth for plan, scope, risks, decisions, and value; surface issues early with clear options; and enforce the routines that keep the program predictable. That purpose implies responsibilities that go well beyond a weekly status deck.
At minimum, the PMO should own five control systems. Integrated planning: one master plan with cross-workstream dependencies and critical path logic. RAID discipline: one register for risks, assumptions, issues, and decisions with owners and due dates. Change control: a controlled intake and approval process for scope changes with quantified impacts and tradeoffs. Quality gates: entry/exit criteria for key phases such as design sign-off, testing readiness, and go-live readiness. Communications cadence: consistent reporting to leaders and teams with clear tasks, not just updates.
A PMO also needs the right roles. Many programs use a small “two-in-a-box” leadership model: a finance program lead accountable for business outcomes and an IT program lead accountable for technical execution, aligned daily and jointly presenting to steering. Add focused support for planning, readiness, and data/integration coordination where scale requires it.
Standardize a weekly artifact set so leaders know what is authoritative and teams operate from one version of the truth.
- Master plan and lookahead: critical path, upcoming milestones, and dependency asks.
- RAID log: top risks/issues with triggers, owners, and escalation dates.
- Change and decision log: what changed, what was decided, and what is pending.
- Quality dashboard: defects, test coverage, conversion results, and readiness indicators.
Integrated planning is where many programs stumble. Workstreams plan in isolation, then discover in testing that their outputs were prerequisites for someone else. The PMO must insist on dependency mapping that is specific and owned. “Data,” “integration,” and “reporting” must be decomposed into concrete deliverables tied to mock conversions, interface testing, and report certification.
RAID discipline requires strong definitions. Risk: an uncertain event that could impact cost, schedule, or quality; it requires mitigation. Issue: something already happening that requires action now. Assumption: something treated as true for planning that must be validated by a date. Decision: a commitment that constrains future work. When teams use these terms loosely, the PMO cannot prioritize or escalate effectively.
Make RAID operational with a weekly rhythm. Owners update mitigation progress, the PMO flags items approaching trigger conditions, and leaders remove blockers. The goal is to shorten the time between signal and intervention so small risks do not become structural schedule slips.
Change control is the PMO’s most important discipline because scope creep is the default state of ERP. Require each change request to include business value, compliance need (if applicable), delivery impact (cost, schedule, testing), and an explicit tradeoff—what will be deferred or removed. When change control is weak, the cost shows up later as test failure and rework.
Quality gates protect the program from optimistic declarations such as “design is done” or “build is complete” when operability is missing. Define gates with evidence. For example, testing readiness requires scripts, test data, environments, trained testers, and defect triage rules. Operability for integrations requires monitoring and runbooks, not only a successful file transfer.
The PMO also sets the transparency tone. Require consistent status from each workstream: progress against plan, key risks and decisions, quality indicators, and specific tasks. Avoid “percent complete” reporting unless it is backed by deliverable completion; prefer evidence such as defect burn-down, conversion success rates, and training completion by role.
Finally, track capacity. Finance ERP programs consume scarce SME time. The PMO should forecast demand peaks (design, test cycles, cutover) and make gaps visible so leaders can intervene with backfills or scope choices before quality is compromised.
9.3 Integrated Workplan Across Finance, IT, and SI
An integrated workplan is the difference between “three parallel projects” and one coordinated program. Finance owns process and readiness, IT owns environments and integration, and the SI owns build delivery—but the work is interdependent. If these plans are not integrated, the program experiences false readiness: build is “complete” but finance cannot reconcile; environments are “ready” but test data is missing; training is “done” but security roles block execution.
Integrated workplan: a single master plan that aligns milestones, deliverables, and dependencies across Finance, IT, and the SI, with one critical path and one definition of readiness. The key is dependency logic and shared accountability.
Build the plan in layers: a milestone view for executives, a dependency-driven integrated plan for program leaders, and a rolling 6-week lookahead refreshed weekly. The lookahead is where you surface blockers early enough to fix them without disrupting test cycles.
Environment and data coordination is a common hidden dependency. Treat environment readiness as owned work with a refresh/masking approach, a calendar for freezes and refreshes, and clear rules for when configuration can change during testing.
- UAT entry criteria: scenarios and data ready, roles provisioned, critical integrations stable with monitoring, and defect triage operating.
Integrate business readiness tasks into the same plan so training, role mapping, and support onboarding do not lag behind solution readiness.
Define shared milestones that anchor all teams: global design sign-off, build freeze, system integration testing start, user acceptance testing start, mock cutover cycles, go-live decision checkpoint, cutover execution, first close, and hypercare exit. Each milestone needs entry and exit criteria and must include deliverables from all parties, not just the SI.
Map dependencies explicitly. For each deliverable, ask what depends on it and what it depends on. Testing depends on stable configuration, stable interfaces, cleansed master data, populated test data, trained testers, and a defect triage model. Conversion depends on cleansing, mapping sign-offs, extraction logic, transformation rules, and reconciliation scripts. Reporting validation depends on stable hierarchies and trial balance mapping plus comparative data. If these dependencies are not mapped, they will appear late as “emergencies.”
Establish a weekly integrated planning cadence chaired by the PMO, with Finance and IT leadership present. Review critical path movement, dependency risks, upcoming peaks, and decisions required in the next two weeks. This meeting should end with actions and owners; otherwise, the plan is not controlling work.
Align on a common definition of “ready.” Define readiness as evidence across four areas: solution readiness (configuration and interfaces), data readiness (cleansed and converted data with reconciliations), people readiness (trained users and updated roles), and operational readiness (support model, monitoring, and runbooks). A single readiness dashboard prevents teams from declaring readiness based on their own criteria.
Integrate defect management into the plan. Define severity rules, triage routines, and ownership, and require root-cause tagging (configuration, data, integration, process, security, training). This turns defects into management information, not just a backlog.
Finally, integrate the cutover early. Cutover should include sequencing, blackout windows, decision rights, rollback criteria, and responsibilities across Finance, IT, SI, and operations. Treat cutover rehearsals as plan milestones with entry criteria and lessons-learned actions.
9.4 Risk Management and Recovery Planning
Every finance ERP program will encounter surprises. Risk management is not about pretending surprises will not happen. It is about detecting them early, quantifying them honestly, and responding with controlled recovery moves rather than improvisation. Programs that stay “green” until they suddenly go red are not healthy; they are blind.
Start with a realistic risk taxonomy. Data quality risk, integration stability risk, scope creep risk, testing participation risk, change adoption risk, and SI performance risk appear repeatedly because they are structural. Name them early, assign owners, and define leading indicators so you do not wait for a crisis to discover them.
Use the risk register as a management tool. Each risk needs a mitigation plan, an owner, a trigger, and a contingency response. Trigger: an observable condition that indicates the risk is materializing and intervention is required. For example, if mock conversion success falls below a defined threshold, the program must add cleansing sprints or adjust scope. If defect burn-down does not meet planned rates, the program may need a build freeze, additional test cycles, or scope deferrals.
Build leading indicators for each major risk so you can see problems before they hit the critical path. For example, data risk is visible in duplicate rates, missing mandatory fields, and the percentage of conversion objects that reconcile during mock runs. Integration risk is visible in interface failure rates, late file arrivals against cutoffs, and the number of unresolved errors aged beyond a threshold. Testing risk is visible in business participation, scenario completion rates, and defect recurrence. Change risk is visible in training completion by role, proficiency checks, and local readiness assessment scores.
- Common “early warning” triggers: rising customization count, increasing variant requests late in design, repeated failures in the same conversion object across mocks, interfaces that “work” only with manual rework, UAT running with unrealistic test data, or unresolved high-severity defects accumulating near cutover.
When a trigger is hit, use a simple recovery playbook to avoid improvisation.
- Stabilize: pause new scope, freeze configuration where needed, and focus teams on defect and root-cause resolution.
- Re-baseline: update the integrated plan with a realistic critical path and publish what changed and why.
- De-scope or re-sequence: defer low-value items, reduce variants, or move entities to a later wave.
- Re-test intentionally: rerun the end-to-end scenarios that prove close-critical flows and reconciliation.
- Reconfirm readiness: apply evidence thresholds again before returning to the original go-live path.
Quantify risk in consequence language. Replace “data quality is a concern” with “data defects will force manual journals and extend close by two days unless resolved by the next mock conversion.” Leaders act faster when they understand specific impacts on close, compliance, and business disruption.
Independent delivery assurance can help, but only if leadership listens. The value is objective challenge on readiness evidence, SI staffing quality, defect trends, and unrealistic plans.
Recovery planning is the part most programs skip until it is too late. Recovery plan: a pre-designed set of actions the program can execute when key risks materialize, aimed at restoring schedule credibility and protecting quality. Common recovery levers include: scope reduction (defer low-value features, reduce variants, move entities to later waves), sequencing shifts (stabilize the core before adding adjacencies), targeted resourcing for data/integration/testing, and stricter quality gates (build freeze plus defect and root-cause resolution).
Recovery requires courage because it often means admitting the original plan was too optimistic. The CFO and steering committee must normalize this: resetting scope and timing is a leadership act, not a failure. The alternative is worse—pushing forward with poor readiness and paying for it through operational disruption and loss of trust after go-live.
Define go/no-go evidence thresholds in advance for common failure modes. For data, set mock conversion and reconciliation success thresholds and limits on critical data defects. For testing, set defect thresholds by severity and coverage thresholds for end-to-end scenarios. For change readiness, set training completion and role readiness thresholds plus adoption measures from simulations. For integration, set interface stability thresholds and monitoring readiness. Evidence-based thresholds protect you from hope-based decisions.
Also plan explicitly for the first close. Treat it as a controlled event with journal plans, reconciliation priorities, intercompany routines, daily triage, and contingency workarounds with owners. The goal is continuity with transparency: everyone knows what is stable, what is being monitored, and what will be improved after stabilization.
9.5 Benefits Tracking and Value Governance
Many programs declare success at go-live and then discover that promised benefits did not materialize. The cause is rarely that benefits were impossible. The cause is that benefits were never governed with owners, metrics, and interventions. Value governance: the routines and accountability that keep the program oriented toward business outcomes throughout delivery and after go-live.
Convert the business case into a benefits register that is owned by the business, not by the PMO. Each benefit needs a baseline, a target, a timing profile by release, and a named owner who can change process and behavior. The PMO tracks; the business owns. If the owner cannot change behavior, they cannot own the benefit.
Use a small set of metrics that are hard to game and pair speed with quality. For close, measure days and post-close adjustments. For AP, measure invoice cycle time and match exception rate. For O2C, measure dispute aging, cash match rate, and unapplied cash aging. For controls, measure SoD exceptions and audit findings that require remediation effort. These measures connect system behavior to real outcomes.
Make benefits visible during delivery through leading indicators tied to design and testing. If you want fewer manual journals, track journal volume in rehearsal closes and require root-cause tags. If you want fewer AP exceptions, track exception rates in testing and validate receiving discipline. If you want reporting trust, validate certified reports against reconciled balances and track how many manual mapping steps remain. This cadence enables intervention while value is still within design control.
Define how productivity will be captured. Productivity is not a financial benefit unless capacity is removed or demonstrably redeployed with measurable outputs. Decide whether the intent is staffing reduction over time, hiring avoidance, or redeployment to higher-value work, then align role redesign and operating model changes to that intent.
After go-live, shift from project governance to product governance. Establish a routine where process owners review KPIs, prioritize enhancements, and protect standards. Use a backlog with value and effort estimates and tie enhancements to measurable outcomes rather than stakeholder volume.
Treat decommissioning as value governance. Legacy systems and spreadsheets anchor old behaviors and duplicate work. Define what will be retired, when, and what evidence is required to retire it safely, then tie those milestones to benefits and adoption measures.
- Value governance checklist: benefits register with owners and baselines, leading indicators reviewed monthly, productivity capture plan, certified reporting and reconciliation measures, post-go-live product governance, and decommissioning milestones tied to behavior change.
When leadership and governance works, it does not feel like bureaucracy. It feels like clarity: decisions are made, risks are surfaced early, teams know what ready means, and leaders can see whether the program is delivering the outcomes that justify it.
