Project managementResponsible for the overall coordination, planning, and strategic management of the project. literature spends a great deal of time discussing requirementsRequirements that may lead to changes, changes, work packages, and results. Yet one crucial distinction is missing almost everywhere: the clear separation between requirements, changes, deliverables, and the product scope. Only when these concepts are cleanly separated does it become visible how projects actually function — and why governanceStructured management and decision-making logic for the cutover, including roles, rules, and communication channels. models often struggle in practice.

To make this distinction tangible, let’s use a simple example: a sardine factory.

Imagine a small factory with eight employees and one machine producing five cans of sardines per minute. This is the AS‑ISRepresentation of the current state state. The owner now has a goal: production should increase to ten cans per minute. This goal describes the TO‑BEDepiction of the desired target state state — and that is a requirement. A requirement defines how the world should look in the future, without specifying how to get there.

The question of how the TO‑BE state will be achieved leads to the changeAny planned or approved change to a system, process, or organizational unit—whether technical, organizational, or procedural. decision. A change is not a work unit and not a result object. It is a governance decision that determines how the AS‑IS state will be altered to reach the TO‑BE state. In the sardine factory, the change consists of three elements: the factory hall will be expanded, a second machine will be purchased, and eight additional employees will be hired. These three measures together form the change — the decision on how to move from five to ten cans per minute.

But implementing this change produces a large number of deliverables. And this is where the distinction often becomes blurry in real projects. A deliverableA tangible, versioned document or artifact (e.g., cutover plan) that is ready for acceptance and formally approved. is a result object — an artifact, a document, a physical object, or an approval‑ready output created through the implementation of a change. Deliverables are not the decision itself; they are the concrete results that emerge from that decision.

Expanding the factory hall produces building plans, permit applications, tender documents, contracts, safety concepts, and ultimately the new hall itself. Purchasing the second machine produces needs analyses, supplier comparisons, purchase orders, contracts, installation plans, test protocols, and the machine as a physical result. Hiring new employees produces job descriptions, advertisements, candidate lists, employment contracts, training materials, and onboarding plans.

This makes one thing clear: one change produces many deliverables. The relationship is not 1:1 but 1:n. A change is the trigger; deliverables are the results. A change alters the state; deliverables document or implement that alteration.

And this is where the product scope enters the picture. The product scope does not include requirements and does not include changes. It includes only the deliverables created through the implementation of changes. The product scope describes what actually exists at the end — the new hall, the second machine, the trained employees, the operational approvals, the test protocols, and all other result objects that enable the new production state.

At this point, another structural peculiarity becomes visible — one that appears in almost every large transformation initiative, especially in SAP programs. The change decision is often made very early. A board decides to introduce SAP, harmonize processes, or implement certain modules. This decision is a change, because it fundamentally alters the AS‑IS state. But the concrete deliverables that will emerge from this decision are still completely unknown at that moment. They are elaborated only later, inside the Outcome Delivery Structure (ODS) — whether a project, a program, or a portfolio.

The ODS is the structure in which deliverables are created. This is why a project charter contains the change decisions but not the deliverables. Deliverables emerge only when teams begin to operationalize the change decision. Requirements often remain invisible to many project members because they are rarely documented cleanly and even more rarely communicated clearly. The change decision, however, is visible because it appears in the charter. The deliverables become visible only later, because they arise through the work performed within the ODS.

This creates a clear and complete chain: requirements define the TO‑BE state. Changes define the decision on how that state will be reached. Deliverables are the concrete result objects of that decision. And the product scope consists exclusively of those result objects. Only the combination of these four layers enables the transition from AS‑IS to TO‑BE — and only the deliverables form the actual product scope.

The sardine factory shows in a simple way what is equally true in complex projects: changes are governance. Deliverables are output. The product scope consists of deliverables. And only when these layers are clearly separated does project management truly work.

Many projects fail because changes are decided without clear requirements, and effort is estimated at the change level instead of the deliverable level. Changes are governance. Deliverables are work. Only deliverables generate effort, risk, and product scope.

In many projects, a peculiar illusion emerges — one that becomes visible only when the terminology is cleanly separated: the Change Illusion. It arises when a change decision is sold as scope, even though it is merely a governance decision. The organization decides, for example, “We will build a new factory.” This sentence sounds like scope, feels like scope, and is presented as scope in the steering committeeStrategic decision-making body for critical escalations (Level 3).. But in reality, it is only a change — a decision about how the AS‑IS state will be altered. The scope emerges later, when the deliverables are defined.

The sardine factory makes this especially clear. First, the decision is made to “build a new factory.” That is the change decision. But as soon as the project begins, this decision is progressively elaborated: the factory becomes a new hall, then a second machine, then more staff, then new processes, then safety concepts, and finally an entire bundle of result objects. This progressive detailing is not scope elaboration — it is change elaboration, the expansion of the change decision that later leads to real deliverables.

PMI speaks of “progressive elaboration,” usually referring to scope. But in practice, something else is elaborated: not the scope, but the change. The change decision is made early and documented in the charter. It is sold as scope, even though scope only emerges at the deliverable level. The deliverables themselves are still completely unknown at that point. They emerge later, within the Outcome Delivery Structure — whether a project, a program, or a portfolio.

This peculiarity leads to a systemic problem: effort is estimated at the change level, even though effort exists only at the deliverable level. Organizations estimate “expanding the hall,” not the building plans, permits, tenders, contracts, safety concepts, and approvals. They estimate “a second machine,” not the needs analysis, supplier comparison, purchase order, installation, testing, and operational readiness. They estimate “more staff,” not the job descriptions, advertisements, interviews, contracts, training, and onboarding plans.

This creates the Change Illusion: the belief that the change is the scope. But the scope emerges only later, when the deliverables are defined. And this is precisely where many projects fail. Changes do not match requirements because requirements often remain invisible.