How to create an SAP implementation project charter

An SAP implementation project charter is the short document that formally authorises the programme. It settles, in writing, what the programme will deliver, what it will not, who decides, how success is measured and by when. Write it before vendor statements of work are signed, have the client sponsor own it, and make it specific enough to settle an argument. A section-by-section outline is below.

Teams dive into SAP kickoff meetings with confidence. Then they find roles were vaguely defined, scope boundaries were never agreed, and nobody can say what success looks like. A charter should prevent that. Most do not, because they are written to satisfy a governance requirement rather than to anchor the work.

I have seen project charters that look clean but fail to connect to real plans. The version that works is the one people argue about during drafting. That is how you know it is honest.

Three documents get confused on every large SAP programme. They do different jobs.

Document	Purpose	Created by	Timing
Project proposal	Justify why the project should happen	Business sponsor	Before approval
Project charter	Authorise the project; fix scope, objectives, named owners and governance	Sponsor with the programme manager	At initiation
Project plan	Define how the work gets done: tasks, resources, dependencies	Programme manager	After the charter is approved

The charter is the governance document. It draws lines. If your S/4HANA programme spans several modules, countries and vendors, the charter is where you decide what is included before people start making their own assumptions.

Objectives tied to a business outcome

Not "system modernisation". Each objective needs a number. The test: can you explain the vision to a board member in 30 seconds without slides?

I have worked on SAP programmes where everyone celebrated at go-live, and two months later nobody could say whether it delivered the value promised. A manufacturing client spent over $4 million and could not demonstrate any return. The CFO asked for metrics. Nobody had them, and it delayed their next funding round.

Contrast that with a retail client I supported. Its charter had defined KPIs from day one. They showed a 32 percent drop in order processing costs, and phase 2 was approved immediately.

Scope with explicit exclusions

This is the most overlooked section. Teams write detailed in-scope lists and leave out the exclusions, which is exactly where the arguments happen.

I worked with a healthcare company that kept its SAP rollout focused this way. The marketing head wanted to add analytics for campaign tracking during user acceptance testing (UAT). The charter had no room for it, and the steering committee flagged it immediately. That one decision saved $850,000 and avoided a six-week delay.

Named people, not departments

"Finance team: provides input on reporting" holds nobody accountable. "Finance lead, [name]: defines reporting requirements, signs off FI/CO configuration, approves data migration readiness" does.

Milestones as commitments

A retail client delayed its go-live by four months. The initial delay was a three-week slip in requirements gathering that nobody added to the schedule. They assumed they could make it up downstream. Instead they spent $1.8 million in overages.

It works the other way too. In one manufacturing engagement, the team stuck to the published plan. When the data migration team flagged a delay, the steering committee authorised staffing support straight away, because the charter made the milestone visible. That decision saved both time and $600,000.

Budget, risks and dependencies

A high-level budget, the three or four risks that could derail the programme, and the other programmes competing for the same people and money. One retail client spent $3.2 million on an implementation that never went live. Its finance redesign and SAP project ran in parallel with the same resources and budget window, and neither charter mentioned the other. Leadership caught it too late.

This is the structure I would start from. Each section should fit on a page or less.

1. Purpose and background: why now, what is broken, what happens if you do nothing.
2. Objectives and success measures: each objective with a baseline, a target and a date.
3. Scope: modules, processes, legal entities, countries, sites, integrations and data in scope.
4. Out of scope: written as carefully as the scope, with the phase each excluded item is deferred to.
5. Deployment model and extension rules: S/4HANA Cloud Public Edition, Private Edition under RISE, or on-premise, and how custom development will be approved.
6. Governance: sponsor, steering committee, design authority, change control, escalation path, with named people.
7. Roles and accountabilities: named individuals for each process area, data, testing, change and cutover.
8. Milestones: phase gates with dates and the criteria to pass them. My quality gates guide has examples.
9. Budget and contingency: the envelope, the contingency, and who can release it.
10. Risks, assumptions and dependencies: including parallel programmes and regulatory deadlines.
11. Compliance requirements: for example HIPAA in US healthcare, GxP in pharma, SOX for US-listed companies.
12. Sign-off: sponsor and business leads, with a version number and date.

1. 01Ask the people who know the workSponsors, business leads and end users
2. 02Sort must-have from nice-to-haveGo-live, phase 2 or not this project
3. 03Start from a templateThen add integration, data and compliance
4. 04Be specific enough to settle argumentsCan you prove each objective was met?
5. 05Get real sign-offRead, challenged and accepted, section by section

A charter you can point to when scope is contested in month three

