SAP project planning and control: keep projects on track

Most SAP programmes have a plan. Far fewer have control. Planning sets scope, timeline, budget and risks. Control is the weekly work of tracking progress against that plan, managing dependencies, escalating early and assessing every change before it is approved. This guide is for programme directors, PMOs and sponsors whose SAP programme is drifting, or who want to stop it drifting. It covers what control looks like, three public failures that show what happens without it, and a weekly control cadence with owners you can adopt this week.

When I started out, I worked on an SAP programme that looked great on paper. Timelines, risk registers, change logs, everything you would expect. Nobody followed it. The steering committee rarely met. Finance was waiting on data migration. IT had not started. Nobody tracked dependencies. Everyone assumed someone else was keeping things on track.

By month six, half the project was behind schedule and we were chasing our own mistakes. The worst part was that nobody saw it coming.

It was not a planning problem. It was a control problem. There was no real resource allocation, no proper risk mitigation and no escalation path. The plan had been produced once and then abandoned in favour of meetings.

Planning covers scope, timeline, budget, resources, the risk register and milestone commitments. Most teams produce this. The question is whether anyone uses it week to week.

Control covers tracking actual progress against the plan, surfacing variances early, managing dependencies, escalating when things slip and re-baselining when scope or timeline formally changes. Most teams do this poorly.

1. 01Track progressActual against plan, by work package
2. 02Surface variancesAny task three days late
3. 03Check dependenciesWho is blocked if this slips
4. 04EscalateOn a path agreed in advance
5. 05Assess changesTime, cost and resources first
6. 06Re-baselineOnly after a formal change

Every week, with named owners

Here is what breaks when control is missing:

What breaks without control	Why it happens
Deadlines slip silently	Nobody checks between milestone reviews
Assumptions go unverified	Each team expects another to handle the dependency
Scope expands informally	Changes approved in meetings with no impact assessment
Risks ignored until they land	Risk log updated quarterly instead of weekly
Costs run past budget	Effort sits in timesheets but is not mapped to work packages
Teams stop communicating	Status meetings become updates with no actions

These are public cases, not client stories. Their root causes are the ones I see repeatedly in advisory work.

Lidl: about seven years and an estimated €500 million, then stopped

Lidl started its eLWIS project on SAP Retail in 2011. Its inventory valuation practice differed from SAP's standard model, and Lidl chose to adapt the software rather than the practice. By 2018 the system was live in Austria, Northern Ireland and the US, but the board concluded that the original goals were not achievable at reasonable cost. Lidl stopped the project and went back to developing its in-house system. Trade press estimated the spend at around €500 million, and the IT board member had left in 2017. Heise reported the decision in July 2018. The lesson: years of customisation to protect a legacy practice is a control failure, not a software failure.

Hershey: about $100 million of Halloween orders not delivered

Hershey's new SAP, Siebel and Manugistics system was planned to go live in April 1999, a quiet month for confectionery. It slipped three months and went live in July, as Halloween orders started arriving. Orders could not get from the system to the warehouses. The CEO told analysts the problems would keep Hershey from delivering about $100 million of product for Halloween, and third-quarter sales fell 12.4%. CIO magazine's account puts the real failure down to timing. A schedule control that protected the peak season would have forced a different go-live date.

Revlon: a plant disrupted and a material weakness in controls

Revlon switched on SAP at its Oxford, North Carolina plant, its largest manufacturing site, in February 2018. Service disruptions hit manufacturing and shipments to large US retailers. In March 2019 Revlon disclosed a material weakness in internal control tied to the rollout, citing no effective continuous risk assessment and too few trained people in the affected operations. Investors sued; TechTarget covered the lawsuit, which claimed about $64 million of shipments went unfulfilled.

None of these failed because SAP was the wrong choice. They failed on planning and control fundamentals that have existed for decades.

Work breakdown structure

