Lastenheft erstellen – in zwei Wochen zur Freigabe

Vor einiger Zeit hat mich ein Kunde angesprochen und mich Folgendes gefragt: „Herr Pfingsten, ich brauche ein Lastenheft – in den nächsten zwei Wochen. Geht das?“

Risikominimierung unter Zeitdruck

Dieser Kunde kannte meinen Blog und meinen Podcast, ihm war durchaus bewusst, dass wir Systemingenieure für die Erstellung eines freizugebenden Lastenheftes für ein komplexes System erfahrungsgemäß zwischen zwei und sechs Monate Zeit brauchen.

Dennoch stand er mit dieser Frage vor mir – denn dieser Kunde hatte schlicht keine Zeit: Seine Einkaufsabteilung wollte für fünf Millionen Euro eine Robotik-Anlage bestellen, doch das Einzige, was für die Ausschreibung seinerzeit vorlag, war eine kleine Excel-Liste mit sage und schreibe zehn Zeilen Inhalt. Zehn Zeilen, für fünf Millionen Euro.

Als Projektleiter war ihm das verständlicherweise zu heikel und so suchte er nach einer praktikablen Lösung für seinen Wunsch, ein Lastenheft innerhalb von zwei Wochen zu erstellen. Als er mich fragte, ob das möglich sei, lautete meine Antwort: „Ja!“

In über zehn Jahren als Troubleshooter wurde mir häufig die Aufgabe übertragen, in kurzer Zeit ein akzeptables Lastenheft zu erstellen. So habe ich über die Jahre einen smarten Prozess entwickelt, um innerhalb von zwei Wochen ein freigegebenes Lastenheft zu erschaffen.

Natürlich kann solch ein Lastenheft nicht die Reife und Güte erlangen wie ein Lastenheft, das über Monate erstellt worden ist. Darüber war sich der genannte Kunde auch durchaus im Klaren, doch er wusste, dass das Ergebnis wesentlich besser sein würde als das, was er bis dahin hatte.

Die Zutaten: Ein smarter Prozess – und klare Spielregeln

Der von mir entwickelte Prozess besteht aus fünf Schritten:

  1. Erfassen – Sammle die Anforderungen. Verschaffe dir einen Überblick und visualisiere die Anforderungen an das System. Diskutiere die vorhandenen Wünsche und kläre, was dazugehört.
  2. Sortieren – Strukturiere den Inhalt. Bringe die vorhandenen Ergebnisse in eine sinnvolle Struktur. Sortiere die Inhalte, sodass sie ihren korrekten Platz erhalten.
  3. Füllen – Schließe vorhandene Lücken. Schaffe ein Lastenheft, das inhaltlich korrekt gefüllt ist: Finde und fülle bestehende Lücken und verbessere doppelte oder unklare Inhalte.
  4. Prüfen – Reflektiere das Ergebnis. Überprüfe, ob die vorhandenen Inhalte wirklich stimmig sind. Kläre offene Fragen und passe die Inhalte konstant an.
  5. Freigeben – Erstelle den finalen Stand. Prüfe gemeinsam mit allen Beteiligten, ob das Ergebnis dem aktuellen Wissensstand und den bekannten Vorstellungen entspricht. Korrigiere alles den Änderungswünschen entsprechend und erstelle den finalen Stand.

Hier findest du die einzelnen Schritte noch einmal dargestellt.

Die Spielregeln sind sogar noch einfacher:

  1. Wer sich nicht einbringt, kann sich hinterher nicht beschweren.
  2. Das Timing wird eingehalten. Nur was bis zum vereinbarten Zeitpunkt da ist, wird berücksichtigt. Alles andere nicht.

Mit diesem klaren Vorgehen hat der erwähnte Kunde innerhalb von zwei Wochen ein freigegebenes Lastenheft erhalten. Er war glücklich und zufrieden – denn er konnte das Risiko, fünf Millionen Euro in die falschen Anforderungen zu versenken, deutlich reduzieren.

Viele meiner Kunden waren schon mal in ähnlichen Situationen: Plötzlich erkennt man seinen dringenden Bedarf nach einem Lastenheft, hat aber keine acht Wochen geschweige denn sechs Monate Zeit, um es herzustellen. Mit meinem Lösungsansatz lässt sich diese Herausforderung meistern – wenn sich alle an die genannten Schritte und Regeln halten.

