Defining Roles & Responsibilities in Systems Integrator (SI) led Projects

Why Clarity Matters Before You Sign the Contract 

Embarking on a major SAP transformation - such as moving from SAP ECC to SAP S/4HANA - is one of the most significant undertakings for any organisation. Typically, such programmes of work require expert implementation services from an external provider as well as input from internal teams. As such, success depends not only on the choice of System Integrator (SI) but also on the clarity of responsibilities between the SI and your own team. 

A poorly defined Statement of Work (SOW) is one of the most common reasons projects overrun, cost more than expected, or fail to deliver anticipated value. Too often, language such as “assist client in” or “provide support for” blurs accountability, leading to misunderstandings and comments such as: 

• “I thought you were doing that!” 

• “Wait, you mean we have to write the test cases?!?” 

Without crystal-clear agreements, your team risks being caught off guard by hidden resource demands, unexpected dependencies, and escalating costs. 

Introducing the RASCI approach 

The RASCI model provides a structured way to define and communicate responsibilities between all key stakeholders in the transformation programme for the core activities that need to be undertaken - against each entry we define which stakeholder is either Responsible, Accountable, Supporting, Consulted or Informed: 

• R – Responsible: Who actually does the work. They are ultimately responsible for the success and end-to-end execution and assurance of the tasks assigned. Every item in the RASCI must have an (R) and an (A). 

• A – Accountable: The ultimate decision-maker, answerable for the outcome. Success will require assigning only one person as accountable for each task, so that decision authority is clear. 

• S – Supporting: Provides active help in completing the task, but not in a lead/decision making capacity. 

• C – Consulted: Provides input and expertise, but not execution. This is a more reactive/supportive role, rather than a decision maker's proactive one. 

• I – Informed: Kept up to date, but not directly involved. 

Using a RASCI forces both the SI and client to explicitly state who owns what across every phase of the project: Discover, Prepare, Explore, Realise, Deploy and Run – not forgetting key considerations for Data and Organisational Change Management. 

The Risks of Skipping This Step 

Research shows that 55–60% of major business application initiatives deliver compromised results. Many overrun, exceeding their allocated time and/or budget includes and most don’t deliver the expected value. In addition to items such as Organisational Change Management and Data Quality, one of the key contributing factors is not clearly defining the roles, responsibilities and deliverables from the outset – ideally this should be done during the SI selection process and certainly be present before the agreement of the associated Statement of Work (SoW).  

Common pitfalls with an ill-defined set of Roles and Responsibilities include: 

• Hidden Client Dependencies: The SI assumes you’ll provide skilled staff for workshops, testing, or data cleansing - yet you weren’t aware of the scale of commitment. 

• Overlaps and Gaps: Multiple parties think they are responsible for the same activity, or worse, no one is 
  

• Project Delays: If internal dependencies (e.g. providing project managers or business SMEs) aren’t costed and planned, delays and overruns are inevitable 

• Change Requests Galore: If you don’t have the expertise or capacity to undertake work that was assumed as your responsibility it leaves the door wide open for costly CR’s (leading to unexpected costs) so that the SI can undertake the work and protect the project timeline 
  
  

How to Use a RASCI Effectively

When reviewing SI Statement of Work proposals, insist on a RASCI table that: 

• Covers all activities - down to task level where appropriate, e.g. data migration: extraction, cleansing, mapping, loading.  

• Assign only one “A” per activity to avoid blurred accountability. 

• Sets clear expectations of SI involvement - particularly in data-related tasks, testing, and training. Also consider additional 3rd parties, separate to the main SI 

A well-structured RASCI not only avoids finger-pointing later but also provides a fair basis for comparing vendor proposals (especially resource costs). When every bidder presents their plan against the same framework, you can see who is truly taking responsibility and who is shifting responsibility and risk back onto you. 

Sub-note: As part of the wider SoW you should also ensure that staff profiles for the senior delivery team roles are provided to prevent the so-called ‘B-Team’ problem – Where the SI promises senior experts during sales, but deploys less experienced staff during delivery. 

The Payoff 

Getting roles and responsibilities right during the transformation preparation phase (Phase Zero) may feel like a detail that should be left for later, but it’s one of the most important steps in protecting your investment. It enables you to: 

• Compare proposals fairly across SIs 

• Plan and fund internal resources realistically 

• Prevent hidden costs and delays during delivery 

• Set the foundation for a collaborative relationship with your SI 

In short: define responsibilities before you sign, not after problems emerge. 

Take the Next Step 

We’ve prepared a practical SAP S/4HANA transformation project RASCI template to help get you started mapping responsibilities across your programme. Use it to clarify expectations with your chosen SI, including additional 3rd parties, and avoid costly surprises down the line. 

Download the RASCI Template, here.