A work breakdown structure (WBS) breaks the total scope into deliverables with clear owners. Without it, work is invisible until it is late. For an SAP programme it covers process design, configuration, data migration, integration, testing, training and cutover, each broken down to tasks with an owner and a due date.

The value is not the document. It forces the conversation about what needs to happen, who does it and what it depends on. Dependencies are what kill projects. A delay in data migration blocks integration testing, which blocks UAT, which squeezes the cutover window. A WBS makes that chain visible.

Schedule management

Timelines fail for predictable reasons. People get pulled. Estimates were wrong. Decisions take longer than planned. Build contingency in from day one, as explicit buffer next to the tasks most likely to need it, not as padding spread everywhere.

Track the schedule weekly. A one-week delay in week four is a conversation. A four-week delay in week sixteen is a crisis. Same issue, very different cost to fix.

Treat go-live timing as its own decision. Never go live into a peak business period. Hershey's lesson applies to every company.

Budget control

Budgets break for three reasons: unmanaged scope changes, underestimated data migration and hypercare costs above early estimates. Track actual spend against plan from week one. By the time a variance reaches the steering committee, it is usually too late to correct without disruption.

Change control is the main budget protection. Every scope change gets an impact assessment on time, cost and resources before approval. If the assessment comes after the approval, the change has bypassed the budget. My guide to avoiding scope creep in SAP implementations goes deeper on the change board.

Risk management

A risk register maintained quarterly is theatre. Risks need weekly review, named owners and response plans. Name these on every SAP programme: data quality found late, integration delays, gaps in resource availability, cutover window compression and poor user adoption.

One client lost three months when its data migration vendor missed deadline after deadline. We kept hearing "just two more weeks" until it was too late to switch vendors without blowing the budget. A risk with an owner and a trigger date would have forced that decision months earlier. My SAP risk assessment matrix gives a template for scoring and owning these risks.

Communication and escalation

Executives need headlines. Delivery teams need specifics. Project managers need variance data. One update for everyone helps nobody.

Document and rehearse escalation paths before a crisis. On one SAP implementation, IT assumed finance was reviewing the configuration and finance assumed IT was. Nobody raised it until go-live was three months away and critical approvals were missing; the fix was a last-minute scramble, extra cost and a delayed rollout. Another company did it right: reporting was structured and tied to actions, so when an issue came up, everyone knew who owned it, what the impact was and how it would be resolved.

Scope is where escalation earns its keep. I worked with an airline that started with a simple booking upgrade (more on SAP for aviation). Six months in, it had added loyalty changes, crew scheduling and finance modules. None were urgent. Nobody said no. The timeline doubled and costs rose 70%.

The on-premise playbook does not survive RISE with SAP unchanged. Three things are different.

RISE changes who you escalate to

Under RISE with SAP, SAP runs the infrastructure and technical operations and provides a customer success team that tracks adoption. Your control structure has to include them. For platform issues (system performance, hyperscaler region, SAP service levels), the programme manager needs a documented escalation path to SAP that does not run through the implementation partner. Write it down before you need it.

Clean core gives scope control a technical backstop

Every gap now needs a decision: configure it, extend it through released APIs (on-stack with ABAP Cloud or side-by-side on SAP BTP), or reject it. On S/4HANA Cloud Public Edition, modifying the core is not an option. On private edition and on-premise it is possible, but SAP's clean-core guidance treats it as the last resort, because every modification adds upgrade work.

That helps scope control. A request to "just tweak the standard order-to-cash process" stops being a casual configuration chat and becomes an extension with design, build and test effort. Put a small extension review forum below the steering committee, with one architect who has the authority to approve or reject. Without it, every customisation argument ends up at steering.

AI drafts the reports, people make the calls

