Im Interview beim Projektmanagement-Podcast erzähle ich über die Unterschiede zwischen einem Lastenheft und dem Pflichtenheft, über die Methoden zur Erstellung von Lastenheften und der Möglichkeit diese auch freizugeben.
Viele Entwicklungsprojekte kennen das Problem: Sie werden vom Marketing beauftragt, ein neues Produkt zu entwickeln – erhalten dazu aber kein Lastenheft.
Ich habe mit vielen Projektleitern und -teams gesprochen, die diese Situation kennen und ihr Projekt dadurch nicht optimal durchführen können.
Viele Projektleiter sind verunsichert, wenn sie ein Lastenheft mit ihren agilen Methoden bzw. Scrum vereinen sollen. Ist ein Lastenheft wirklich noch sinnvoll, wenn sich unsere Anforderungen ständig verändern? Wenn wir als Systemingenieure für das Erstellen eines Lastenheftes für ein komplexes System zwei bis sechs Monate brauchen, gibt es dann eine Möglichkeit, dabei agil vorzugehen? Und passt ein Lastenheft eigentlich mit Scrum zusammen?
Der Systems-Engineering Management-Plan bietet einen umfassenden Ansatz für die erfolgreiche Verwaltung und Durchführung des Projekts. Durch die Anwendung von Systems-Engineering-Prinzipien während des gesamten Projektlebenszyklus wird ein zuverlässiges und hochwertiges System liefern, das die Erwartungen und Anforderungen aller Beteiligten erfüllt.
Die Ergebnisse, die wir als Geistesleister erstellen, existieren meist im virtuellen Raum. D.h., wir können sie nicht anfassen oder ausprobieren. Wir können zwar heutzutage mittels moderner Methoden, gewisse Aspekte automatisch prüfen lassen. Allerdings sind Reviews, an denen Menschen beteiligt sind, für unsere Arbeit enorm wirkungsvoll.
Warum das so ist und wie sie effektiv eingesetzt werden können, beschreibe ich im Artikel auf meiner Webseite näher.
Welche Spezifikationen? Oder: Duck an cover
Den ersten und häufigsten Weg nenne ich gerne „duck and cover“ nach dem amerikanischen Spruch aus dem kalten Krieg. Diese Variante liegt in zwei Ausprägungen vor.
Aus Last mach Pflicht – Variante I
Die eine Ausprägung: Man nehme sich das Lastenheft, kopiere stumpf einfach alles – und schreibe darüber „Pflichtenheft“. Das habe ich als Troubleshooter in einem Projekt gehabt und schließlich gefragt: „Wie ist eigentlich diese Systems-Requirements-Specification entstanden?“ „Die ist aus dem Lastenheft kopiert. Wir haben keine Zeit und es sind viel zu viele Anforderungen.“
Das große Nichtstun – Variante II
Die zweite Variante sehe ich häufiger bei kleinen und mittelständischen Unternehmen: Einfach gar nichts machen.
Diesen Fall habe ich mit absolut extensiven Spezifikationen bei einem Elektromobilitäts-Projekt erlebt. In der Vorprojektphase brachte der Hersteller ein 600-Seiten starkes Dokument und sagte, dies seien die Spezifikationen.
Wirklich hinschauen – die Visualisierung der Spezifikationen
Der dritte Weg, der sich nun mehr und mehr durchsetzt, ist, die Anforderungen erstmal zu visualisieren und sich ein Gesamtbild zu machen.
Vor einiger Zeit hat mich ein Kunde angesprochen und mich Folgendes gefragt: „Herr Schorre, ich brauche ein Lastenheft – in den nächsten zwei Wochen. Geht das?“
Wenn es um die Erstellung von Lastenheften geht, kann man gewisse Fehler vermeiden – wenn man sich von Beginn an bewusst macht, welche diese sind und wie und warum sie entstehen.
In dieser und der folgenden Ausgabe des Blogs möchte ich Euch sieben entscheidende Tipps geben, die die Erstellung von Lastenheften vereinfachen und Fehlerquellen minimieren.