1. Ask the people who know the work

Before writing anything, sit with sponsors, business leads and end users. Ask what is broken and what was tried before. I once worked with a manufacturing client that wasted $1.8 million on an SAP implementation because it assumed it knew what the shop floor needed. Six months in, it discovered the real workflow issues were not being addressed.

On a finance transformation I worked on, IT planned to roll out SAP to solve efficiency problems. Conversations with finance showed the real problem was poor data quality. If we had not asked, we would have spent millions fixing the wrong problem.

2. Sort must-have from nice-to-have before writing scope

Categorise every input as needed for go-live, phase 2 or not this project. A professional services client of mine went 40 percent over budget because requirements sat in three different places and kept getting "rediscovered" months into the project. My scope template guide helps with this step.

3. Start from a template, then add the SAP specifics

A generic template misses what makes SAP programmes expensive: integration points, data migration and cleansing ownership, module assumptions, compliance requirements and the rules for custom development. I heard about one SAP project that started with a generic charter that never mentioned data cleanup. Six months in, the legacy data turned out to be a mess, adding $750,000 and three months.

4. Be specific enough to settle arguments

I ran the implementation for a retail client in Singapore whose charter said "modernise inventory management". Half the team thought that meant faster processing. The other half focused on forecasting. The result was $1.8 million spent and no agreement on what success looked like. For every objective, ask: can I prove this was completed?

5. Get real sign-off

The charter is done when the people signing it have read it, challenged it and accepted its commitments. Walk the sponsor and business leads through it section by section. I have seen retail clients spend three full days getting charter alignment. It saved them months of arguments and scope changes later.

Mistake	What it causes	What to do instead
Vague objectives ("improve efficiency")	Teams pull in different directions	Put a number on every objective
No exclusions	Scope grows quietly	Write the out-of-scope list as carefully as the scope
Owners named by title or department only	Decisions get deferred	Name individuals
No success measures	Go-live is celebrated, value is never shown	Define KPIs before kickoff
Parallel programmes not mapped	Resource and budget collisions	Record dependencies in both charters
Charter written by the implementation partner	Scope reflects what the partner wants to deliver	Client owns it; partner contributes detail

On the last point, I am firm. Your implementation partner should not write your charter. Their incentive is to start the project. Yours is to scope it.

On RISE with SAP (Private Edition), add two things to the governance section. First, a clean core approval forum. SAP now classifies extensions from level A, released APIs only, to level D, modifications (SAP News, August 2025). Private Edition still lets you modify the core, so the forum is what stops technical debt building up. Second, an escalation path into SAP. Under RISE, SAP runs the infrastructure and technical operations. The CIO needs to know who to call at SAP when something fails at platform level, not just at the partner.

On GROW with SAP (Public Edition), the charter gets smaller. Extensions are limited to released interfaces, so the platform enforces clean core for you, and integration options are narrower. Vision, success measures, named owners and exclusions matter just as much.

AI tools can turn interview notes into a first draft faster. They cannot do the political work of the charter, which is getting sponsors to agree what they own.

What is a project charter in an SAP implementation?

The document that formally authorises the SAP programme. It sets scope and exclusions, names the sponsor and accountable people, defines success measures, sets milestones and governance, and lists the main risks. A useful charter is specific enough to settle a disagreement about scope or ownership.

What should an SAP project charter include?

Purpose, objectives with measurable targets, scope, explicit exclusions, deployment model and extension rules, governance with named people, roles, milestones with gate criteria, budget and contingency, risks and dependencies, compliance requirements and sign-off. The outline above shows each section.

What is the difference between a project charter and a project plan?

The charter authorises and defines: scope, sponsor, governance and high-level milestones. The plan executes: tasks, dependencies, resources and sequence. A plan without a charter drifts because scope was never agreed. Every plan commitment should trace back to the charter.

Who should write the SAP project charter?

The client sponsor owns it and the programme manager drafts it, with finance, IT and operations leads providing the detail. I recommend against letting the implementation partner write it. Their incentive is to start the project, not to protect you from scope you do not need.

How does RISE with SAP change the project charter?

Add a clean core approval forum that decides which extensions are allowed and at what level. Add an escalation path into SAP for platform issues, since SAP runs the infrastructure under RISE. On GROW with SAP the charter is lighter, because Public Edition enforces clean core technically.

Can the project charter change during implementation?

Yes, through change control. Treat the charter as a baseline. When scope, sponsor, budget or a major milestone changes, update it with a version number, a note of what changed and why, and fresh sign-off. Do not let it be quietly revised whenever the project drifts.