AI now helps with the paperwork of control. SAP Cloud ALM, SAP's application lifecycle tool, holds project tasks, requirements and test status, and can generate requirement drafts from workshop transcripts. Microsoft Copilot drafts variance summaries for steering packs from dashboards and status reports. Anomaly detection in Power BI or SAP Analytics Cloud flags KPIs that drift from their usual pattern. That is useful for resource use, change request volume and support tickets, less so for metrics that swing naturally.

What AI does not do is act. A dashboard can show schedule slippage in red for six weeks. If the steering committee does nothing, the slippage continues.

This is the minimum rhythm for a programme in active delivery. If any row is missing, add it before anything else.

Control	Minimum practice	Owner	Frequency
Work breakdown structure	Every task has an owner, a due date and its dependencies	PMO lead	Updated weekly
Schedule review	Flag any task more than three days late; check the critical path	Programme manager	Weekly
Budget tracking	Actual against plan by work package	Programme finance lead	Weekly, reported monthly
Risk review	Every active risk has an owner, a trigger and a response	Workstream leads	Weekly
Change control	Impact assessment on time, cost and resources before approval	Change board chair	Weekly or as requests arrive
Extension review (RISE and GROW)	Configure, extend or reject decision for every gap	Solution architect	Fortnightly
Steering committee	Decisions, not status; papers sent in advance	Executive sponsor	Fortnightly; weekly in cutover and hypercare

Most planning and control fails not because the method was wrong but because the discipline was dropped by month four. Keep the cadence small enough that the team will still run it in month fourteen. If your programme is already off track, this is how I help bring an SAP implementation back on course. For the steering committee itself, see my guide to creating an effective SAP steering committee.

What is the difference between project planning and project control?

Planning produces the roadmap: scope, timeline, budget, resources and risks. It sets direction at the start.

Control is the ongoing work of tracking progress against that plan, surfacing variances, managing dependencies and re-baselining when formal changes occur. It happens every week for the life of the programme.

Most SAP programmes invest heavily in planning and too little in control. By the time variance shows up at steering, weeks or months of recovery cost have built up.

Why do SAP projects fail despite having a project plan?

Because nobody works the plan. Dependencies are not tracked, so one workstream's delay silently blocks another. Risk logs are updated quarterly. Scope changes are approved informally. The steering committee meets monthly and sees milestone summaries that hide what is happening on the ground.

Lidl, Hershey and Revlon all had plans. What they lacked was active control: honest tracking, early escalation and a real response when warning signs appeared.

How do I manage scope creep on a long SAP programme?

Give every scope change a written impact assessment before approval: time, cost and resources. Without it, approving a change means approving an unknown.

The most effective rule: any addition must displace something else. That one constraint makes business leads prioritise honestly.

Executives have to back it. When a CFO or COO publicly supports change control, informal requests drop quickly. On RISE and GROW programmes, the extension decision for every gap adds a technical check on top.

What is a work breakdown structure and why does it matter for SAP?

A WBS breaks the total scope into deliverables, each with an owner and a due date. On an SAP programme that means process design, configuration, data migration, integration, testing, training and cutover, all broken down to tasks.

Its practical value is dependency mapping. Data migration feeds integration testing, which feeds UAT, which feeds cutover. When one slips, the downstream impact is visible straight away.

How does RISE with SAP change project planning and control?

SAP becomes a participant in delivery. It runs infrastructure and technical operations, and its customer success team runs its own cadence on adoption and value.

Three changes follow. You need a documented escalation path into SAP for platform issues that does not go through the partner. You need an extension review forum below steering to decide how every gap is handled under clean core. And you should fold SAP's customer success cadence into your governance rather than run it in parallel.

What should a steering committee do on an SAP programme?

Make decisions. Its job is to resolve what the programme team cannot: resource conflicts, scope disputes, budget changes and anything needing cross-functional authority. A steering meeting that ends without decisions was a status update.

Monthly steering on a large programme leaves issues waiting up to four weeks. Fortnightly is the minimum in active delivery, weekly in cutover and hypercare. Send progress reports in advance and use the meeting for the decisions they raise.