3 Kommentare
  1. Joachim Reinke
    Joachim Reinke sagte:

    Ich bin mal so frei und gehe aus meiner Erfahrung (ich mache ziemlich ähnliches) ein bißchen auf die beiden Punkte “Sammle die Anforderungen” und “Wer sich nicht einbringt, kann sich hinterher nicht beschweren” ein.

    Beiden Punkten ist eines gemeinsam, nämlich die Frage:

    “Von wem sammle ich denn die Anforderungen?” – bzw. “Wer sollte sich denn eigentlich einbringen?”
    Auch die Negationen dieser beiden Fragen sind hochinteressant, also: “Von wem sammle ich die Anforderungen denn *nicht*” – bzw. “Wer sollte sich denn besser nicht einbringen?”

    Diese Fragen sind die zentralen Fragen, wenn es um Stakeholder-Management geht.

    Genau an dieser Stelle im Prozess ist die zentrale Frage, wer meine Stakeholder eigentlich sind. Und wenn ich die finde, wenn sie sich nicht schon von selbst bei mir einfinden. Und auch hier das Gegenteil: wen von denjenigen, der behauptet, Stakeholder zu sein, ich denn vielleicht doch eher in die zweite Reihe schieben kann, ohne dass das später Probleme gibt. (auch hier gilt wie überall: zu viele Köche verderben den Brei).

    Da ich Trainings im Bereich Requirements Engineering gebe, kommt diese Frage immer und immer wieder auf und ich erlebe viel Unsicherheit hier.

    Die Frage “Wen muss ich denn einbeziehen?” hat zwei Antworten, nämlich die Lehrbuch-Antwort und die Praxisantwort.

    Die Lehrbuch-Antwort lautet: Beziehe alle diejenigen ein, die mit Konsequenzen werden leben müssen, wenn das System, das Du spezifizierst, tatsächlich entstehen und in Betrieb gehen wird. Das Wort “Konsequenzen” ist hier breit zu verstehen. Darunter ist von “Ich muss früher aufstehen” über “Ich muss das Geld dafür hinblättern” bis hin zu “Ich kann dann nicht mehr so wie ich will, sondern muss das entstehende System verwenden” alles sein. Und noch viel mehr darüber hinaus.
    Die zweite Antwort (die ernüchternde Praxisantwort) geht noch einen Schritt über die erste Antwort hinaus, sie lautet: Beziehe auch all diejenigen ein, die zwar nicht mit Konsequenzen leben müssten, wenn Dein System entstehen und in Betrieb gehen wird, sondern die aus welchen Gründen auch immer die Möglichkeit hätten, die ganze Sache vor die Wand fahren zu lassen. Diese nenne ich die “pathologischen” Stakeholder 😉 Und die gibt es auch. Fast immer.

    Ich gehe mal auf beide ein:

    Die ersteren findet man einfach. Da habe ich eine Liste, die man als Autor eines Lastenhefts abarbeiten kann: Kunde (hier ist gemeint: der das Geld bezahlen muss), Benutzer (des entstehenden Systems), Entwickler (sie kennen technische Rahmenbedingungen/Restriktionen, die bereits den Lösungsraum einschränken könnten), ggf. Tester/Validierer (ebenfalls wg. möglicher technischer Restriktionen; die Rolle “Validierer” gibt es in manchen Branchen nicht, dann fällt sie weg) und Betreiber (derjenige, der nachher dafür verantwortlich ist, dass das System auch läuft, wenn’s fertig und ausgerollt ist – er weiß am besten, was ein System haben muss, damit es ohne viel Aufwand betreibbar ist und sich in seine Landschaft betriebener Systeme einbettet).

    Je nach Organisation der Firma, die das System haben möchte, wird der Lastenheft-Autor mit diesen verschiedenen Stakeholdern nicht persönlich reden, sondern sie werden auf die ein oder andere Weise “geproxied”, sprich: Er wird vielleicht nicht mit allen 100.000 Benutzern einzeln reden müssen, sondern nur mit dem Produktmanagement und/oder dem Product Owner und/oder dem Vertrieb. Er wird ggf. nicht mit Testern reden müssen, weil die in Personalunion auch die Entwickler sind. Er wird nicht mit dem Betreiber reden müssen, weil der gleichzeitig der Kunde oder der Benutzer ist und somit über das Produktmanagement vertreten ist. Oder eine von vielen anderen Spielarten.

    Klingt erst einmal einfach, ist es in der Realität nicht, weil Rollen oftmals nicht formal festgelegt sind und ein abgesprochenes Rollenverständnis nicht zugesichert ist. Dieses herzustellen ist dann sinnvoll, ist hier aber nicht der Fokus.

    Und dann gibt es die pathologischen Stakeholder. Diese zu finden ist schwierig und erfordert gute und schon durch Erfahrung geschärfte Antennen.

    Es gibt einige Ansatzpunkte, anhand derer man im Vorfeld – d.h. bevor sie einen haben vor die Wand fahren lassen – pathologische Stakeholder identifizieren kann. Hier nur ein kleiner Ausschnitt – die Kriterienliste ist für mich noch ca. 10 Punkte länger:

    1. Gibt es Personen, die sich als Trittbrettfahrer betätigen wollen und durch das entstehende System ein paar persönliche Dinge miterledigen lassen wollen, quasi “unter der Haube” bzw.- “im Windschatten”? Und haben diese Personen die Macht, das System ansonsten scheitern zu lassen?

    2. Gibt es Personen, denen das entstehende Produkt nicht passt, weil sie sich damit überfordert fühlen?

    3. Gibt es Personen, die ihre persönliche Entwicklung im Unternehmen durch das entstehende System mittel- bis langfristig durchkreuzt sehen?

    4. Gibt es Personen, die nach Wertevorstellungen leben, zu denen das entstehende System nicht passt (auch wenn es sie in ihrer täglichen Arbeit eigentlich nicht tangieren würde)?
    Und vieles mehr.

    Spannend wird es jetzt, wenn der Lastenheft-Autor mit den Stakeholdern – sowohl den “echten” also auch den “pathologischen” umgehen soll.

    Er kann und wird nicht alles, was alle sagen, sich zu 100% zu eigen machen können und wollen. Die in diesem Umfeld entstehenden Konflikte auszuhalten und zu lösen ist eine Kernkompetenz, die der Anforderungsautor haben muss. Und sie macht das ganze so spannend.

    Dazu vielleicht später mehr 😉

    • Maik Pfingsten
      Maik Pfingsten sagte:

      Hallo Joachim,

      wow, wunderbar auf den Punkt gebracht!

      Diese beiden Fragen zu beantworten ist in der Praxis eine Herausforderung. Wobei die meiste Arbeit oft bei den Macht-Strategen im Entscheiderumfeld liegt, die versuchen das Lastenheft (oder Spezifikationen im allgemeinen) zu zerschießen. Sei es durch nachträglich lauthals eingebrachte Punkte oder durch nicht erscheinen und anschließendes Zerpflücken beim Review-Workshop.

      Du hast absolut recht, nur mit guter Kommunikationsfähigkeit lässt sich das handhaben. Außerdem kommuniziere ich meine beiden Regeln “Wer da ist, ist da” und “Keine Rückmeldung ist Zustimmung” zu Beginn und habe damit sehr gute Erfahrungen gemacht.

      Schönen Gruß aus Köln,

      Maik

      • Joachim Reinke
        Joachim Reinke sagte:

        Qui tacet consentire videtur: “Keine Rückmeldung ist Zustimmung” ist absolut notwendig. Ohne geht es nicht.

        Wenn ich als Projektleiter Input benötige und schon so einen Verdacht habe, dass es Schweiger gibt, die dann nach dem gesetzten Termin dann doch noch mit Wünschen ankomme, gehe ich da noch etwas weiter.

        1. Falls der Wunsch nach Zuarbeit nur mdl. war, schiebe ich ihn sicherheitshalber noch mal schriftlich nach.

        2. Ich schreibe auch das “Schweigen ist Zustimmung” noch mal rein.

        3. Ich füge noch hinzu, dass es selbstverständlich sein kann, dass mal keine Zeit ist und dass es unter den Umständen völlig ok ist, wenn man um Terminverschiebung bittet.

        4. Ich schreibe dazu, welche Konsequenzen es auf die Timeline des Projekts hat, wenn der genannte Termin nicht gehalten wird. Um allen maximal viel Zeit zu geben, lege ich Termine natürlich nicht willkürlich fest, sondern gebe möglichst lange Zeit. Das hat den Effekt, dass ein Überziehen automatisch dazu führt, dass es zu Projektverzögerungen kommt (weil entweder die Zuarbeit dann zum kritischen Pfad wird oder sie es eh schon vorher war). Dadurch habe ich immer plastisch Konsequenzen in petto.

        Ich habe es immer als hilfreich empfunden, zu Anfang von Projekten so einige Male gezielt vorzugehen. Dann schleift sich ein Termin-Überziehen gar nicht erst ein.

        Wichtig ist, dies alles höflich zu machen und Konsequenzen auch wirklich nur nüchtern und neutral als Konsequenzen – und nicht als Drohungen – zu beschreiben.

Kommentare sind deaktiviert.