The clip above illustrates numerous aspects that are typical of a “changeAny planned or approved change to a system, process, or organizational unit—whether technical, organizational, or procedural. illusion”:

🐢 1. “Boss, we misunderstood the change decision!”

“You said we were supposed to build a new factory. But nobody told us exactly what the factory was supposed to produce. So we just built everything we could think of.”

→ Key message: Change ≠ Scope. Without deliverables, chaos ensues.

🎢 2. “The roller coaster was part of the ‘productivity boost’!”

“We thought that if the sardines slid faster, we’d produce more. So we built a roller coaster so the cans could zoom through the hall faster.”

→ Key message: When change decisions are made without requirementsRequirements that may lead to changes, absurd solutions result.

🏊 3. “The pool was a safety deliverableA tangible, versioned document or artifact (e.g., cutover plan) that is ready for acceptance and formally approved.!”

“The steering committeeStrategic decision-making body for critical escalations (Level 3). said we needed more safety. So we built a pool so no one would hit the ground hard when they fell off the roller coaster.”

→ Key message: Vague changes result in deliverables that have nothing to do with the goal.

🛶 4. “The can boats were a process harmonization project!”

“You said we should harmonize the processes. We didn’t know which ones. So we turned the cans into boats so that all employees would take the same route to their break.”

→ Key message: Without clear deliverables, “harmonization” leads to absurd interpretations.

🐟 5. “The flying sardines were an innovation deliverable!”

“You said we should be innovative. So we built wings for the sardines. Now they’re flying all over the place, shouting ‘Caipirinha!’”

→ Key message: Innovation without a defined scope leads to chaos instead of progress.

🧨 6. “We progressively elaborated on the change decision… until it exploded.”

“You said: New factory. Then it turned into: new hall → new machine → new processes → new safety concepts → new recreational activities → new employee satisfaction → new roller coaster → new pool → new flying sardine school.”

→ Key message: This is the “change illusion”: You elaborate on the change, not the scope.

📦 7. “We didn’t have any deliverables, so we just made some up.”

“No one told us what we were supposed to deliver. So we just delivered everything we could think of. Even the sardine boats. And the sardine flight school. And the roller coaster maintenance schedules.”

→ Key message: Without defined deliverables, the scope spirals out of control.

Definition:

The “change illusion” is the false assumption that a decision to make a change automatically defines the scope of work.

It occurs when organizations treat a high-level change (“We need a new factory,” “We need more security,” “We need harmonization”) as if it already contained the specific outcomes required for its implementation.

This illusion leads teams to flesh out the change themselves—by adding ideas, interpretations, and assumptions—rather than defining the actual deliverables. As a result, effort is estimated at the wrong level, scope spirals out of control, and projects descend into chaos.

A particularly charming form of the Change Illusion can be found in SAP projects. There are so-called requirements workshops, but they rarely address actual requirements. Instead of defining the target state, the discussion jumps straight to implementation. People click through SAP transactions, compare the “as-is” state with the SAP standard, discuss process variants, and decide which configurations, enhancements, or interfaces are necessary. This sounds like requirements, but it isn’t. It is change elaboration—the elaboration of the change decision that is already outlined in the charter.

The SAP methodology thus goes beyond the actual scope of the project. Requirements—that is, the target business state—are rarely documented and even more rarely communicated. Deliverables—the output objects that enable the target state—are not defined until later in the Outcome Delivery Structure. What is defined in the workshop are changes—not requirements and not deliverables. No wonder SAP projects go off the rails: the framework was never established. The organization believes it is defining requirements, but in fact, it is defining changes. And effort is estimated at the change level, even though effort only exists at the deliverable level. The “change illusion” is thus firmly anchored in the SAP methodology—and explains why so many projects fail before they’ve even really begun.

SAP requirements workshops are not requirements workshops. They are change workshops disguised as requirements workshops.

Okay, under the current SAP ActivateOfficial SAP methodology for implementing SAP S/4HANA, consisting of six phases (from Discover to Run) and focusing on standardization, agility, and compliance. methodology, the way requirements are gathered has fundamentally changed. In the past, there were long, traditional “requirements gathering” sessions to write a massive, customized requirements specification (blueprint approach). Today, SAP relies heavily on the standard.

The most important and dominant workshop type in today’s SAP world is the Fit-to-Standard workshop. This is complemented by strategic preparatory workshops and follow-up detailed sessions.

An overview of the most important workshops:

