SAP project risk assessment: the practical version

An SAP project risk assessment lists what could derail the programme and scores each risk by probability and impact. Each risk gets one named owner and a response agreed before it happens, and the list is reviewed every week. The risks that sink SAP programmes are rarely surprises: data migration, integration, people availability, scope drift and adoption. This guide is for programme managers and sponsors who want a risk register that changes decisions rather than one that sits in a folder. It gives you a scored matrix, a register template, three public failures as worked examples, and the risks RISE with SAP and clean core add. Start by putting a named owner against every risk you already have.

Most SAP risk assessments get built before the first steering committee, reviewed once, and never touched again. That is not risk management. That is a document.

I have seen risks ignored because they were too uncomfortable to raise early. That silence almost always costs more later. What starts as a small integration issue in Materials Management suddenly blocks Finance. A report that looked fine in testing breaks after a system update. I have seen that happen more than once.

The risks were not surprises. They were documented. Nobody acted on them.

Scope. The project starts with standard modules. Then someone adds "just one more report", then a dashboard, then a few enhancements. The danger is scope changes introduced informally in workshops, emails and hallway conversations that the project manager hears about only after configuration is done. My guide to avoiding scope creep covers the controls.

Resources. The architect gets pulled onto a production issue. A key developer leaves. Business users miss test cycles because their day jobs do not stop. Get availability in writing. Verbal promises evaporate under headcount pressure.

Technical. Field mappings never validated against the target structure. Interfaces that pass unit testing and break at real transaction volume. Custom code that looks fine until production load. These are predictable if you know where to look.

Timeline. A late blueprint squeezes testing, but the go-live date stays fixed. UAT, training and data preparation get rushed. The same pattern appears on almost every programme that misses a phase gate and does not move the downstream plan.

Adoption. People reject what they do not understand. Weak or late training produces workarounds, workarounds degrade data, and the system gets blamed for a change management failure.

These cases are public and well documented. The patterns repeat at every scale.

Lidl: about €500 million over seven years

Lidl started its eLWIS project on SAP for Retail in 2011, went live in some smaller countries, and dropped it in 2018 at a reported cost of about €500 million. One widely reported cause: Lidl valued inventory at purchase prices, while SAP's standard retail model uses retail prices. Lidl customised rather than change the practice, and the company said the original goals could not be achieved with reasonable effort.

Lesson: a mismatch between your data model and SAP's standard is a week-one risk, not a year-five discovery.

HP: about $400 million in lost revenue

In 2004 HP migrated part of its server business onto a consolidated SAP-based order and supply chain system. Orders fell out between the legacy front end and SAP and needed manual work, and the backlog doubled. HP's CEO said the problems cost the server and storage group about $400 million in revenue and $275 million in operating profit, leaving a $120 million backlog. HP's CIO later said the team had planned for three weeks of disruption and should have had contingency for four to six.

Lesson: size the contingency for a bad cutover, not an average one, and build inventory or channel buffers before you switch.

Nike: more than $100 million in lost sales

In 2000 Nike went live with i2 demand-planning software before its SAP ERP programme. The software was heavily customised to work with Nike's legacy systems, ran slowly and crashed under the product volume. It ordered too many of some shoes and too few of others. Nike lost more than $100 million in sales and its stock fell about 20%. Nike later moved short- and medium-range planning into SAP.

Lesson: never assume an integration works until it has run at production volume with real data.

An assessment built on assumptions is worse than none, because it creates false confidence. Six inputs matter:

1. Scope documentation: charter, approved scope and signed requirements. If they do not exist, scope risk is already high.
2. Resource commitments: written commitments from department heads, a skills matrix for critical roles, and a named backup for every key position.
3. Budget and timeline: approved budget with contingency, and a timeline checked against comparable programmes. Six months and minimal funding for a full rollout is a risk to call out now.
4. Vendor commitments: contracts with service levels and penalties. On RISE, SAP's responsibilities and escalation route.
5. Technical landscape: legacy compatibility, data migration complexity, deployment model and a clean-core plan for any custom work.
6. Past project logs: risk registers, issue logs and post-mortems from earlier SAP or ERP programmes. Most risks are not new.

Score each risk on probability and impact from 1 to 5 and multiply. The example below is a typical starting point for an S/4HANA programme; your scores will differ.

Risk	Probability (1-5)	Impact (1-5)	Score	Priority
Data migration failure	4	5	20	High
Integration delays	4	4	16	High
Resource constraints	4	4	16	High
Budget overrun	3	5	15	Medium
Custom code in the core blocking upgrades	3	5	15	Medium
Scope creep	4	3	12	Medium
Test coverage gaps	3	4	12	Medium
Performance under peak load	3	4	12	Medium
Compliance gaps	2	5	10	Medium
No escalation route into SAP (RISE)	2	5	10	Medium
Low user adoption	3	3	9	Medium
Subscription or licence cost exposure	2	4	8	Medium
KPIs not tracked	3	2	6	Low

