Jedes Unternehmen muss sich an Marktveränderungen anpassen und sein Geschäft umgestalten. Wie? Durch Projekte, Programme und komplexe Transformationsinitiativen. Seit Jahrzehnten sprechen wir von Portfolio, Programm, Projekt und in jüngerer Zeit auch von „Epic“. Doch eines hat bisher gefehlt: ein gemeinsamer Oberbegriff, der diese Ebenen logisch zusammenfasst und beschreibt, wie Organisationen ihre Arbeit strukturieren, um ein Ergebnis zu erzielen.

Genau hier kommt ein neuer Begriff ins Spiel:

Outcome Delivery Structure (ODS): Die Gesamtheit aller strukturellen Ebenen, die der Realisierung eines Ergebnisses dienen.

ODS ist ein moderner, framework-neutraler Ansatz, der die bekannten Ebenen nicht ersetzt, sondern sie übersichtlicher ordnet.

ODS umfasst somit:

• klassische Projektstrukturen (PMI, PRINCE2)
• agile Strukturen (Scrum, SAFe)
• Hybridmodelle (SAP ActivateOffizielle SAP-Methodik zur Einführung von SAP S/4HANA mit sechs Phasen (Discover bis Run) und Fokus auf Standardisierung, Agilität und Compliance.)
• serviceorientierte Modelle (ITILFramework für IT-Service-Management mit definierten Prozessen.)

1. Klassische hierarchische Strukturen

Zu den klassischen hierarchischen Strukturen gehören:

• Portfolio, Ebene 1 – strategische Zusammenfassung aller Initiativen
• Programm, Ebene 2 – koordinierte Gruppe verwandter Projekte
• Epic, Ebene 3 – große Arbeitseinheit, die in Projekte unterteilt ist
• Projekt, Ebene 4 – klar definiertes Ergebnis mit Start- und Enddatum
• Aufgabe, Ebene 5 – kleinste operative Einheit

2. Die agile Hierarchie (SAFe & Scrum)

In einer skalierten agilen Umgebung (SAFe) fügen sich die Begriffe direkt in die bestehende Struktur ein:

• Epic (Portfolio-/Lösungs-/Programmebene): Befindet sich ganz oben. Es beschreibt eine große, strategische Initiative (z. B. „Entwicklung eines neuen Kundenportals“).
• FeatureEinzelne Funktionalität innerhalb eines Produkts oder Services. (Programmebene): Ein Epic wird in Features unterteilt (z. B. „Anmeldesystem“ oder „Rechnungsübersicht“).
• User Story (Teamebene): Features werden zur Umsetzung in User Stories unterteilt (z. B. „Als Kunde möchte ich mich mit meiner E-Mail-Adresse anmelden können“).
• Sprint (Zeitrahmen): Ein Sprint ist keine hierarchische Arbeitseinheit, sondern ein zeitbasierter Zeitrahmen (in der Regel 2–4 Wochen). Innerhalb dieses Zeitrahmens bearbeitet das Team eine Auswahl an User Stories.

Visualisierung der SAFe-Hierarchie mit Zeiteinheiten:

1. Portfolio / Lösung (Strategie)
2.      ↳ Epic (Monate bis Quartale)
3.           ↳ Feature (passt in ein PI / Program Increment, ca. 8–12 Wochen)
4.                ↳ User Story (passt in einen Sprint, einige Tage)

3. Klassifizierung in SAP Activate

SAP Activate verbindet agile Konzepte mit traditionellen Projektphasen:

• Epic: Entspricht einem wesentlichen Ergebnis innerhalb eines Arbeitsstroms (z. B. im Arbeitsstrom „Anwendungsdesign und -konfiguration“).
• User Story: Im SAP-Kontext wird diese häufig während der Explore-Phase im Backlog erfasst. Sie konkretisiert die Anforderungen und entspricht auf der untersten Ebene den Aufgaben, die im Sprint umgesetzt werden.
• Sprint: Findet hauptsächlich in der „Realize“-Phase statt. Hier werden die im Backlog priorisierten User Stories in iterativen Zyklen (Sprints) umgesetzt und getestet.

4. Klassifizierung nach PMI und ITIL