2.1. Fit-to-Standard Workshops

The goal here is to align processes with the SAP standard. The main participants are business unit managers (key usersLocal subject matter experts who act as advocates and testers during the rollout.) and module consultants.

These workshops take place during the Explore phaseA time- and content-defined section of a process model focused on specific goals, activities, and results. of the project. The standard is presented, and the company adapts to it—not the other way around. The workshops are organized by business area/SAP module and typically proceed as follows:

• Business Process Walkthroughs: The consultant demonstrates predefined standard processes (SAP Best PracticesProven methods for increasing efficiency and minimizing risk) live on a functional demo system.
• Fit Validation: Key users from the business departments verify whether their daily work can be covered by this standard process.
• Delta/Gap Identification: If something does not fit—that is, if a gap exists—it is precisely documented why the standard is insufficient and what business need requires an adjustment.

2.2. Special Workshops for Technical Requirements (RICEFW)

The goal here is to design technical solutions for gaps. The main participants are process owners and ABAP/technical consultants.

As soon as gaps or extensions are identified in the “Fit-to-Standard” sessions, dedicated in-depth workshops are conducted with the IT and technical consultants. These focus on the so-called RICEFW objects:

• Reporting workshops: Which operational reports or analytical dashboards (e.g., using SAP Fiori or SAP Analytics Cloud) are absolutely necessary?
• Integration/Interface Workshops: How will the SAP system be connected to third-party systems (measurement results, web shops, HR tools)?
• Forms Workshops: Coordination of layouts and required fields for invoices, delivery notes, purchase orders, or labels.
• Enhancements / Custom Code: Discussion of custom logic that does not exist in the standard SAP system.

2.3. Data and Migration Workshops

The goal here is to plan the data migration from legacy systems. The main participants are data analysts and IT managers.

An SAP system is only as good as its data. Since data migration is often the biggest stumbling block, dedicated sessions are held early on:

• Data Cleansing & Mapping Workshops: These sessions define how legacy data (customers, vendors, material master records) is cleansed, transformed, and transferred into the new SAP data structures (e.g., business partners).

2.4. Cross-Functional & Organizational Workshops

The goal here is to lay the foundation for the system. The key participants are the project managementResponsible for the overall coordination, planning, and strategic management of the project. team and the enterprise architects.

• Organizational Structure Workshops: Right at the start, it must be defined how the company will be represented in the system (company codes, plants, sales organizations, storage locations).

• Authorization & Security Workshops: Who will be allowed to view which transactions and data later on? Roles and profiles (e.g., for buyers, accountants, warehouse workers) are defined here.

The problem with these workshops is that they do not elaborate on deliverables, but rather on the scope.

3.1. Why “Fit-to-Standard” Workshops Define Changes

At first glance, Fit-to-Standard workshops appear to be classic requirements workshops, but from a methodological perspective, they do something entirely different. They do not define the target business state, but rather examine to what extent the existing current state can be aligned with the SAP standard. The focus is not on “What do we want to achieve?” but on “How do we need to change our current state so that it aligns with thestandard?” This does not describe the target state, but rather the change to the current state—that is, a change. The discussion revolves around process variants, system behavior, configuration options, and deviations from the standard. As soon as a gap is identified, a change automatically arises: a decision on how the current state should be adjusted. “Fit-to-Standard” is therefore not a requirement definition, but rather the systematic elaboration of changes resulting from the decision “We are implementing SAP.”

3.2. Why Technical RICEFW Workshops Elaborate on Changes

The technical workshops that deal with RICEFW objects also do not address requirements, but rather the concrete design of the changes previously identified in the Fit-to-Standard process. A requirement would describe the business benefit that a report, an interface, or a form is intended to provide. In the RICEFW workshops, however, the focus is not on benefits or the target state, but on technical implementation: data fields, tables, function modules, mapping logic, trigger points, and custom code. This is purely change elaboration. The workshops clarify how the change decisions made earlier are to be technically implemented. They do not define the business requirements, but rather the technical changesChanges to infrastructure, systems, or software to the system. Thus, RICEFW workshops are a prime example of how SAP projects jump straight into implementation without ever formulating the target business state.

3.3. Why and Workshops Elaborate Changes