Scores of 16 and above need a named owner and action now. Scores from 8 to 15 need monitoring with a defined escalation trigger. Below 8, keep it on the register without spending priority time on it. Scores are a starting point, not a verdict: a compliance gap scored 10 can become 25 in a regulated industry.

A score alone changes nothing. Each risk needs these fields, filled in.

Field	What to write	Example
Risk	The event, in one sentence	Vendor master data is not cleansed before mock load 2
Owner	One named person	Accounts payable lead
Score	Probability × impact	4 × 5 = 20
Trigger	The measurable point at which you act	Duplicate rate above 5% in the mock 1 extract
Response	Avoid, mitigate, transfer or accept, with the action	Mitigate: two AP analysts on cleanup for three weeks
Next review	Date	Next Monday's risk review
Status	Open, in action, closed	In action

Put the cost in real terms where you can. "High risk" is vague. "A one-week UAT delay costs about six figures in team time and may push go-live three weeks" gets attention.

Custom code is a risk category of its own. On S/4HANA Cloud Public Edition, custom code in the core is not possible. Extensions go through SAP BTP, released APIs or key-user tools. On private cloud and on-premise you can still modify the core, and partners who are used to doing so will. That technical debt surfaces at the first major upgrade. Track how many identified customisations have an agreed clean-core approach, check the partner's BTP extension experience, and stand up a review forum by the end of Explore.

RISE changes who owns availability. SAP runs the infrastructure, so the risk shifts from "our team owns availability" to "SAP owns it and we need a fast way in when something fails". Record SAP's named contacts, the escalation route and service levels, and an incident plan agreed before go-live. Without them, problems that should go to SAP sit inside the project team too long.

AI helps with the paperwork, not the judgement. Joule-based assistants in SAP Cloud ALM and tools such as Microsoft Copilot can draft register entries and steering packs from status reports, defect logs and minutes. That speeds up register maintenance on programmes with clean source data. It finds risks already visible in the data. It does not decide which risks deserve action, get owners to act, or escalate the risks leadership would rather ignore.

1. Identify risks across all five categories. Run workshops with IT, the business and vendors; each sees different risks. On RISE, include SAP's contacts in at least one. The risks teams usually miss: IT and business expecting different things, poorly defined external integrations, UAT owners who are not available, and informal scope changes.
2. Score each risk on probability and impact, with real numbers where possible.
3. Assign one owner per risk. A person, not a team. No owner, no tracking, no resolution.
4. Define the response before the risk lands. Avoid, mitigate, transfer or accept. "Monitor and respond" is not a plan. It is a deferred decision.
5. Review weekly. Check open risks, add new ones, rescore where conditions changed and escalate anything near its trigger. Bring the top risks to the steering committee with a proposed decision rather than a colour.

1. 01IdentifyAll five categories
2. 02ScoreProbability × impact, 1 to 5
3. 03Assign an ownerOne person, not a team
4. 04Define the responseAvoid, mitigate, transfer or accept
5. 05Review weeklyRescore, escalate near triggers

16 or above: a named owner and action this week

What is a risk assessment in an SAP project?

It is the process of identifying what could go wrong, scoring each risk by probability and impact, giving each one an owner, and agreeing a response before it happens. SAP programmes run several modules, integrations, a data migration, a change programme and a fixed go-live at once, so informal risk management does not hold. A short list of real risks with owners beats a long document nobody reads.

How do you build a risk matrix for an SAP project?

List risks across scope, resources, technical, timeline and adoption, plus clean core and SAP escalation on RISE. Score each on probability and impact from 1 to 5 and multiply. Treat 16 and above as high, 8 to 15 as medium and below 8 as low. Give every medium and high risk an owner and a measurable trigger, such as "if UAT completion is below 80% by week 16, the go-live date goes to review". Rescore weekly and at every phase gate.

What are the most common risks in SAP implementations?

Data migration failure, because legacy data is almost always messier than estimated. Integration delays, especially with undocumented legacy interfaces and third-party vendors. Scope creep that compresses testing and training. Resource constraints such as key people pulled away or users unavailable during UAT at month-end. Low adoption from training that demonstrates screens instead of simulating the job. On RISE, add custom code in the core and the lack of an escalation route into SAP.

When should a risk assessment be done during an SAP project?

Before the project starts, when structural risks such as data model mismatches or unrealistic timelines are cheapest to fix. Before every SAP Activate phase gate, because each phase changes the risk profile. Whenever scope, budget or resources change. And when a risk turns into a problem, to check what else it affects. In between, review weekly.

Who should own risks in an SAP programme?

The person who can act on them. The data lead owns data migration risk, the technical architect owns integration risk, the change lead owns adoption risk, and the solution architect owns clean-core risk. On RISE, the CIO or programme director owns the escalation route into SAP. The programme manager tracks the health of the register but does not own every risk.

What happens when ERP risk assessment is skipped?

At scale, you get cases like Lidl, which dropped its SAP retail project in 2018 after about €500 million. Or HP, whose 2004 SAP order system migration cost its server group about $400 million in revenue. At smaller scale the mechanism is the same: data model mismatches found late, integrations failing at production volume, and adoption failures from weak training. The risks were identifiable before they became problems.