Projektmanagement: Was ist ein Pflichtenheft?

Im Projektmanagement und im Qualitätsmanagement versteht man unter dem Pflichtenheft das i.d.R. vom Auftragnehmer oder von einer speziellen hierfür eingesetzten Arbeitsgruppe erarbeitete Detailkonzept eines Vorhabens aufgrund der Anforderungen des Kunden, Nutzers oder sonstigen Nachfragers. Der Begriff ist insbesondere in der Softwareentwicklung aber etwa auch im Media Design üblich. Im zweiten Teil dieser Miniserie, die gestern mit einem Artikel zum Lastenheft begonnen wurde, betrachten wir mit den theoretischen und praktischen Merkmalen des Pflichtenheftes sozusagen die andere Seite des Problem.

Im Gegensatz zum Lastenheft muß das Pflichtenheft detailliert und vollständig die Anforderungen des beabsichtigten Projektes enthalten. Es dient dann als verbindliche Grundlage des zu schließenden Vertrages.

Der Begriff des Pflichtenheftes ist wie auch der des Lastenheftes nicht gesetzlich oder sonst verbindlich geregelt; es besteht jedoch ebenfalls eine Regelung in DIN 69905. Demnach sind im Pflichtenheft die vom "Auftragnehmer erarbeiteten Realisierungsvorgaben" niedergelegt. Die beschreiben die "Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes". Während im Lastenheft also steht, was der Auftraggeber will, enthält das Pflichtenheft die Details, wie der Auftragnehmer die Vorgaben des Auftraggebers umsetzen will. Das Lastenheft kann also mit der Nachfrage und das Pflichtenheft mit dem Angebot verglichen werden.

Die einfachste praktische Form des Lastenheftes ist die Benennung eines Liefertermines und eines Preises bei der Anfrage nach einem Produkt; die einfachste Form eines Pflichtenheftes wäre die Benennung eines tatsächlich möglichen Preises und Liefertermines. Eine häufige praktische Art des Pflichtenheftes ist die Baubeschreibung als Grundlage eines Bauprojektes.

Da das Pflichtenheft vom Auftraggeber geschrieben wird, folgt es i.d.R. auch seinen Denkmustern. Es ergibt sich daher das kommunikationstheoretische Problem, die angebotene Art und Weise der Erfüllung der Anforderungen des Lastenheftes so zu beschreiben, daß es der Auftraggeber, der seinen eigenen Denkmustern folgt, auch versteht. Es ist daher von großer Bedeutung, die Abfassung des Pflichtenheftes so vorzunehmen, daß der Auftraggeber transparent sehen kann, wie seine Anforderungen umgesetzt werden sollen. In Pflichten- wie in Lastenheften besteht also das Problem, daß die realitätsbezogene ("alltägliche") Sprache der Anwender und die produkt- oder theoriebezogene Sprache der Techniker ("Fachchinesisch") aufeinander abgestimmt und wechselseitig aufeinander bezogen werden müssen. Dies ist insbesondere in der Softwareentwicklung der Fall, wo die Anforderungen der Anwender oft vage, unzusammenhängend, unvollständig und widersprüchlich sind. Zudem ist dem Anwender oft nicht bekannt, was mit einem bestimmten Softwareprodukt oder im Rahmen einer bestimmten Softwareumgebung möglich ist und was nicht. Die Definition des Leistungsumfanges ist dann besonders problematisch und kann umfassen:

• Mußkriterien: unabdingbare Leistungen,
• Wunschkriterien: erstrebenswerte Leistungen,
• Kannkriterien: Leistungen, die enthalten sein können, denen der Auftraggeber aber neutral gegenübersteht und
• Negativkriterien: Leistungen, die nicht enthalten sein dürfen.

Aufgabe des Auftragnehmers ist es u.U. auch, dem Auftraggeber relevante Kenntnisse soweit nahezubringen, daß er überhaupt in der Lage ist, ein angemessenes Lastenheft zu schreiben, das Grundlage für die Erstellung des Pflichtenheftes sein kann. Die Erstellung des Pflichtenheftes (und indirekt damit auch die des Lastenheftes) kann also eine Beratungsleistung sein. Bei großen Projekten mit viel Abstimmungsbedarf zwischen Auftragnehmer und Auftraggeber wird daher oft eine besondere Arbeitsgruppe zur Erarbeitung des Lastenheftes eingesetzt, die dann auch für die Erstellung des Pflichtenheftes verantwortlich ist.

Anders als die zumeist allgemeinsprachliche Darstellung des Lastenheftes empfiehlt sich die Verwendung von Visualisierungstechniken im Pflichtenheft, weil auf diese Weise Wünsche der Anwender kanalisiert und formalisiert werden können. Aus Darstellungsformen wie dem Flußdiagramm oder dem Blueprinting-Diagramm lassen sich später leicht interne Dokumentationen wie Programmablaufpläne erstellen. Eine gute Möglichkeit, in eine solche formale Darstellung überzuleiten, ist das Mind-Mapping. Die Anforderungen des Pflichtenheftes können sich in der Anwenderdokumentation oder dem Anwenderhandbuch niederschlagen.

Links zum Thema: Projektmanagement: Was ist ein Lastenheft? | Skript zum Qualitätsmanagement | Skript zum Projektmanagement | Kundenzufriedenheit und Qualitätsmanagement im Bildungsbetrieb | Warum Qualitätsmanagementsysteme scheitern (interne Links) | Grundlagen Projektmanagement mit Softwaretest (externe Links)

Hinweise auf relevante Inhalte der BWL CD: [Lexikon]: "Blueprinting", "Flußdiagramm", "ISO 9000", "Kano-Modell", "Kunde", "Lastenheft", "Mind-Map", "Pflichtenheft", "Projektmanagement", "Qualitätsmanagement", "Software". [Manuskripte]: "ISO 9000 2000 Inhalte.pdf", "ISO 9000 Folien.pdf", "ISO 9000 Formulare.pdf", "ISO 9000 Handbuch.pdf", "ISO 9000 Skript.pdf", "Produktion Skript.pdf", "Projekt Management Skript.pdf", "Software im Unternehmen.pdf".
Diese Hinweise beziehen sich auf die zum Zeitpunkt des Erscheinens dieses Artikels aktuelle Version der BWL CD. Nicht alle Inhalte und nicht alle Stichworte sind in älteren Fassungen enthalten. Den tagesaktuellen Stand ersehen Sie aus dem Inhaltsverzeichnis oder dem thematischen Verzeichnis.