and migration workshops often appear to be business-focused sessions, but they, too, elaborate on changes. The migration itself is a change: the decision to alter the current state of the data in order to transfer it to the new system. The workshops do not define the business requirements for the data, but rather how the existing data must be transformed so that it works in SAP. The focus is on mapping, cleansing, structural alignment, and technical transfer. This is not a definition of requirements, but rather the elaboration of a change that is already stated in the charter: “We are migrating our data to SAP.” The workshops clarify the implementation of this change, not the target business state of data quality or data processes. Thus, migration workshops are also part of change elaboration—and not part of requirements gathering.

3.4. Why Organizational Workshops Elaborate on Changes

At first glance, the organizational workshops—which focus on corporate structures, authorizations, and security concepts—appear to be strategic and technical in nature. However, they, too, do not define requirements, but rather the structural changes necessary to operate SAP in the first place. Defining company codes, plants, sales organizations, or role profiles is not a description of a target state, but rather a decision on how the company’s current state should be mapped in the system. These decisions change the organization—and are therefore changes. The workshops do not clarify what the company aims to achieve from a business perspective, but rather how it must change structurally in order to use SAP. Here, too, no product scope is defined; instead, the focus is on formulating the change decision: “We are implementing SAP.” The deliverables resulting from these structural changes only become apparent later—in the form of organizational models, role matrices, security concepts, and system configurations.

4.1. Why a Second Effort Estimate Is Absolutely Necessary

After the workshops, a realistic picture of the actual changes becomes available for the first time. Only now does the project know which process adjustments, enhancements, interfaces, data migrations, and organizational changesChanges to processes, roles, or structures are truly necessary. However, the original effort estimate is almost always based on the change decision from the charter—that is, on a rough idea such as “We are implementing SAP” or “We are harmonizing processes.” This estimate is inevitably inaccurate because it is not based on deliverables. A second effort estimate would therefore not only be sensible but methodologically essential: Only after the workshop phase does the information necessary to correctly determine the effort actually exist. Without this second estimate, the project plans based on an illusion—and hits a wall because the actual deliverables were never evaluated.

4.2. Why a Preliminary Project Would Be the Only Sound Solution

A preliminary project would do exactly what the SAP methodology skips: it would establish the framework. It would define the target business state, identify the deliverables, evaluate the changes, and prepare the Outcome Delivery Structure. A preliminary project would be the phase in which the “change illusion” is dispelled and the deliverables become visible. Only then could a project be properly planned. In practice, however, this step is almost always skipped. Instead of conducting a preliminary project, people jump straight into the workshops—and thus directly into the change elaboration phase. The project begins with the solution before the problem has been defined . A preliminary project would be the methodologically correct response to the “change illusion,” yet it is rarely carried out because it requires time, money, and clarity—three things that are often perceived as “delaying” factors in early project phases.

4.3. Why This Solution Is Systematically Rejected

The rejection of a second effort estimate or a preliminary project is no coincidence, but rather a structural pattern. Organizations want quick decisions, clear budgets, and fixed schedules—long before it is clear what actually needs to be built. A second estimate would reveal that the original planning was unrealistic. A preliminary project would show that the change decision does not align with the requirement. Both would shatter the illusion that the project is “under control.” That is why the methodologically correct solution is rejected: it would create transparency where, until now, only hope has existed. The illusion of change is comfortable because it gives the false impression of planning certainty. The reality of deliverables is uncomfortable because it reveals effort, risk, and complexity. That is precisely why the sound solution is systematically prevented.

4.4.  Why Projects Inevitably Fail Without This Solution

If the second effort estimate is missing and no preliminary project is conducted, the project plans based on the “change illusion.” Changes are sold as scope, even though scope exists only at the deliverable level. Effort is estimated at the change level, even though effort arises only from deliverables. Risks are underestimated because the deliverables are unknown. Dependencies are overlooked because the Outcome Delivery Structure has not been defined. And the cutover(i) Phase of the 5-phase model: Execution of the production transition; includes technical switchover and operational implementation. (ii) Selective transition of a project to the production environment. (iii) Production transition phase of an IT system, often under time pressure and requiring high coordination. becomes chaotic because POD → OD only works if deliverables exist. The project fails not because people are doing a poor job, but because the methodology never established the framework. Without the second estimate and without a preliminary project, the project remains in the dark—and inevitably goes off the rails because it never knew where the framework actually lay.

4.5. Why the solution only works if deliverables are first derived from the elaborated changes

