PMP Zertifizierung und die Leistungsbeschreibung. 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 zum Lastenheft
Im PmBok Guide dominiert der Begriff „Dokumentation der Anforderungen, Lastenheft oder Statement of Work“, kurz als SOW bezeichnet.
Im Kapitel 5, Inhalts- und Umfangsmanagement, wird nur der Begriff Dokumentation der Anforderungen (DdA) benutzt. Hier wird aus der Perspektive eines internen Projekts argumentiert. Das DdA bildet hier einen Ausgangswert aus dem Prozess „Anforderungen sammeln“. Die Anforderungen wurden also intern generiert. Mit welchen Werzeugen und Methoden, das wird im Kapitel 5 ausführlich beschriben.
Im Kapitel 12, „Beschaffungsmanagement“, wird der Begriff „Lastenheft“ benutzt. Hier argumentiert man aus der Perspektive des Auftraggebers. Das Lastenheft dient der Ausschreibung für ein Projekt und den potenziellen Auftragnehmern, die eigenen Kapazitäten daraufhin zu prüfen. Das DdA bildet daher einen Eingangswert in dem Prozess „Beschaffungen planen“ und bildet dann den Ausgangswert „Lastenheft“ (Flussdiagram Seite 467 oder 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) Manche 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, die 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.
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. PM3 von GPM spricht daher in Summe vom “Projekt-Leistungsumfang”(S.585).
Projektmanagementaufgaben sind keine “Eh da Kosten”!
Auch aus Sicht des Auftraggebers ist es von Interesse, die Leistungen des
Projektmanagements 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.
Nutzer eines Produkts
Da aber 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 vü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. (PmBok Guide 5th.
Ab S.114)
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 Guide 6 S.274).
“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 Prozesse
senken und vermeiden Fehler und Qualitätskosten. Gemäß der Aussage Demings, “Wer
einen Prozess nicht beschreiben kann weiß nicht was er tut!”, sollten alle
negative 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 Konfigurationsmanagements (PmBok Guide S.118)