Wann und warum ein Lastenheft

In diesem Beitrag möchte ich auf folgende, ganz grundsätzliche Frage eingehen: Warum eigentlich Lastenhefte? Wenn wir mal einen Gedankenschwung über Sinn und Zweck des gesamten Themas machen, so finden wir zwei grundlegende Ausgangslagen für Lastenhefte. Ich möchte diese ein wenig beleuchten.

Unabhängig davon, welchen Business Case Du in Deinem Unternehmen tatsächlich vorliegen hast, es gibt immer diese eine Konstellation: Jemand möchte etwas entwickelt wissen und jemand anderes – ein Spezialist bzw. die richtige Abteilung – entwickelt dieses Etwas.

Die erste typische Ausprägung für ein Lastenheft liegt vor, wenn ein Geschäftskunde sagt: „Ich will für mein Gesamtsystem ein Teilsystem entwickelt haben. Dafür hole ich mir einen externen Spezialisten, der das entwickeln und produzieren kann.“

Diese Situation finden wir typischerweise in der Automobilentwicklung oder bei der Luft- und Raumfahrt, d.h. in Branchen, die mit großen, komplexen Systemen arbeiten. Hier werden die Lastenhefte von den Herstellern erstellt, um den Zulieferern alle nötigen Informationen und Inhalte für die Erstellung und spätere Umsetzung ihrer Angebote vorzulegen.

Die zweite typische Ausprägung bzw. Situation ist die ohne direkten Kunden: Du lieferst in diesem Fall in den Markt hinein, ohne dass es konkrete technische Zielpersonen gibt, wie z.B. in der klassischen Consumer-Elektronik oder bei bestimmten Spezialprodukten.

Hier sind es Produktmanagement und Marketing, die Deine eigentlichen Kunden abbilden. In diesen Fällen arbeitet man nicht mit dem technischen Spezialisten oder dem Projektleiter von beispielsweise VW, wie es bei der ersten Ausprägung der Fall ist. Stattdessen sind es hier eher Produktmanager oder Marketing-Leute, die mit Dir sprechen und Dir eigentlich das Lastenheft übergeben sollten.

Warum? Sie dokumentieren damit ihre Wünsche, das Lastenheft ist ihr „Wünsch Dir was“ – das zusätzlich auch die Beschreibung ihrer Probleme beinhaltet. Das Entscheidende aber für jede Ausprägung, jeden Kunden und jedes Lastenheft: Lastenhefte sind nicht für Lösungen da.

Wenn wir das Thema kurz ein wenig größer aufziehen und fragen, wo Lastenhefte hineingehören, so sehen wir wieder die unterschiedlichen Ebenen, die ich bereits in einigen Podcast-Episoden diskutiert habe: Es sind diese hierarchisch übereinandergelegten Bereiche, von denen der oberste die Kundenebene darstellt.

Und genau auf dieser Ebene existiert das Lastenheft mit der reinen Wunsch- und Problembeschreibung, oft in Kombination mit ergänzenden Grundlagen wie Normen oder referenzierten Standard-Branchenvorgaben etc.

Die nächste Ebene darunter ist die Systemebene mit zwei Artefakten bzw. zwei Teilspezifikationen: Die Systems-Requirements- und die Systems-Architecture-Specification.

Ersteres ist die Antwort auf das Lastenheft, während letzteres quasi die Lösungsbeschreibung darstellt. Dies findet also auf einer anderen Ebene statt als das Lastenheft, welches sozusagen als Dokumentation der Wünsche erstellt wird.

Ein Entwicklungsprojekt antwortet auf diese Wunschliste mit einem Pflichtenheft – auch wenn ich diesen Begriff nicht gerne verwende: Er fasst beide Artefakte aus der Systemebene zusammen, obwohl der Systems-Requirements-Teil aus problembeschreibender Sicht eigentlich schon die Antwort darstellt.

Also: Das Lastenheft gehört als „Wünsch Dir was“ auf die oberste, auf die Kundenebene! Und dort ist es DAS entscheidende Dokument, DAS Artefakt, das ausschlaggebend für ein erfolgreiches Projekt ist.

Meine Erfahrungen aus jahrelangem Trouble-Shooter-Leben zeigen das immer wieder: Projekte, die extreme Schwierigkeiten hatten und sehr stark gestrauchelt sind, hatten immerhin ein mangelhaftes Lastenheft, an dem sie sich mehr schlecht als recht entlanghangeln konnten.

Die Projekte allerdings, die grandios und komplett an die Mauer gefahren wurden, hatten überhaupt kein Lastenheft. Daher denkt daran: Warum Lastenhefte? Weil sie absolut essentiell für erfolgreiche Projekte sind!