For a second and time estimate to work at all, a step must be inserted between the change elaboration and the planning phase—a step that is almost always missing in SAP projects: the derivation of deliverables. Only when it is clear which deliverables will result from the identified changes can a project be realistically assessed. The workshops merely provide the change decisions—that is, the description of how the current state is to be changed. However, effort, risk, and complexity do not arise from the change decision itself, but rather from the deliverables that result from that decision. A gap in the “Fit-to-Standard” is not a scope element, but an indication that a deliverable must be created. An enhancement is not a driver of effort, but rather a bundle of deliverables such as specifications, development artifacts, test cases, documentation, and operational approvals. A data migration is not a task, but rather a multitude of deliverables such as mapping tables, cleansing rules, transformation scripts, test runs, and acceptance reports.

As long as these deliverables are not visible, the project remains in the dark. Change elaboration generates only the idea of change, not the work itself. Only the derivation of deliverables reveals what actually needs to be built, tested, documented, and transferred. Without this step, any effort estimate is inevitably incorrect because it is based on a governanceStructured management and decision-making logic for the cutover, including roles, rules, and communication channels. decision rather than on the deliverables that constitute the product scope. The second estimate can therefore only take place once the deliverables are clearly defined—and not before. It is not a “correction” of the first estimate, but rather the first realistic estimate of all, because it is based on the Outcome Delivery Structure and not on the “change illusion.”

This is precisely why a preliminary project would be so valuable: it would derive the deliverables from the changes before the actual project begins. But because this step requires time, money, and transparency, it is often rejected in practice. The organization wants budgets, schedules, and commitments early on, even though the deliverables aren’t even known yet. This perpetuates the “change illusion”: a project is planned whose scope has never been defined. The solution is therefore clear: first derive the deliverables from the elaborated changes, then estimate effort and time—and only then decide whether the project is even feasible in this form.

5.1. SAP Activate is an implementation methodology, not a scope methodology

SAP Activate was never designed to define business scope. Activate is an and acceleration methodology that assumes the scope is already clear—even though in reality it never is. The methodology presupposes that the organization knows what it wants to achieve and that the deliverables can already be implicitly derived from the SAP standard. But that is not true. Activate starts with the solution (SAP standard), not with the problem (requirement). That is why the step of deriving deliverables is missing: The methodology assumes that the scope is “embedded in the standard” and does not first need to be made visible. This is a methodological short-circuit that leads to scope illusions in practice.

5.2. SAP Activate is based on the assumption that the standard defines the scope

The core of Activate is “Fit-to-Standard.” This implicitly assumes that the SAP standard dictates the scope. If the standard dictates the scope, then theoretically there is no need for deliverable derivation—since the scope would already be defined. But in reality, the standard is only a starting point. Every deviation generates changes, and every change generates deliverables. Activate skips this step because the methodology assumes that the deviations are minor and that the deliverables “arise on their own.” This is an illusion. In real projects, hundreds of deliverables arise that are never named, never estimated, and never planned. Activate ignores this step because the methodology locates the scope in the standard—not in the project.

5.3. SAP Activate deliberately avoids anything that makes effort visible

Another reason is political: Deriving deliverables would immediately reveal just how large the project really is. It would show:

• how many enhancements need to be built
• how many test cases will be created
• how many data objects will be migrated
• how many roles need to be defined
• how many documents need to be created

In other words: It would reveal the true effort involved.

Activate avoids this step because it would shatter the illusion that SAP implementations are fast, lean, and “best practice.” The methodology is designed to make projects sellable—not plannable. Deriving deliverables would reveal the complexity and thus undermine the sales logic of the Activate methodology. That is why this step is systematically omitted.

5.4. SAP Activate Focuses on Change Elaboration Rather Than Deliverable Definition

The most important point is methodological: Activate is entirely focused on change elaboration.

“Fit-to-Standard” is change elaboration. RICEFW workshops are change elaboration. Data migration is change elaboration. Organizational structure is change elaboration.

Activate defines how the current state is changed—but never what the resulting outcome will be.

The methodology has no outcome delivery structure. It has no list of deliverables. It has no product scope. It deals only with changes.

That is why the step of deriving deliverables is missing: Activate is a methodology that exclusively elaborates on changes—and considers deliverables to be “implicitly present,” even though in reality they must first be made visible.

In short:

SAP Activate skips the derivation of deliverables because the methodology assumes that the scope is already defined in the standard system, that the changes define the work, and that the deliverables follow naturally. In reality, this is incorrect—and that is precisely why SAP projects go off the rails.