What Steering Committees Should Ask and What the Evidence Should Show

Whether the program involves ERP, AI, or another major transformation, the buck stops with the executives. They are accountable for the investment, the decisions made along the way, and whether the promised business results are achieved.

That means they need more than a reassuring status report. Before approving the next phase, they need clear evidence of what has been completed, what remains at risk and whether the program is ready to move forward.

A useful ERP governance framework connects the work being performed to those executive decisions. Core teams produce and validate the deliverables. The PMO evaluates their quality, assesses dependencies and prepares recommendations. The steering committee challenges those recommendations, resolves business trade-offs and provides direction. Here are seven questions steering committees should ask:

1. Does the design support the business strategy?

Blueprint approval is an early opportunity to assess whether the program will deliver what the business needs. A design can accommodate departmental requirements while leaving broader strategic objectives poorly supported.

If an investment is intended to make acquisitions easier to integrate, for example, leaders should understand how the design supports common processes and data across entities. Allowing each location to retain its own practices could undermine that objective before configuration begins.

The committee should ask to see how strategic objectives connect to process designs, requirements, and acceptance criteria. Business owners should explain material gaps and their consequences.

Ask: “Which intended business improvements does this design enable, and where are we accepting a compromise?”

2. Is the methodology suitable for this implementation?

An implementation approach for ERP, AI or any other enterprise technology needs to fit the business, the project and the people available to deliver it. A compressed schedule may assume that subject-matter experts can make decisions and validate work faster than their operational responsibilities allow.

Leaders should examine the assumptions behind the plan. Does the deployment sequence reflect dependencies between sites and systems? Are team members capable of performing their assigned work, and do they have sufficient capacity? Is there room to test, correct problems and validate the changes?

The methodology should define deliverables and approval criteria that make progress objectively assessable. Where resources or capabilities fall short, the plan needs an explicit response.

Ask: “What assumptions make this approach achievable, and have we confirmed them against our capabilities and constraints?”

3. Are process deviations and customizations justified?

Customization decisions can accumulate through individual requests that appear reasonable. Collectively, they can increase development costs, complicate integrations and expand the testing and support burden.

Some deviations are necessary to meet regulatory obligations or support a valuable business capability. Others preserve practices that employees know and prefer. Steering committees need to understand the distinction when reviewing material departures from the agreed process design.

A recommendation should explain the business need, alternatives considered and consequences over the solution’s life. Rejecting necessary functionality also has a cost; that should be visible in the assessment.

Ask: “What would the business lose by following the preferred process, and does that justify the proposed deviation?”

4. What has testing actually demonstrated?

“Testing is 90% complete” provides little assurance without knowing what was tested and what passed. The remaining scenarios could include the transactions essential to operating the business.

Testing should develop iteratively. Unit testing establishes whether individual functions and developments work. Departmental testing checks whether teams can execute their processes. System integration testing, or SIT, validates flows across departments, interfaces and connected systems. Day-in-the-life testing brings people, processes and data together under representative operating conditions.

Problems found during these cycles require correction and retesting, including checks for effects on previously working processes. Steering committees should see results by business criticality, alongside unresolved defects and workarounds. Automation can accelerate execution; the adequacy of the scenarios and evidence still requires scrutiny.

Ask: “What can we confidently say the business will be able to do, and what remains unproven?”

5. Will the transformed data support future operations?

Successfully loading records does not establish that the data is fit for use. Data migration may require changes to definitions, structures and business rules as well as cleansing.

Business owners need to validate that transformed data supports the future processes. Financial reconciliation alone will not establish whether product, customer or supplier records allow employees to perform their work correctly or support executive-level reporting and decision-making.

Readiness evidence should include approved transformation rules, quality checks, business validation and migration rehearsals. Those rehearsals should also establish whether extraction, conversion, loading and validation can be completed within the cutover window.

Ask: “What evidence confirms that the migrated data will support operations, and which unresolved problems could prevent it?”

6. Are people prepared to work differently?

Training attendance measures participation. It provides limited evidence of whether employees can perform their new responsibilities.

Organizational change management starts earlier, with leadership alignment on how the business will operate. Communication needs to explain changes in responsibilities and expectations clearly enough for people to prepare. Managers must be equipped to support adoption and address resistance or confusion.

The committee should review practical proficiency assessments and readiness by affected group, alongside unresolved role and ownership questions. These findings should influence the deployment decision.

Ask: “Can people perform their new roles, and are their managers prepared to reinforce the changes?”

7. Can we execute cutover and sustain operations?

Cutover approval brings the preceding evidence together against agreed go/no-go criteria. Conditions for proceeding should be established early enough to guide preparation.

The committee needs an executable transition plan, informed by rehearsals, with clear responsibilities and contingency arrangements. Hypercare requires a staffed support structure that can triage problems, escalate decisions and coordinate business and technical responses. Support coverage must reflect operating hours and locations.

Define how the organization will judge stabilization and transition to ongoing support.

Ask: “Can we complete the transition and sustain operations, and who will respond when problems arise?”

Put the evidence to work

An effective ERP governance framework helps leaders turn evidence into informed decisions. These questions help leaders interpret recommendations and identify where intervention is needed. Answers should lead to decisions, accountable owners and follow-through.

Explore how steering committees, PMOs, and core teams can strengthen governance across design, data migration, testing, and organizational readiness in our ERP Rescue Room webinar.

Watch ERP Rescue Room: What Steering Committees Need to Successfully Govern ERP Implementations