PMBOK® Guide und die Leistungsbeschreibung (SOW)
Im Rahmen der PMP® Zertifizierung ist die Leistungsbeschreibung ein Prüfungsthema. Die Leistungsbeschreibung wird u.a. als Lastenheft oder auch als Statement of Work bezeichnet. In immer komplexer und komplizierter werden Projekten gilt es, professionelle Lastenhefte anzulegen, die Konflikte im Projektlebenszyklus möglichst vermeiden. Auftragnehmer und Auftraggeber sind hier gehalten, ein produktives Commitment zu erstellen. Konflikte stellen für beide Seiten Stress und Aufwand dar.
Vom Dokument der Anforderungen zur Leistungsbeschreibung
Im PmBok Guide 8.0 dominiert der Begriff „Dokumentation der Anforderungen, (Lastenheft in Deutschland) oder Statement of Work“, kurz als SOW bezeichnet.
Unter 2.2.2.2 , Anforderungen ermitteln und analysieren, (nicht mehr „Anforderungen sammeln“, dieser Begriff wird jetzt nur noch als Tätigkeit genutzt, 2.3, Seite 24) wird auf die Dokumentation der Anforderungen (DdA, Abb. 2-15) der Stakeholder hingewiesen.
Im PMBOK 8.0, wird der Begriff „Leistungsbeschreibung“ (Statement Of Work (SOW)) benutzt. Hier argumentiert man aus der Perspektive des Auftraggebers. Das SOW dient der Ausschreibung für ein Projekt und den potenziellen Auftragnehmern, die eigenen Kapazitäten daraufhin zu prüfen. ( PMBOK 8.0 Abbildung X4-1. Beispiel für Beschaffungsprozessfluss, PMIstandards+ (Nur als PMI Mitglied))
Die Leistungsbeschreibung, der Vertrag mit dem Kunden, der Projektstrukturplan, Termin-, Kosten- und Inhalts- und Umfangspläne müssen widerspruchfrei, nicht interpretierbar und lückenlos sein
Das Lastenheft, das Backlog.
Die Leistungsbeschreibung als Lastenheft, muss durch den Auftraggeber oder Kunden erstellt werden. Wie oben schon erwähnt, dient es auch als Grundlage für eine Ausschreibung. Komplexe Lastenhefte sollten durch Inanspruchnahme einer dritten Partei, die fachlich kompetent ist, erstellt werden. Dass der spätere Auftragnehmer das Lastenheft erstellt oder überarbeitet, ist nicht zu empfehlen, falls nicht über Jahre hinweg eine stabile Vertrauensbasis erwachsen ist.
Kommt es zum Vertragsabschluss, ist es aus Sicht des Auftragnehmers von hoher Wichtigkeit, die “Use Case” orientierte Leistungsbeschreibung “Wasserdicht” zu sichern. Unklarheiten, interpretierungsbedürftige Anforderungen und Lücken, führen während des Projektlebenszyklus meist zu Konflikten. Eventuell ist es auch ratsam, da wo Zweifel aufkommen könnten, Anforderungen zu beschreiben, die nicht in den vertraglich vereinbarten Scope gehören. (Ausschlüsse: PM3 von GPM, S. 592) Mancher Kunden eignet sich während des Projektes protoprofessionelles Wissen an, dass dazu führen könnte, weitere Anforderungen einzubringen. In agilen Projekten meistens unkompliziert, falls es nicht mitten im Sprint dazu kommt.
In agilen Projekten, z.B. Scrum, beruhen die Anforderungen im Backlog (analog zum Lastenheft) meist auf einer “User Story”. Eine “User Story” beschreibt keine Anforderung aufgrund von genauen technischen Spezifikationen, wie der Use Case. Es handelt sich mehr um eine Umschreibung eines Ergebnisses. Derweil bei SCRUM aber der stetige intensive Kontakt mit dem Kunden Teil der Vorgehensweise ist, wird empfohlen, vertragliche Vereinbarungen immer auf den nächsten Sprint zu aktualisieren oder zu erweitern.
TRAINERKNOWLEDGE AI – Ihre smarte PMP®-Vorbereitung!
Bestehen Sie die PMP®-Zertifizierung sicher und flexibel über unsere innovative Online-Plattform. Wählen Sie passgenau: Komplettkurs inklusive der offiziellen 35-Stunden-Kontaktstunden oder als reines Prüfungstraining. Nutzen Sie KI-gestützte Lerneinheiten für maximalen Lernerfolg zu einem absolut unschlagbaren Preis. Jetzt informieren auf trainerknowledge-ai.training und die Karriere auf das nächste Level heben!
Trainer Live Videos – Storytelling – ECO 2026 Bezug
Projekt- und Produktprozesse ergeben die Gesamtleistung
Aus Sicht des Auftraggebers kann es aber auch wichtig sein, spezielle
Prozesse oder Methoden des Projektmanagements zu verwenden. Die
Leistungsbeschreibung sollte daher zwischen den Prozessen des Produkts und den
Prozessen des Projekts klar unterscheiden.
Projektmanagementaufgaben sind keine “Eh da Kosten”!
Auch aus Sicht des Auftraggebers ist es von Interesse, die Leistungen des
Projektmanagements ebenfalls zu operationalisieren. Die Erfassung der Anforderungen in der Leistungsbeschreibung dient diesem Anspruch. Die Operationalisierung der Aufwände hilft dem Auftragnehmer, die Kosten des Projektmanagements dem Kunden gegenüber besser zu argumentieren.
Anforderungen an das Projektcontrolling, hier ein Beispiel des Department of Defence USA:
Das US-Verteidigungsministerium (Department of Defense – DoD) war historisch gesehen der Haupttreiber für die Standardisierung des Earned Value Management (EVM) und schreibt dessen Anwendung bei größeren Beschaffungsverträgen strikt vor.
Die Vorgaben sind in der DFARS (Defense Federal Acquisition Regulation Supplement, Klausel 252.234-7002) geregelt und richten sich primär nach der Vertragsart und dem Auftragswert (Projektbudget):
Die Schwellenwerte für EVM im DoD
-
Ab 20 Millionen US-Dollar (Vertragswert):
-
Anforderung: Der Auftragnehmer muss ein EVMS (Earned Value Management System) nachweisen und anwenden, das den Vorgaben des Standards EIA-748 entspricht.
-
Prüfung: Das System muss formal konform sein, benötigt aber in der Regel noch keine offizielle Zertifizierung („Validation“) durch die US-Regierung, es sei denn, die programmspezifische Risikoanalyse fordert dies ausdrücklich.
-
-
Ab 50 Millionen US-Dollar (Vertragswert):
-
Anforderung: Der Auftragnehmer benötigt ein formal auditiertes und zertifiziertes EVMS („Government Validated System“).
-
Prüfung: Die zuständige Behöre (meist die DCMA – Defense Contract Management Agency) führt strenge Audits durch, um das System offiziell abzunehmen. Ohne ein von der DCMA anerkanntes EVMS darf das Unternehmen Verträge dieser Größenordnung nicht ausführen.
-
Nutzer eines Produkts
Der Kunde oder Auftraggeber nicht immer auch der Nutzer ist, gilt es für den Auftragnehmer auch die Sicht der späteren Nutzer zu kennen. In agilen Projekten übernimmt diese Aufgabe der Product Owner. Diese Sicht spiegeln die Werkzeuge des PmBok Guides zur Erfassung von Anforderungen wieder, aber auch Prozessmodelle wie SCRUM oder PRINCE2.
Werkzeuge zur Erfassung oder genaueren Definition können sein: Interviews, Beobachtungen, Prototyping, Benchmarking, Kreativitätsmethoden wie bspw. Brainstorming, moderierte Workshops, Fragebogen etc.
Anforderungen an die Qualität
Hier sind nicht nur die eindeutigen Anforderungen an die Qualität der Liefergegenstände gemeint, sondern auch die Anforderungen an die Qualität der Produkt- und Projektmanagementprozesse. Modernes Qualitätsmanagement agiert präventiv und senkt dadurch die Qualitätskosten (PMBOK 8.0, Abb 5-3)
“Qualität wird nicht hineingeprüft, sondern hineingeplant!” (Edward Deming)
Nicht nur Auftraggeber interner Projekte, auch externe Auftraggeber
können an qualitativ “robusten Prozessen” interessiert sein. Robuste Prozessesenken und vermeiden Fehler und Qualitätskosten. Gemäßder Aussage Demings,“Wer einen Prozess nicht beschreiben kann weiß nicht was er tut!”, sollten allenegative Elemente und Treiber aus Prozessen bereinigt werden.
Jedes Projekt sollte ein Gegenstand evolutionärer Weiterentwicklung der Qualität in den Prozessen darstellen.
Bezogen auf die Liefergegenstände sollten auch Anforderungen an die Möglichkeiten der Operationalisierung oder Nachweisbarkeit von Qualität und Qualitätsverbesserung generiert werden.
Signifikanz und Kontext der Leistungsbeschreibung
Eine ungenaue Leistungsbeschreibung führt häufig zu Problemen.
Es kommt allerdings darauf an, ob die Leistungsbeschreibung “Use Case”oder “User Story” getrieben aufgesetzt wird. Besonders in agilen Projekten, werden häufig “User Story” getriebene Leistungsbeschreibungen präferiert. Allerdings besteht hier aufgrund der kurzen Sprints und fehlenden Anforderungen auf lange Sicht die Möglichkeit, Korrekturen und neue Anforderungen zu generieren.
Auch bezogen auf unterschiedliche Branchen, sind Leistungsbeschreibungen sehr unterschiedlich zu gestalten.
Das Lastenheft wird Teil des Projektauftrags und muss durch das Projektteam in ein Pflichtenheft (Statement of Scope) umgeschrieben werden, die eigentliche Spezifikation. Wenn das Lastenheft das “Was” beantwortet, beantwortet das Pflichtenheft das “Wie”. Die Synchronisierung aller Dokumente die in einem Kontext zur Leistungsbeschreibung stehen, muss im Rahmen der Überwachung und Steuerung des
Projekts regelmäßig durchgeführt werden. Dies ist aber auch eine Anforderung des Änderungs- und Konfigurations-managements (PmBok Guide 6.0 S.118; PMBOK 8.0 Abb. 2-11)