• PMI (Classic & Hybrid): Ein „Epic“ entspricht einer übergreifenden PhaseZeitlich und inhaltlich abgegrenzter Abschnitt eines Vorgehensmodells zur Fokussierung auf bestimmte Ziele, Aktivitäten und Ergebnisse. oder einem großen Arbeitspaket im Projektstrukturplan (PSP/WBS). Die „User Story“ ist die spezifische, detaillierte Aktivität. Der „Sprint“ ersetzt die klassische, starre Zeitplanabfolge durch kurze, iterative Abschnitte.
• ITIL (Wertströme): Ein Epic und seine User Stories sind die spezifischen Anforderungen, die durch einen Wertstrom fließen. Die Umsetzung von User Stories innerhalb eines Sprints ist Teil der Aktivitäten „Design & Transition“ oder „Obtain/Build“ und liefert letztendlich einen Mehrwert für den Kunden.

5. Die konzeptionelle Lücke in allen Rahmenwerken

Wir verfügen über perfekte Begriffe für Strukturebenen (Portfolio, Programm, Epic, Feature, Projekt, User Story, Aufgabe), aber keinen einzigen guten Begriff für den Status des Liefergegenstands, solange dieser noch nicht im ODS in Produktion ist.

Ich habe in meinem Buch über SAP-Cutover-Management bereits klar definiert, was unter „Deliverables“ und „Ergebnisarten“ zu verstehen ist.

Definition: LiefergegenstandGreifbares, versioniertes Dokument oder Artefakt (z. B. Cutover-Plan), das abnahmefähig und formell freigegeben wird.
Ein Liefergegenstand ist ein greifbares Dokument oder Artefakt (z. B. der vollständige Cutover-Plan), das abnahmefähig, versioniert und formell freigegeben wird.

Definition: ErgebnistypMeilenstein oder Teilergebnis (z. B. Rollenklärung), das im Rahmen eines Liefergegenstands erzeugt und dokumentiert wird.
Ein Ergebnistyp (Outcome) ist ein MeilensteinZeitpunkt im Projekt, zu dem ein definierter Fortschritt erreicht sein muss; dient der Zeit- und Fortschrittskontrolle. oder ein Teilergebnis (z.B. Stakeholder-Workshop, Rollenklärung), das im Rahmen eines Liefergegenstands erzeugt, protokolliert und in den Gesamtkontext eingeordnet wird.

Beispiel: Die Definition der Zuständigkeiten ist ein „Ergebnistyp“ – sie wird in den Liefergegensatnd „Rollen- und Zuständigkeitsmatrix“ integriert.

Es gibt jedoch zwei Arten von Ergebnissen in einem Projekt. Einige beziehen sich auf den Projektumfang (Project Scope), andere auf den Produktumfang (Product Scope), um die Terminologie des PMI zu verwenden. Nur die Ergebnisse, die sich auf den Produktumfang beziehen, sind in der Regel in die Produktion übertragbar – das heißt, sie sind für die Umstellung relevant. Man könnte hier pedantisch sein und argumentieren, dass einige Ergebnisse aus dem Projektumfang tatsächlich übertragen werden könnten, wie beispielsweise gewonnene Erkenntnisse.

Beispiel: Der Systemintegrationstest (SIT) und der Benutzerabnahmetest (UAT) sind Liefergegenstände innerhalb des Projektumfangs. Auch wenn sie Abnahmekriterien für den Cutover(i) Phase des 5-Phasen-Modells: Durchführung des produktiven Übergangs; umfasst technische Umschaltung und operative Umsetzung. (ii) Punktueller Übergang eines Projekts in die produktive Umgebung. (iii) Produktive Umstellungsphase eines IT-Systems, oft unter Zeitdruck und hoher Koordinationsdichte. darstellen, werden sie nicht überführt. Systemkonfigurationen, neue Prozessabläufe, geschultes Personal und für den produktiven Einsatz bereite Dokumente sind überführbare Ergebnisse.

Und hier ist der fehlende Begriff:Pre‑Operational Deliverable (POD)

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

Ein überführbares Deliverable ist ein Pre‑Operational Deliverable (POD), solange es noch nicht produktiv ist. Während des Cutovers wird ein POD in ein OD, Operational Deliverable, überführt

6. Zusammenfassung

Der Cutover überführt Pre‑Operational Deliverable (POD) in Operational Deliverables (OD). Diese operative Überführung bezieht sich immer auf die gewählte Outcome Delivery Structure (ODS). Es macht deshalb Sinn von einem Project-spezifischem, Program-spezifischem oder Portfolio-spezifischem Cutover zur sprechen, je nachdem, auf welche ODS wir uns beziehen.