RISE conversion governance, committee structure.

A RISE with SAP conversion is a programme. The programme has a budget, a timeline, a scope, a risk profile, and a long list of decisions that have to be made under time pressure across multiple business functions. The committee structure that the buyer organisation puts in place determines whether the decisions land on time and on budget, or whether they slip into the SAP delivery team default. This article describes the committee structure that consistently holds a RISE conversion programme to its plan, identifies the decision rights at each layer, and lists the escalation paths that the senior CIO should establish before the programme starts.

The three layer model and what each layer owns

The committee structure for a RISE conversion has three layers. The top layer is the executive steering committee, which owns the business case, the budget, the timeline, and the strategic decisions. The middle layer is the programme steering committee, which owns the workstream coordination, the scope changes, the risk register, and the operational decisions. The bottom layer is the working group structure, which owns the day to day delivery, the technical decisions, and the workstream level deliverables.

The three layer model is not unique to RISE programmes, but the application to RISE has specific properties. The first property is the cross functional nature of the programme, which requires representation from IT, finance, business operations, procurement, and legal at every layer. The second property is the multi vendor delivery model, which requires the structure to coordinate the SAP delivery team, the SI partner team, and the hyperscaler team. The third property is the multi year duration, which requires the structure to sustain stable decision authority across executive transitions on the buyer side.

The executive steering committee

The executive steering committee meets monthly during the active conversion phase and quarterly during the steady state phase. The committee is chaired by the CIO or the equivalent senior executive with the operational accountability for the conversion. The membership includes the CFO, the senior business leadership across the affected divisions, the procurement leadership, and the legal leadership. The committee owns four decisions that no lower layer can take. The budget envelope. The timeline major milestones. The scope changes that affect more than one workstream. The risk acceptance for the high impact risks.

The committee operates against a defined decision template, with each meeting producing a documented set of decisions and a documented set of escalations to the next meeting. The discipline of the template is the operational property that distinguishes the committees that drive the programme from the committees that observe it. The driving committees have a documented decision log that the programme can be audited against. The observing committees have a meeting note that nobody refers to between meetings, and the lower layers fill the decision vacuum with default behaviours that drift away from the buyer position.

The programme steering committee

The programme steering committee meets weekly during the active conversion phase. The committee is chaired by the programme director, who reports to the executive steering committee. The membership includes the workstream leads across IT infrastructure, application configuration, data migration, business change, integration, security, and testing. The committee owns the operational decisions that the workstreams cannot resolve at the working group level, the scope changes that affect a single workstream, the risk register updates, and the issue resolution across the workstreams.

The programme steering committee is the layer at which the SAP delivery team participates most heavily. The SAP programme manager attends as a participant, with the buyer programme director as the chair and the decision authority. The structural distinction between the SAP participation and the buyer authority is the property that prevents the SAP delivery team from setting the cadence and the priorities. The distinction has to be operationalised through the meeting agenda, the decision template, and the escalation procedure. Without the operationalisation, the SAP team drifts into the chair role by default, and the buyer position erodes.

The working group structure

The working groups operate at the technical delivery layer. Each working group is owned by a workstream lead and includes the technical staff who execute the deliverables. The working groups meet on a cadence that matches the delivery rhythm, typically twice weekly during the active phase. The working groups own the technical decisions that fall inside the agreed scope, the daily issue resolution, and the deliverable production. The working groups do not own scope changes, risk acceptance, or budget decisions, which are reserved to the higher layers.

The working group structure varies across conversions, but the consistent groups are six. Infrastructure, which covers the hyperscaler reservation, the network buildout, and the operational handover. Application, which covers the SAP configuration, the custom code remediation, and the BTP extension development. Data, which covers the migration strategy, the cleansing, and the cutover plan. Integration, which covers the inbound and outbound interfaces. Business change, which covers the user training, the process redesign, and the operational readiness. Security, which covers the access controls, the audit posture, and the compliance reporting.

Decision rights and the RACI matrix

The decision rights at each layer have to be documented in a RACI matrix that the programme uses as the governance anchor. The matrix identifies, for each decision category, who is responsible, who is accountable, who is consulted, and who is informed. The matrix has to be published at the programme start and reviewed at each phase gate. The discipline of the matrix is the operational property that prevents the decision drift that consumes programme time.

The most contested categories in a RISE programme are typically the scope changes, the integration boundary decisions, and the user classification decisions. The SAP delivery team frequently attempts to escalate these decisions to the buyer side without taking accountability for the outcome. The buyer side RACI has to identify the buyer accountable owner explicitly, with the SAP delivery team in the consulted role. The structural assignment prevents the SAP team from making decisions by default through the absence of a buyer side owner.

Escalation paths and the dispute resolution mechanism

The escalation paths between the three layers have to be defined explicitly. The default escalation runs from the working group to the programme steering committee to the executive steering committee. The cross vendor escalation runs from the buyer programme director to the SAP regional vice president, with the dispute resolution mechanism defined in the contract. The cross workstream escalation runs from the workstream lead to the programme director, with the parallel notification to the affected workstream lead.

The escalation paths have to define the response time at each layer. The default is twenty four hours at the working group, forty eight hours at the programme steering committee, and one week at the executive steering committee. The cross vendor escalation defaults to seventy two hours, with the formal dispute resolution mechanism triggering after that period. The defined response times are the operational property that prevents the escalations from drifting into long term issues.

The governance failures that the structure prevents

Across the firm engagement base, the RISE conversion programmes that miss their plan fail at one of three governance points. The first failure is the absence of the executive steering committee, with the budget and timeline decisions taken at the programme director level and ratified retrospectively. The second failure is the drift of the programme steering committee chair to the SAP delivery team, with the buyer programme director participating rather than chairing. The third failure is the absence of the RACI matrix, with the decisions taken by default in the absence of a documented owner.

The committee structure described in this article prevents the three failures by defining the committees, the decision rights, and the escalation paths before the programme starts. The structure is not a guarantee of success, but the absence of the structure is a reliable predictor of failure. The programmes that land on plan have the structure in place. The programmes that miss the plan typically lack one or more of the three layers, or have the layers in place without the operational discipline.

Closing position. Structure before delivery

The committee structure for a RISE conversion has to be established before the formal delivery begins. The temptation to start the technical work first and add the governance later is consistent across programmes, and it is consistently fatal. The technical decisions that the programme takes in the early phase set the foundation for the entire conversion, and the foundation is set without the governance discipline that the structure provides. The discipline of the structure has to be in place at the programme inception, not added at the mid point when the drift has already taken effect. The structure is the property that converts the conversion from a vendor led delivery into a buyer led programme, and it is the property that the firm consistently installs at the start of every conversion engagement.