Projekt-Liefergegenstände: Definition, Arten und Beispiele

Bitten Sie fünf Personen aus einem Projektteam, „die Liefergegenstände" zu nennen, und Sie bekommen meist fünf verschiedene Antworten, manche davon Aufgaben, manche Ziele, eine vermutlich ein Meilenstein-Datum. Diese Verwirrung ist kein Vokabelproblem. Es ist ein Planungsproblem, denn ein Liefergegenstand ist die eine Einheit der Projektarbeit, die formal angenommen oder abgelehnt wird, und wenn sich das Team nicht einigen kann, was als einer zählt, kann sich auch niemand darauf einigen, was „fertig" bedeutet.

Key Facts

• PMIs eigene Leitlinie zum Scope Statement beschreibt Liefergegenstände als „wesentliche, zusammenfassende Positionen, deren vollständige und zufriedenstellende Lieferung den Abschluss des Projekts markiert", eine Definition, die PMI in seiner Leitlinie zum Projektumfang durchgängig verwendet.
• Der PMBOK Guide, Eighth Edition (PMI, November 2025) ist der aktuelle Standard und nennt Scope, die Domäne, die regelt, was ein Projekt liefern muss, als eine von sieben Performance-Domänen neben Governance, Zeitplan, Finanzen, Stakeholdern, Ressourcen und Risiko.
• PMIs Pulse-of-the-Profession-Studie (2014, Reihe „The High Cost of Low Performance") stellte fest, dass fast die Hälfte, nämlich 47 %, der gescheiterten Projekte ihre Ziele wegen ungenauen Anforderungsmanagements verfehlt, dieselbe Lücke, die später als Liefergegenstände auftaucht, bei denen sich niemand einigen kann, ob sie wirklich fertig waren.
• Der Scrum Guide definiert ein Increment, die agile Variante eines Liefergegenstands, als nutzbar, sobald es die Definition of Done des Teams erfüllt: „In dem Moment, in dem ein Product-Backlog-Eintrag die Definition of Done erfüllt, entsteht ein Increment."

Was ist ein Projekt-Liefergegenstand?

Ein Projekt-Liefergegenstand ist jedes eindeutige, überprüfbare Ergebnis, ein Produkt, ein Dokument, eine Leistung oder ein Resultat, das ein Projekt erzeugen und formal übergeben muss, bevor dieser Teil der Arbeit als abgeschlossen gilt. Ein Liefergegenstand ist kein Ziel und keine Aufgabe. Er ist ein Ding: etwas, das konkret genug ist, um darauf zu zeigen, es zu prüfen und es entweder anzunehmen oder zurückzugeben.

PMIs eigene Leitlinie zu Scope Statements formuliert Liefergegenstände genauso: „wesentliche, zusammenfassende Positionen, deren vollständige und zufriedenstellende Lieferung den Abschluss des Projekts markiert." Das ist für sich genommen ein nützlicher Test. Wenn Sie etwas nicht als Position beschreiben können, die geliefert und zufriedenstellend abgenommen wird, ist es wahrscheinlich kein Liefergegenstand, sondern eine Phase, eine Aktivität oder ein Ziel im Kostüm eines Liefergegenstands.

Liefergegenstände stehen im Zentrum dessen, wie ein Projekt tatsächlich geplant und gesteuert wird. Sie entstehen aus dem Projektumfangs-Statement, werden über den Projektstrukturplan in planbare Teile zerlegt und anhand von Akzeptanzkriterien abgenommen. Jedes andere Planungsartefakt eines Projekts, der Zeitplan, das Budget, die RACI, existiert, damit Liefergegenstände rechtzeitig erzeugt und abgenommen werden.

Liefergegenstand vs. Meilenstein vs. Ziel vs. Ergebnis vs. Aufgabe vs. Anforderung

Hier werden die meisten Projektseiten vage, und hier geraten die meisten Projekte tatsächlich in Schwierigkeiten. Sechs Begriffe werden im lockeren Gespräch fast austauschbar verwendet, und jeder beantwortet eine wirklich andere Frage. Hier ein Ein-Zeilen-Test für jeden.

Die Tabelle von links nach rechts gelesen zeichnet die tatsächliche Kette der Arbeit in den meisten Projekten nach: Ein geschäftliches Ziel rechtfertigt das Projekt, das Projekt erzeugt Liefergegenstände, jeder Liefergegenstand muss eine Reihe von Anforderungen erfüllen, seine Lieferung erfordert eine Reihe von Aufgaben, sein Abschluss wird durch einen Meilenstein markiert, und wenn das Projekt erfolgreich ist, zeigt sich das Ganze schließlich als Ergebnis, auf das das Unternehmen verweisen kann. Werden diese im Plan durcheinandergebracht, steht „Startseite bauen" (eine Aufgabe) neben „Conversion steigern" (einem Ziel) auf derselben Liste von Liefergegenständen, und niemand kann sagen, welches von beiden formal abgenommen wird.

Die Verwechslung von Liefergegenstand und Meilenstein ist in der Praxis die häufigste. Ein Meilensteinplan trägt Termine ab, nicht Arbeitsumfang, und ein Meilenstein markiert häufig, wann ein Liefergegenstand fertig oder genehmigt wurde. Aber der Meilenstein ist die Markierung, nicht das Ding selbst. „Startseite live" kann ein Meilenstein im Zeitplan sein und sich auf einen Liefergegenstand beziehen, der am selben Tag abgenommen wurde. Sie hängen zusammen, sind aber nicht dasselbe.

Arten von Projekt-Liefergegenständen

Sobald Sie bestätigt haben, dass etwas tatsächlich ein Liefergegenstand ist, hilft es trotzdem, ihn zu klassifizieren. Vier Achsen tauchen in fast jedem Projekt auf, und zu wissen, in welchem Quadranten ein Liefergegenstand liegt, sagt Ihnen, wer ihn prüft, wie formal er abgenommen wird und wie sichtbar er außerhalb des Delivery-Teams sein muss.

Interne vs. externe Liefergegenstände

Externe Liefergegenstände bergen mehr Risiko, wenn die Akzeptanzkriterien vage sind, weil Meinungsverschiedenheiten zu Vertragsstreitigkeiten statt zu internen Reibereien werden können. Das ist ein großer Teil des Grundes, warum ein Statement of Work externe Liefergegenstände meist ausdrücklich aufführt, mit angehängten Abnahmebedingungen, während interne Liefergegenstände oft mit einer Slack-Nachricht und einem Häkchen abgenommen werden können.

Prozess, Produkt, greifbar, nicht greifbar, Zwischen- und Endergebnis

Die meisten echten Liefergegenstände liegen am Schnittpunkt mehrerer Achsen. Ein UAT-Testbericht ist ein Prozess-Liefergegenstand, greifbar und meist ein Zwischenergebnis. Eine ausgelieferte Mobile-App ist ein Produkt-Liefergegenstand, greifbar und final. Die Art vorab zu benennen hilft Ihnen, schon vor Arbeitsbeginn zu entscheiden, wer sie prüft und wie streng diese Prüfung sein muss.

Vom Scope zum abgenommenen Liefergegenstand: Wie Liefergegenstände abgeleitet werden

Liefergegenstände werden nicht mitten im Projekt erfunden. Sie werden über eine bestimmte Kette abgeleitet, und das Überspringen eines Glieds dieser Kette ist die Quelle der meisten „Moment, wer hat dem zugestimmt?"-Gespräche.

Das Projektumfangs-Statement ist der Ort, an dem jeder Liefergegenstand erstmals benannt wird, als Substantivgruppe (ein Ding), nie als Tätigkeit (ein Verb). Der Projektstrukturplan nimmt diese benannten Liefergegenstände dann und zerlegt sie, bis jedes Arbeitspaket klein genug ist, dass ein Verantwortlicher es mit Zuversicht schätzen und abschließen kann. In Projekten, in denen der volle Umfang nicht vorab bekannt ist, nutzen Teams Rolling Wave Planning, um Liefergegenstände im Nahbereich vollständig auszuarbeiten und spätere bewusst grob zu lassen und sie erst zu verfeinern, wenn ihre Welle näher rückt. Wenn ein Arbeitspaket fertig ist, sollte es sauber auf einen benannten Liefergegenstand im ursprünglichen Scope Statement zurückführbar sein. Ist das nicht der Fall, handelt es sich meist entweder um Umfangsausweitung oder um einen Liefergegenstand, für den niemand geplant hat.

Beispiele für Projekt-Liefergegenstände nach Branche

Die Namen von Liefergegenständen ändern sich je nach Branche vollständig, aber die zugrunde liegende Form, ein konkretes, abnehmbares Ding, bleibt gleich. So sehen echte Liefergegenstände in sechs gängigen Bereichen aus.

Beachten Sie das Muster in der Spalte der Genehmiger. Es ist immer eine bestimmte Person genannt, nie „das Team" oder „Stakeholder". Ein Liefergegenstand ohne benannten Genehmiger wird nicht wirklich als Liefergegenstand gesteuert, er ist nur Arbeit, die auf einer Liste liegt und darauf wartet, dass irgendwann jemand bemerkt, dass sie fertig ist. Genau diese Verantwortlichen festzulegen, dafür ist eine RACI gebaut: Jeder Liefergegenstand braucht genau eine Person, die dafür verantwortlich ist, ihn abnehmen zu lassen, auch wenn mehrere Personen zu seiner Erzeugung beitragen.

Wie ein Liefergegenstand tatsächlich abgenommen wird

Hier scheitern die meisten Projekte tatsächlich, nicht beim Bauen, sondern bei der Übergabe. Ein Liefergegenstand, der nach dem eigenen Urteil des Teams „fertig" ist, und ein Liefergegenstand, der von demjenigen „abgenommen" ist, dem die Entscheidung gehört, sind zwei verschiedene Ereignisse, und sie gleichzusetzen ist der Weg zu Streitigkeiten.

Definition of Done vs. formale Akzeptanzkriterien

Eine Definition of Done ist die eigene Qualitätslatte des Teams: Code geprüft, getestet, dokumentiert, was auch immer das Team immer verlangt, bevor es etwas als fertig bezeichnet. Akzeptanzkriterien gelten für einen Liefergegenstand und gehören der Person, die die Befugnis hat, Ja zu sagen. Ein Liefergegenstand kann die Definition of Done des Teams vollständig erfüllen und trotzdem die formale Abnahme verfehlen, weil der Genehmiger gegen eine andere, liefergegenstandsspezifische Latte prüft. Beide Tore müssen passiert werden. Keines ersetzt das andere.

Wer tatsächlich freigibt

Abnahme ist keine Stimmung, sondern eine Entscheidung einer bestimmten Person mit der Befugnis, sie zu treffen. Bei internen Liefergegenständen ist das oft ein Manager oder ein Peer-Reviewer. Bei externen, kundenseitigen Liefergegenständen wird sie meist im Statement of Work selbst benannt, zusammen damit, was geschieht, wenn der Liefergegenstand abgelehnt wird: ein definiertes Nacharbeitsfenster, ein Termin für die erneute Prüfung, manchmal ein an die Unterschrift gebundener Zahlungsmeilenstein. Projekte, die darauf verzichten, vorab einen Genehmiger zu benennen, stellen tendenziell im denkbar ungünstigsten Moment fest, dass drei verschiedene Personen glauben, die mit der Freigabebefugnis zu sein, und keine sich einig ist.

Liefergegenstände dokumentieren: das Deliverable-Register

Ein Deliverable-Register (manchmal Deliverable-Tracker oder -Log genannt) ist die einzige Quelle der Wahrheit für jeden Liefergegenstand eines Projekts: was er ist, wer ihn verantwortet, wann er fällig ist, was „abgenommen" bedeutet und wo er gerade steht. Ohne eines lebt der Status von Liefergegenständen in verstreuten E-Mails und bei dem, der daran denkt zu fragen.

Halten Sie das Register im selben Takt aktuell wie Ihren Projektstatusbericht, damit der Status der Liefergegenstände nie veraltet ist, wenn Stakeholder danach fragen. Wenn Akzeptanzkriterien im Register statt im Posteingang einer Person stehen, wird eine strittige Übergabe zu einer Zwei-Minuten-Recherche statt zu einem Gedächtniswettbewerb. Gleichen Sie bei Liefergegenständen, die an bestimmte Produkt- oder Vertragsanforderungen gebunden sind, das Register mit einer Anforderungs-Rückverfolgbarkeitsmatrix ab, damit sich jede Anforderung auf den Liefergegenstand zurückführen lässt, der sie erfüllen soll, und jeder Liefergegenstand auf die Anforderung, die seine Erstellung rechtfertigte.

Häufige Probleme mit Liefergegenständen

Die meisten Streitigkeiten um Liefergegenstände lassen sich auf eine kleine Zahl wiederkehrender Verursacher zurückführen. Sie zu benennen macht sie leichter erkennbar, bevor sie jemanden eine Woche Nacharbeit kosten.

Umfangsausweitung verdient hier eine eigene Hervorhebung, weil sie selten als offensichtlich neuer Liefergegenstand ankommt. Sie kommt fast immer getarnt als kleine Ergänzung zu einem bestehenden: ein „kurzes zusätzliches Feld" im Formular, eine weitere Folie im Deck, eine Seite, die ursprünglich niemand eingeplant hatte. Jede dieser Ergänzungen verändert, was der Liefergegenstand tatsächlich ist, und damit auch, was „abgenommen" bedeuten sollte.

Liefergegenstände in Agile: Increments und Definition of Done

Agile Teams verwenden das Wort „Liefergegenstand" im Alltag meist nicht, doch das Konzept verschwindet nicht, es wird umbenannt und häufiger geliefert. In Scrum ist die entsprechende Einheit das Increment: ein Stück Produkt, das nutzbar und potenziell auslieferbar ist, sobald es die Definition of Done des Teams erfüllt.

Der Scrum Guide stellt klar, dass diese Latte nicht optional ist: „Arbeit kann nur dann Teil eines Increments sein, wenn sie die Definition of Done erfüllt", und sobald sie das tut, entsteht „in dem Moment, in dem ein Product-Backlog-Eintrag die Definition of Done erfüllt, ein Increment". Das ist eine strengere, kontinuierlichere Version derselben Übergabelogik, die einen traditionellen Liefergegenstand regelt. Der Unterschied liegt nicht darin, ob eine Abnahme stattfindet, sondern wie oft und wer prüft. Ein prädiktives Projekt nimmt womöglich fünf Liefergegenstände über ein Jahr formal ab. Ein Scrum-Team stellt dieselbe Abnahmefrage in jedem Sprint, manchmal jeden Tag, nur jedes Mal in viel kleinerem Maßstab.

Best Practices

• Benennen Sie Liefergegenstände als Dinge, nie als Tätigkeiten. Beginnt der Name mit einem Verb, gehört er in den Projektstrukturplan oder die Aufgabenliste, nicht in die Liste der Liefergegenstände.
• Schreiben Sie Akzeptanzkriterien vor Arbeitsbeginn, nicht danach. Nachträglich geschriebene Kriterien beschreiben, was gebaut wurde, nicht, was tatsächlich gebraucht wurde.
• Weisen Sie jedem Liefergegenstand genau einen Verantwortlichen zu. Geteilte Verantwortung ist der Weg, auf dem Liefergegenstände still ins Stocken geraten, ohne dass sich jemand persönlich zuständig fühlt.
• Trennen Sie „fertig" und „abgenommen" ausdrücklich. Die eigene Qualitätslatte des Teams und die formale Freigabe eines Stakeholders sind zwei verschiedene Prüfungen, und beide müssen bestanden werden.
• Führen Sie ein lebendiges Deliverable-Register statt eines Gedächtnisses. Status, Verantwortlicher, Fälligkeitsdatum und Akzeptanzkriterien sollten an einem Ort stehen, den alle einsehen können.
• Behandeln Sie jede „kleine Ergänzung" als Scope-Frage. Der schnellste Weg, auf dem Umfangsausweitung in ein Projekt gelangt, sind Änderungen an einem bestehenden Liefergegenstand, die nie durch die Änderungssteuerung laufen.
• Stimmen Sie die Formalität der Abnahme auf die Art des Liefergegenstands ab. Ein kundenseitiger End-Liefergegenstand verdient eine strengere Prüfung als ein interner Zwischenentwurf; sparen Sie sich den aufwendigsten Prozess für die Stellen, an denen das Risiko wirklich liegt.
• Führen Sie Liefergegenstände auf Anforderungen zurück, nicht nur vorwärts auf Aufgaben. Eine Anforderungs-Rückverfolgbarkeitsmatrix fängt die Liefergegenstände ab, die ohne dokumentierten Grund existieren, und die Anforderungen, für die nie ein Liefergegenstand gebaut wurde.

Ein Liefergegenstand ist das eine Wort in einem Projektplan, das nie mehrdeutig sein sollte, denn er ist das, was zu erzeugen alle letztlich bezahlt werden, und das, wovon ein anderer zustimmen muss, dass es wirklich fertig ist. Benennen Sie Liefergegenstände als Dinge, schreiben Sie ihre Akzeptanzkriterien, bevor jemand zu bauen beginnt, und geben Sie jedem genau einen Verantwortlichen und einen Genehmiger. Wenn Sie das richtig machen, hören die meisten „Moment, ist das wirklich fertig?"-Gespräche, die die letzten Wochen eines Projekts auffressen, schlicht auf.