What SAP Programmes Teach You That Agile Books Never Will

The project that took three years and taught me everything

My first serious programme was an SAP rollout across more than fifteen countries for a global brand. I was young, I was from Accenture, and I believed that if the blueprint was solid and the governance model was clean, delivery would follow. It mostly did. But what I remember most are not the go-lives. I remember the moments when the plan met reality and reality won.

Large ERP programmes are unfashionable now. Everyone wants microservices, two-week sprints, and a Figma prototype by Friday. That is fine. But if you have never run — or survived — a programme where a single cutover weekend puts the invoicing of an entire region at risk, you are missing a category of experience that agile delivery alone will never give you. And if you are now building AI platforms or digital public services, that experience is more relevant than it looks.

What large ERP programmes actually force you to get right

SAP implementations are not glamorous, but they are brutally honest teachers. Here is what they force on you that smaller projects let you skip.

Scope is a contract, not a conversation

In a multi-country SAP rollout, scope is defined in a document that legal, finance, IT, and the business all sign. Change requests go through a formal board. Nothing happens informally. At the time, this felt bureaucratic. In retrospect, it saved the programme repeatedly.

When a country manager in a southern European market decided mid-implementation that they needed a custom pricing logic that did not exist in the global template, the answer was not yes or no — it was a formal impact assessment: cost, timeline, risk to other countries, and a decision by the steering committee. The request was rejected in two weeks. The programme moved on.

I have watched agile teams spend months in scope creep because nobody wanted to have that formal conversation. Agility is not the same as avoiding hard decisions. Good scope governance is not waterfall — it is discipline, and it works in sprints too.

Data migration is where the real risk lives

Every ERP programme I have ever been close to has had the same crisis, usually six to eight weeks before go-live: the data is not ready. Customer master data has duplicates. Material codes are inconsistent across legacy systems. Open purchase orders do not reconcile.

This is not a technical problem. It is a governance problem. Data has owners in the business, and those owners have day jobs. Data migration needs a dedicated workstream, a named owner on the business side, clear quality rules defined at the start, and at least three full dress-rehearsal loads before cutover. Without all of that, you will be in a war room at 2am the night before go-live.

I carry this into every data-intensive project I run now — including AI platforms. When I built the candidate data pipeline for CVChatly, I treated data quality rules as first-class requirements, not cleanup tasks. The lesson came directly from ERP programmes.

Integration is the programme, not a workstream of the programme

SAP does not live alone. It connects to HR systems, logistics platforms, customer portals, reporting tools, and often a dozen legacy applications that nobody wants to touch but everyone depends on. In most programmes I have seen, integration is treated as a technical task owned by the middleware team. That is a mistake.

Integration is where business processes actually live. The handoff between the order management module and the warehouse system is not a technical interface — it is a business decision about who owns the process, what happens when it fails, and who gets called at 3am. Those decisions need to be made by people with authority, not resolved by developers at the last minute.

This maps directly to how I think about LLM agent orchestration today. The boundaries between agents — what each one owns, what happens on failure, how errors propagate — are not technical questions you can defer. They are design decisions that determine whether the system is operable in production.

Cutover planning is its own discipline

A cutover is the window — usually a weekend — when you switch off the old system and switch on the new one. Everything that has to happen in that window needs to be scripted, sequenced, timed, rehearsed, and owned by a named person. You need a go/no-go checklist with clear criteria. You need a rollback plan that everyone has actually read. You need a communications plan for every stakeholder group, including the ones who will call the helpdesk in a panic on Monday morning.

I have seen cutovers with a 200-step runbook where step 47 had a dependency on a vendor action that was never confirmed. I have seen cutovers where the rollback plan existed on paper but had never been tested and was technically impossible. Both of those programmes had difficult Monday mornings.

The discipline of cutover planning — extreme attention to sequence, dependency, and failure mode — is directly transferable to any complex deployment. It is how I think about releasing AI features that touch live user data. You do not wing it. You run it like a cutover.

What large ERP programmes get badly wrong

Being a good teacher does not mean being a good model. There are things about classic ERP delivery that I would not carry forward.

The assumption that the template is always right. Global template programmes often treat local business requirements as deviations to be minimised. Sometimes that is correct — standardisation has real value. But sometimes the local requirement reflects a legal obligation, a market reality, or a user need that the template designers never encountered. The instinct to protect the template above all else produces systems that technically work but that nobody in the local market can actually use.

The distance between the system and the user. Classic SAP implementations are designed by consultants, configured by developers, and handed to users in a three-day training session before go-live. The people who will use the system every day are consulted in workshops at the start and then largely ignored until UAT. This is backwards. The people who know where the process actually breaks are the people doing it. Getting them involved continuously — not just at the bookends — produces better systems and faster adoption.

The belief that a big programme requires a big team. Large programmes accumulate people. Every workstream needs a lead, every lead needs a deputy, every deputy needs a coordinator. By the time you have three hundred people on a programme, a meaningful fraction of the effort is spent on internal communication and reporting rather than delivery. I have seen smaller, more focused teams deliver comparable scope faster, with less overhead and fewer coordination failures.

The practical takeaway

If you are running a complex IT programme today — whether it is an ERP migration, a digital public service, or an AI platform — the fundamentals that large SAP programmes enforce are still the right ones: clear scope with a real change process, data quality treated as a first-class concern, integration designed at the business level not just the technical level, and deployment planned like a cutover with named owners and tested rollback.

What you do not need to carry forward is the distance from users, the deference to the template, or the belief that scale requires bureaucracy rather than discipline.

Twenty years in, I still think about those early programmes when I am making architecture decisions or writing a deployment checklist. Not because the technology is the same — it is not, at all — but because the failure modes are. Scope that nobody agreed on. Data that nobody cleaned. Integrations that nobody owned. A go-live that nobody rehearsed.

The tools change. The ways projects fail do not.