SAP project scope template: what to define and exclude

An SAP project scope template defines what the programme will deliver, what it will deliberately not deliver, who owns each part and how scope can change. The nine sections below cover it. The two that matter most are the ones teams skip: explicit exclusions and data migration scope. Fill the template before configuration starts and get it signed by the sponsor and the process owners.

Sometimes teams fill out a scope template and move on. That part feels easy. Weeks later, during design or build, someone flags a process that was "assumed to be in scope". The conversation gets uncomfortable. Nobody wrote it down. Nobody meant to leave it out. I have seen this happen too often. A few unchecked assumptions at the start quietly push the project weeks off course.

The scope document's job is not to record what people said in the room. It is to force clarity before configuration locks in assumptions that are expensive to reverse.

These are the nine sections, with what each must answer.

1. Objectives

Why is this work being done, and what will the business see when it is finished? Tie each objective to a measurable outcome: reduce the month-end close by three days, remove manual reconciliations across three entities, one view of inventory across all plants. Vague objectives produce vague success criteria, and the disagreement surfaces in user acceptance testing (UAT).

2. Scope definition

Modules, legal entities, plants, countries, languages, integrations and the deployment model. Be specific. "Finance" is not scope. "Financial Accounting and Controlling (FI/CO) covering payables, receivables, general ledger and cost centre accounting for the UAE legal entity on S/4HANA Cloud Private Edition" is scope.

3. Exclusions

This is where most scope templates fail. If something is not written as excluded, someone will assume it is included. Exclusions to write down by name:

1. Countries or entities deferred to a later phase.
2. Legacy integrations kept as they are for now.
3. Historical data before a defined cutoff date.
4. Reports moved to a post-go-live enhancement list.
5. Regulatory requirements deferred pending legal confirmation.

Give each exclusion the phase it moves to, if any. A signed exclusion turns a two-week argument into a short conversation.

4. Data migration scope

A consistent blind spot. Answer three questions in writing:

1. What moves? Open items only, or history? All customers and vendors, or the active ones? Materials for every plant, or only the go-live entities?
2. What are the cutoff rules? The as-of date for open purchase, sales and work orders, and what happens to items in progress at cutover.
3. What is archived instead? Legal retention rules for history, and how long the legacy system stays readable.

Assumptions left undocumented here become disputes during build. My article on why SAP data migration fails covers the planning in depth.

5. Non-functional scope

These get dropped in planning and surface as blockers late in testing. Put them in scope:

1. Availability and the maintenance window. Under RISE, reference the availability terms in your contract.
2. Performance at peak load, such as month-end close.
3. Audit logging: which transactions, and how long logs are kept.
4. Security and access control by role.
5. Reporting latency: real time, near real time or daily.

They are not features. They are constraints the system must meet. If they are not in scope, nobody designs for them.

6. Roles and responsibilities

Every workstream needs a consultant lead and a business counterpart with decision authority, both named. The gap I see most is UAT ownership: who can sign off that a process is tested and accepted? Decide that before build starts, not two weeks before go-live.

7. Change control

Not "changes require formal approval". A specific process: what triggers a change request, who assesses the impact on time and budget, who approves, and what gets recorded. Without it, "can we add this?" becomes "we thought that was included" and then a three-week extension nobody planned.

8. Extension rules

How custom development will be approved. SAP now classifies extensions from level A, released APIs only, to level D, modifications to the core (SAP News, August 2025). On Public Edition under GROW the system only allows released interfaces. On Private Edition under RISE and on-premise, the core can still be modified, so the scope should state the target level and who approves exceptions. My clean core guide explains the levels.

9. Assumptions and constraints

List the assumptions behind the scope so someone has to check them. Then the constraints: regulatory deadlines that fix a go-live date, budget ceilings, people who are only part-time, and legacy decommission dates.

Customisation is the form of scope creep that takes longest to show. One approved custom report becomes five. One workflow exception becomes the precedent for every request after it.

Classify every request before you approve anything:

