Liefergegenstand

Für den PMBOK(R) Guide besitzt der Begriff "deliverable" einen zentralen Stellenwert. Er bezeichnet ein "eindeutiges und überprüfbares Produkt oder Ergebnis oder eine Dienstleistung, das/die hergestellt bzw. erbracht werden muss, um einen Prozess, eine Phase oder ein Projekt abschließen zu können."

Die erste deutsche Übersetzung des PMBOK(R) Guide 2000 prägte das neue Wort "Liefergegenstand" als möglichst wörtliche Entsprechung von "deliverable".

Dieser Begriff setzte sich im Sprachgebrauch durch, so dass auch die DIN 69901-5 im Jahr 2009 "Liefergegenstand" als offiziellen Begriff aufnahm. Im Gegensatz zum PMBOK Guide beschränkt die DIN 69901-5 die Bedeutung von "Liefergegenstand" jedoch ein auf ein "Ergebnis, das am Ende eines Vorgangs, Arbeitspakets oder Projekts zu erbringen bzw. abzuliefern ist."

PRINCE2 wählt in Abgrenzung vom PMBOK Guide bewusst den Begriff "Produkt" für alle Projektergebnisse, da die Konzentration auf Produkte eines der sieben Prinzipien von PRINCE2 ist.

Betriebswirtschaftlich gesehen sind Liefergegenstände zu erbringende Leistungen, rechtlich gesehen entspricht "Deliverable" dem Begriff "Werk" gemäß der Paragraphen 631-651 BGB.

Ein Liefergegenstand muss durch Qualitätskriterien beschrieben werden, nach denen er überprüft und abgenommen werden kann.

Erläuterung und Kommentar

Grundsätzlich können die Begriffe "Liefergegenstand", "(Projekt-)Produkt", "Leistung" und "Werk" deshalb synonym verwendet werden. Allerdings gibt es unterschiedliche Interpretationen von "externen" Liefergegenständen und Produkten des Projekts.

Der PMBOK(R) Guide weist explizit auf die häufige Unterscheidung zwischen den "external deliverables", die vertraglichen Vereinbarungen entsprechen, und den für jedes Arbeitspaket erforderlichen Einzelergebnissen. PRINCE2 hingegen unterscheidet interne und externe Produkte nach dem Kriterium, ob sie innerhalb des Projekts erstellt werden oder ob sie dem Projekt von außen ohne zusätzlichen Aufwand zur Verfügung stehen. Während das Ergebnis eines Arbeitspakets bei PRINCE2 deshalb immer in internes Projektprodukt ist, kann es gemäß PMBOK Guide ein externer Liefergegenstand sein.

Gemeinsam ist allen Standards und Richtlinien, dass sie den Projektumfang (Scope) über die Menge aller Liefergegenstände bzw. Projektprodukte definieren.

Eine Bewertung dieser begrifflichen Feinheiten und Interpretationen fällt schwer. Einerseits präzisiert ein eigenständiger Begriff für die Werke bzw. Leistungen eines Projekts den Sprachgebrauch, andererseits geben die verschiedenen Begriffe Anlass zu Missverständnissen. Da es sich um einen der zentralen Begriffe für jedes Projekt handelt, sollten die Projektbeteiligten sich vor Beginn des Projekts auf eine gemeinsame Sprachregelung einigen und sie z.B. im Glossar des Projekthandbuchs festlegen.

Relevante Beiträge im Projekt Magazin
von Markus Schmidt
2 Bewertungen
3
0 Kommentare
Bezieht eine Firma neue Räume, soll der Umzug möglichst reibungslos und ohne Unterbrechung des laufenden Geschäftsbetriebs erfolgen. Dabei sorgt oft der Transfer der IT-Infrastruktur für Kopfschmerzen bei den Verantwortlichen. Denn mit dem Ausfall des Telefon- oder Rechnernetzes würde der gesamte Betrieb zum Erliegen kommen. Damit so etwas nicht passiert, haben Markus Schmidt und Dominik Dopheide eine speziell auf den Umzug der IT-Infrastruktur abgestimmte Checkliste entwickelt, die Sie zusammen mit dem Artikel herunterladen können. Die Liste hilft dabei, potenzielle Probleme frühzeitig zu erkennen und beim Umzug nichts Wichtiges zu vergessen.
von Tim Krüger
20 Bewertungen
3.75
0 Kommentare
Ein großer Mobilfunkanbieter stand 2007 vor dem Problem, dass die Fachabteilungen immer mehr Anforderungen an die Neu- und Weiterentwicklung der internen IT-Systeme stellten. Arbeitskapazität und Budget der IT-Abteilung reichten aber nicht aus, um diese umzusetzen. Es wurde deshalb ein Verfahren entwickelt, mit dem sich Projektinhalt und –umfang reduzieren und an die Ressourcensituation anpassen lassen. Dabei werden die besonders nützlichen Funktionsanforderungen herausgefiltert und umgesetzt, Anforderungen mit einem niedrigeren Nutzen fallen weg. Das Verfahren basiert auf dem Pareto-Prinzip und wird im Unternehmen deshalb als Pareto-Analyse bezeichnet. Tim Krüger stellt Ablauf und Nutzen der Pareto-Analyse vor.
von Josef Schwab
3 Bewertungen
4.333335
1 Kommentar
Um Abhängigkeiten zwischen einzelnen Projekten darzustellen, stehen in Microsoft Project die projektübergreifenden Anordnungsbeziehungen zur Verfügung (siehe Teil 2). Terminänderungen im Quellprojekt wirken sich dabei automatisch auf die nachfolgenden Termine im Zielprojekt aus – was nicht immer erwünscht ist. Praktischer wäre es, Termine aus anderen Projekten darstellen zu können, ohne befürchten zu müssen, dass diese die Vorgänge im eigenen Projekt beeinflussen. Microsoft hat diesen Bedarf erkannt und in Project 2007 das neue Feature "Lieferumfang" ("Deliverable") eingeführt (Voraussetzung: Project Server). In diesem dritten und abschließenden Teil der Artikelfolge zeigt Josef Schwab die Anwendung des neuen Features in der Praxis und geht der Frage nach, inwieweit es sich dabei um eine echte Alternative zu den projektübergreifenden Anordnungsbeziehungen handelt.
Alle relevanten Beiträge anzeigen
Tech Link