Every company must adapt to market changes and transform its business. How? Through projects, programs, and complex transformation initiatives. For decades, we’ve been talking about portfolio, program, project, and, more recently, epic. But one thing has been missing until now: a common umbrella term that logically groups these levels and describes how organizations structure their work to deliver an outcome.

This is accurately where a new term comes in:

Outcome Delivery Structure (ODS): The totality of all structural levels that serve to realize an outcome.

ODS is a modern, framework-neutral approach that doesn’t replace the familiar levels but organizes them more clearly.

ODS thus covers:

• classic project structures (PMI, PRINCE2)
• agile structures (Scrum, SAFe)
• hybrid models (SAP ActivateOfficial SAP methodology for implementing SAP S/4HANA, consisting of six phases (from Discover to Run) and focusing on standardization, agility, and compliance.)
• service-oriented models (ITILFramework for IT Service Management with defined processes.)

1. Classic hierarchical structures

Classic hierarchical structures include:

• Portfolio, Level 1 – strategic collection of all initiatives
• Program, Level 2 – coordinated group of related projects
• Epic, Level 3 – large work unit broken down into projects
• Project, Level 4 – clearly defined deliverableA tangible, versioned document or artifact (e.g., cutover plan) that is ready for acceptance and formally approved. with a start and end date
• Task, Level 5 – smallest operational unit

2. The Agile Hierarchy (SAFe & Scrum)

In a scaled agile environment (SAFe), the terms fit directly into the existing structure:

• Epic (Portfolio/Solution/Program Level): sits at the very top. It describes a large, strategic initiative (e.g., “Develop a new customer portal”).
• FeatureA single functionality within a product or service. (Program Level): An epic is broken down into features (e.g., “Login system” or “Invoice overview”).
• User Story (Team Level): Features are broken down into user stories for implementation (e.g., “As a customer, I want to be able to log in with my email address”).
• Sprint (Time Frame): A sprint is not a hierarchical work unit, but rather a time-based container (usually 2–4 weeks). Within this container, the team works through a selection of user stories.

Visualization of the SAFe hierarchy with time units:

1. Portfolio / Solution (Strategy)
2.      ↳ Epic (months to quarters)
3.           ↳ Feature (Fits into a PI / Program Increment, approx. 8–12 weeks)
4.                ↳ User Story (Fits into a Sprint, a few days)

3. Classification in SAP Activate

SAP Activate links agile concepts with traditional project phases:

• Epic: Corresponds to a major deliverable within a workstream (e.g., in the Application Design & Configuration workstream).
• User Story: In the SAP context, this is often recorded in the backlog during the Explore phaseA time- and content-defined section of a process model focused on specific goals, activities, and results.. It refines the requirementsRequirements that may lead to changes and, at the lowest level, corresponds to the tasks that are implemented in the sprint.
• Sprint: Takes place primarily in the Realize phase. Here, the user stories prioritized in the backlog are configured and tested in iterative cycles (sprints).

4. Classification in PMI & ITIL

• PMI (Classic & Hybrid): An Epic corresponds to a broad phase or a large work package in the project structure plan (PSP/WBS). The User Story is the specific, detailed activity. The Sprint replaces the classic, rigid schedule sequence with short, iterative segments.
• ITIL (Value Streams): An epic and its user stories are the specific requirements that flow through a value stream. The implementation of user stories within a sprint is part of the Design & Transition or Obtain/Build activities, ultimately delivering value to the customer.

5. The Conceptual Gap in All Frameworks

We have perfect terms for structural levels (portfolio, program, epic, feature, project, user story, task), but not a single good term for the state of the deliverable as long as it is not yet in production within the ODS.

I have already clearly defined deliverables and outcome types in my book on SAP 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. Management.

Definition: Deliverable

A deliverable is a tangible document or artifact (e.g., the complete cutover planA structured plan for executing the cutover, including a timeline, role logic, communication matrix, and fallback strategy. The cutover timeline is part of the cutover plan.) that is ready for acceptance, versioned, and formally approved.

Definition: Outcome

An outcome type is a milestoneA point in the project at which a defined level of progress must be achieved; used for time and progress tracking. or a partial result (e.g., stakeholder workshop, clarification of roles) that is generated, documented, and placed within the overall context as part of a deliverable.

Example: The definition of responsibilities is an “outcome type”—it is incorporated into the deliverable “Roles and Responsibilities Matrix.”

However, there are two types of deliverables in a project. Some relate to the Project Scope and others to the Product Scope, to use PMI terminology. Only the deliverables that relate to the Product Scope are generally transferable to production—that is, relevant to the cutover. One could be pedantic here and argue that some deliverables from the project scope might indeed be transferred, such as Lessons LearnedReflection format for documenting insights from tests, workshops, or real-world cases – classified as a result type..

Example: The System Integration TestTesting the interaction of multiple components. (SIT) and User Acceptance Test (UAT) are deliverables within the Project Scope. Even though they are acceptance criteria for the cutover, they are not transferred. System configurations, new process flows, trained staff, and documents ready for production use are transferable deliverables.

And here is the missing term: Pre-Operational Deliverable (POD)

Definition: Pre-Operational Deliverable (POD) versus Operational Deliverable (OD)

A transferable deliverable is a Pre-Operational Deliverable (POD) as long as it is not yet in production. During the cutover, a POD is transferred to an OD, or Operational Deliverable.

6. Summary

The cutover transforms Pre-Operational Deliverables (PODs) into Operational Deliverables (ODs). This operational transformation always refers to the selected Outcome Delivery Structure (ODS). It therefore makes sense to speak of a project-specific, program-specific, or portfolio-specific cutover, depending on which ODS we are referring to.