Category	Test	What to do
Essential	The process cannot legally or operationally work without it	Approve, with the cheapest extension that is upgrade-safe
Important, not critical	Improves efficiency but is not a showstopper	Approve only with a clear cost-benefit case
Unnecessary	A preference, or a copy of how the legacy system worked	Challenge it, then reject or defer

Most unnecessary customisations exist because someone did not want to change how they work, not because SAP could not support the process. And the build cost is only the start. Every custom object adds testing, training, documentation and upgrade work for as long as it lives.

Set a change freeze. Pick a date, typically four to six weeks before go-live, after which no new requests are accepted for the release. Everything later goes to the post-go-live backlog. The freeze needs the steering committee's signature behind it. A date announced only by the project manager will be overruled the first time a department head pushes.

1. 01Request raisedWhat counts as a change is defined up front
2. 02ClassifiedEssential, important or unnecessary
3. 03Impact assessedTime and budget, by a named assessor
4. 04DecisionA named approver approves, rejects or defers
5. 05Scope versionedNew version number and a list of what changed

After the change freeze, new requests go to the post-go-live backlog

Analytics is where scope conversations get heated. Everyone wants reports and nobody says how many.

Agree a fixed report list during design. Ask people what they need, not what they might want. Mark each report as standard SAP output or custom development, and get the list signed with the rest of the scope. Standard reports cost a fraction of custom ones. Identify each report's data sources at the same time; a report that pulls from three systems is an integration requirement. If dashboards and planning are in scope, my SAP Analytics Cloud guide covers what to settle first.

Mistake	What it causes	How to avoid it
Objectives not measurable	UAT disputes over what "working" means	Set measurable outcomes at the start
Exclusions not written	Work absorbed without approval	List what is out of scope, by name
Data migration scope vague	Wrong volumes, slipped cutover, rework	Define what moves, cutoffs and archiving
Non-functional requirements missing	Audit and performance problems at go-live	Put availability, performance, logging and security in scope
No named UAT owners	Testing drags, nobody can sign off	Name individuals with authority
No change control	Informal additions, compressed testing	Write the change process into the scope
No sign-off	Scope challenged later without accountability	Sponsor and process owners sign
Analytics left for later	Report requests two weeks before go-live	Agree the report list during design
Deployment model or extension rules open	The debate runs into the build phase	Decide both before scope is signed

Review the scope at every SAP Activate phase gate and after every approved change, with a version number and a list of what changed. The scope belongs in the project charter by reference, so both documents tell the same story.

This guide is part of my SAP implementation hub, which links every topic from the business case to go-live.

What should an SAP project scope template include?

Nine sections: objectives with measurable outcomes, scope definition (modules, entities, countries, integrations, deployment model), explicit exclusions, data migration scope, non-functional requirements, named roles, change control, extension rules and assumptions with constraints. Exclusions are the section most often missing.

How do you prevent scope creep in SAP projects?

Write exclusions explicitly, run every change through a formal request with an impact assessment and a named approver, classify customisations before approving them, and set a signed change freeze four to six weeks before go-live. The aim is not to refuse all change. It is to make change visible, assessed and authorised.

What is data migration scope in an SAP project?

The definition of which data moves into SAP and under what rules: which objects (customers, vendors, materials, open orders, history), the cutoff dates, and what is archived instead of migrated. It drives effort and timeline, and it decides how long legacy systems must stay accessible.

What is non-functional scope in SAP projects?

The constraints the system must meet as opposed to the processes it supports: availability, performance at peak load, audit logging, security and access control, and reporting latency. They are often left out of scope and then found in testing. In regulated industries, audit logging is a legal obligation.

How should customisations be handled in the scope?

Classify each request as essential, important or unnecessary. For each approved one, record the requirement, why standard SAP does not meet it, the effort, the test impact, the maintenance cost and the extension approach. On Private Edition and on-premise, state the target clean core level and who approves exceptions.

When should SAP project scope be reviewed?

At each SAP Activate phase gate, after every approved change request, and whenever budget, resources or timeline change. Keep every version with a date, a version number and a summary of what changed. That history protects the team when scope is challenged later.