Handlungen und Vorgehensweisen

Spezifikationen: Problembewusstsein schaffen – und Lösungen finden

In diesem Beitrag möchte ich auf die Frage eingehen, wie Projekte mit dem Problem der vielen, aber kaum gelesenen Spezifikationen umgehen – und wie sie damit umgehen sollten.

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 waren in der Tat 40.000 Anforderungen. Ich bin das durchgegangen, habe das analysiert und schnell zeigte sich, dass sie damit auch alle nicht-technischen Projektanforderungen kopiert haben – inklusive einiger unsinniger Anforderungen … Damit haben sie gleichzeitig akzeptiert, was dort drinsteht – und einfach weggeschaut.

In einem anderen Fall hatte ein klassisches, mittelständisches Maschinenbau-Unternehmen ihr System entwickelt, nämlich das, was auf der technischen Zeichnung stand, das waren ja die Anforderungen.

Die Probleme mit einem Teilsystem, das im Feld Schwierigkeiten machte, waren dann groß, denn Elektronik und Software, die mit verbaut waren, hat keiner richtig betrachtet. Und es gab auch kein Lastenheft, denn niemanden interessierte das – bis ich hinzukam. Für sie war es eher überflüssiger Ballast. Sie haben sich geduckt und gehofft, dass der Sturm an ihnen vorbeizieht.

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.

Parallel waren damit auch viele Widersprüchlichkeit verbunden, denn in der Automobilindustrie wird heutzutage regelrecht in einem Lego-Schema gearbeitet, vieles ist also „reused“. Das ist generell ein großes Thema, weil oft einfach mehrere Bauteile zusammengesteckt werden und ein Lastenheft ergeben sollen und zwar ein extrem ausführliches – das niemand lesen will.

Da wir zudem in einem Innovations-Projekt saßen, hatte gerade mal ein gefühltes Drittel überhaupt Relevanz für uns. Die anderen zwei Drittel dieses Lastenheftes waren zwar da und wir mussten die durchgehen, aber im Grunde konnten wir das hinterher alles komplett wegkehren.

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.

Ich habe als Mentor in vielen Projekten genau das gemacht: Wir haben den System Footprint aufgehängt, die unterschiedlichsten Spezialisten und auch Bereiche wie Marketing, Vertrieb, Produktmanagement etc. eingeladen und sind gemeinsam durch diesen Footprint gegangen.

Durch diese Visualisierung wird allen erstmal bewusst, was die Anforderungen an dieses gesamte System sind. Wenn ich dann eine Spezifikation lese, habe ich dieses Bild auch im Kopf. Das ist einer der großen Gewinne daran – und dass es für alle funktioniert.

In einem Projekt beispielsweise was es für das Marketing sehr wichtig. Diese Abteilung gab sehr viele Anforderungen mit hinein, doch mit dem Footprint hat das alles wunderbar funktioniert. Er wird dort mittlerweile in den ganzen Business Units eingesetzt und die Unternehmensführung weiß, dass es für sie ein extrem wertvolles Mittel ist.

Es ersetzt keine Spezifikationen, das ist ganz wichtig, es visualisiert diese nur. Aber dann lässt sich mit ihnen auch arbeiten.

Die erste deutsche Online-Bibliothek zum Thema Lastenhefte

Der Blog „Agile Lastenhefte“ eröffnet seine Online-Bibliothek mit Templates, Lernvideos, Tutorials und vielem mehr

Templates und Checklisten sind und bleiben heißbegehrte Werkzeuge. Ob für einen Startpunkt, für den Abschluss – oder für Probleme mittendrin: Sie schaffen den nötigen Überblick, bilden Strukturen ab und ermöglichen sinnvolle Deadlines für Lastenhefte.

Weiterlesen

Der System Footprint – Aufbau und Inhalt

Im letzten Beitrag habe ich die Entwicklungsgeschichte des System Footprints beschrieben. Nun möchte ich mehr in die Tiefe gehen und erläutern, wie das Ganze funktioniert. Zunächst gehe ich im Detail darauf ein, wie der System Footprint aufgebaut ist.

User- und Use-Cases & die Value-Proposition

Im Grunde kann man sich das Ganze als großes Poster vorstellen, welches in mehrere Kästchen aufgeteilt ist, die – ähnlich wie Puzzlestücke – ineinanderpassen.

Auf der rechten Seite des System Footprints platziere ich den Kunden bzw. den Benutzer, der das System hinterher verwendet. In der Mitte findet sich die Value-Proposition, also das Nutzenversprechen, der Grund dafür, dass der Kunde dieses System überhaupt kauft.

Die Value-Proposition sollte unbedingt klar definiert und verstanden werden, denn so können wir später im Requirements Engineering unproblematischer entscheiden, ob eine Anforderung notwendig bzw. wie nützlich sie ist. Manchmal gibt es auch Anforderungen, die einen Nutzen zerstören können. Kenne ich die Value-Proposition eines Systems, kann ich auch hier besser entscheiden, ob diese Anforderung tatsächlich kontraproduktiv ist.

Dieses Nutzenversprechen transportieren wir über zwei Wege zum Kunden: Über die Nutzungsfälle und über die Liefereinheiten. Bei ersterem sind die Key-Use-Cases gemeint, also die Einsatzfälle des Systems. Bei den Liefereinheiten kann es sich entweder um einen ABC-Musterstand handeln oder um Ausprägungen in Basis-, Mittel- und Premium-Varianten.

Beide platzieren wir rechts von der Mitte. Diese beiden Wege sind allein für das Grundverständnis sehr wichtig, denn darüber schafft ein System den essentiellen Wert für den Kunden.

Key Features, Key Components und Schnittstellen

Im mittleren Teil auf der linken Seite des System Footprints setzen wir zwei Aspekte, die den Nutzen erzeugen können: Zum einen die Key-Features bzw. die Hauptfunktionalitäten, die auch in Use-Cases sichtbar werden, und zum anderen die Key Components, also die Hauptkomponenten des Systems. Diese können mechanische, elektronische oder auch Software-Komponenten sein, in denen die Key Features ja häufig verhaftet werden.

Nichtsdestotrotz ist das keine architektonische Vorgabe. Vielmehr ist es oft so, dass es neue Features gibt – schließlich handelt es sich häufig um Entwicklungsprojekte, die noch nicht zwingend ein eigenes Key Component als „Zuhause“ finden.

Dennoch ist diese Trennung wichtig, weil wir aus den Key-Components ja auch die Key-Liefereinheiten, die Key Deliverables darstellen können. Wir können also sagen: „Okay, hier gibt es diesen ABC-Musterstand und da werden diese Key-Components und diese Features einfließen.“

Gleichzeitig kann es diese Ausprägungen für den Markt geben – beispielsweise Basis, Medium, Premium oder Ähnliches -, hierbei sind die Komponenten ebenso notwendig.

Links neben diesem linken Mittelteil finden wir schließlich die Interfaces – also die Schnittstellen des Systems. In jedem Workshop machen wir auch eine große Systemabgrenzung und definieren, was drin und was draußen ist.

Dies ist einer der Schritte, die häufig vergessen werden. Ich kann hier nur nochmals bekräftigen, wie wichtig diese Abgrenzung des Systems und die dazugehörigen Schnittstellen sind.

Der System Footprint im Feinschliff

Das Besondere an diesen Teilen ist, dass wir von links nach rechts quasi einen Wertstrom erstellen: Wir schaffen die Value-Proposition über die Use-Cases und die Liefereinheiten an den Kunden, während wir gleichzeitig dieses Nutzerversprechen über die Schnittstellen, die Features und die Components, also die Funktionen und die Komponenten, erzeugen.

In der Fortentwicklung des System Footprints habe ich die Dimensionen hierbei ein wenig angepasst und die Value-Proposition verkleinert, sodass ich maximal vier Post-Its einfügen kann. In der alten Form war die Value-Proposition in der Mitte ein ziemlich großer Bereich, mit dem die Verlockung wuchs, hier sehr viele Post-Ist einzufügen. Meine Erfahrung über die Jahre ist jedoch, dass zwei, drei Value-Propositions im Kern die beschreibenden Inhalte für ein System abbilden können.

Dies hat zwar die Diskussion um die Value-Proposition noch mal deutlich verschärft, weil ich keinen fünften Post-It zulasse, aber meine Gegenfrage lautet dann: „Wie viele echte KERN-Nutzenversprechen kann es denn realistisch geben?“ Weniger ist auch in diesem Fall mehr.

 

Der System Footprint – Entwicklung und Einsatz

In diesem Beitrag möchte ich den System Footprint als strukturierte Systemvisualisierung diskutieren. Denn obwohl dieser Überblick enorm wertvoll und effektiv ist, wird er oft unterschätzt. Weiterlesen

Requirement Engineering für komplexe Systeme – Teil II

Im letzten Beitrag habe ich bereits zwei Probleme des Requirement Engineering in komplexen Systemen angesprochen: Fehlende Lastenhefte und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Hier möchte ich zwei weitere, nicht weniger relevante Probleme diskutieren. Weiterlesen

Requirement Engineering für komplexe Systeme – Teil I

In diesem Beitrag möchte ich auf die Frage eingehen, warum Requirement Engineering für komplexe Systeme so wichtig ist. Hierfür erläutere ich zunächst die ersten großen Schwierigkeiten in solchen Situationen: Das fehlende Lastenheft und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Weiterlesen

Tolle Kombination: Lastenhefte und agile Methoden

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? Weiterlesen

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.

Agiles Vorgehen bei der Erstellung eines Lastenheftes – Teil IV

Hier könnt ihr den ersten, den zweiten und den dritten Teil lesen!

Phase V: Die Weiterentwicklung

Für die Erstellung eines Lastenheftes und für das Lastenheft selbst ist diese fünfte Phase – die Weiterentwicklung – eine besondere. Denn der Release von 1.0 bedeutet, dass wir das Lastenheft mit bestem Wissen und Gewissen und auf dem aktuellen Stand der Technik und allem, was wir kennen, erstellt haben.

Release 2.0 – Neues einplanen

Gleichzeitig bedeutet es aber auch: Die Welt dreht sich weiter, wir werden neue Erkenntnisse bekommen, wir werden verstehen, dass und warum Dinge nicht funktionieren, wir werden neue Ideen haben. All das wird kommen. Das heißt, 1.0 ist niemals das eine unveränderliche Lastenheft, das beim Abschluss des Projektes zwangsläufig noch immer genauso vorliegen wird.

In der Regel gibt es eine Weiterentwicklung. Und auch diese kann ich über eine Release-Planung durchaus begleiten. Denn immer wieder kann etwas passieren, das nicht eingeplant war:

Ein Fertigungsstandort wurde plötzlich gewechselt, es ist eine neue Technologie hinzugekommen, die bislang überhaupt nicht geplant war, irgendetwas funktioniert auf einmal doch nicht und muss herausgenommen werden und so weiter.

Das heißt, ich kann in dieser fünften Phase tatsächlich hingehen und sagen: „Wie und auf welchen Wegen wandern wir jetzt zum Release 2.0“?

Mit dem bestehenden Lastenheft und der gesamten Dokumentation kann man sich also weiter zum Release 2.0 iterieren. Das ist eigentlich die Idee dahinter: In vielen kleinen Schritten, in vielen kleinen Schleifen weiterkommen – gegebenenfalls auch noch zu einem 3.0.

Selbst das ist nicht ganz unüblich, allerdings handelt es sich hierbei meist nur noch um Änderungswünsche: 2.0 ist inhaltlich meistens schon relativ stabil, während bei 3.0 eher Änderungen über das Änderungsmanagement abgewickelt werden.

Das agile Vorgehen bei der Erstellung eines Lastenheftes im Überblick

Das waren also die fünf Phasen der Erstellung eines Lastenheftes. Da wir hier relativ stark ins Detail gegangen sind und die Veröffentlichung des ersten Teils schon ein wenig zurückliegt, möchte ich hier kurz alle Phasen zusammenfassen:

1. Phase: Die Nutzen-Klärung

Beim System-Footprint-Workshop werden das System und die Anforderungen definiert und visualisiert. Die Release-Strategien helfen, alle Zusammenhänge zu begreifen, ein gemeinsames Verständnis für das Vorgehen zu entwickeln und eine Roadmap zu erstellen.

2. Phase: Datensammlung

Alle Informationen werden im System-Footprint-Template gesammelt, zusammengestellt und geprüft. So entdecken wir noch bestehende Lücken und füllen sie auf.

3. Phase: Erstellung des Lastenheftes

Hier geht es um die kontinuierliche Erstellung eines Lastenheftes mit einem Requirements-Management-Werkzeug. Release-Stände, zusätzliche Inhalte und Pflege der diversen Attribute fallen in diese Phase.

4. Phase: Reviews & Freigabe

Alle Teammitglieder erhalten alle Daten, Dokumentationen und Teile des Lastenheftes, um 1.0 fertigstellen zu können. Durch die Reviews sind die meisten Inhalte bereits bekannt, sodass es nicht mehr um wirkliche Fehler geht, sondern um zu behebende Auffälligkeiten.

5. Phase: Die Weiterentwicklung

Das Lastenheft kann und wird ständig an die aktuellen Entwicklungen angepasst, 2.0- oder gar 3.0-Releases können die Folge sein.

Agiles Vorgehen bei der Erstellung eines Lastenheftes – Teil III

Hier könnt ihr den ersten und den zweiten Teil lesen!

Phase IV: Reviews & Freigabe

In der vierten Phase geht es um das finale Review und die Freigabe: Mit der 0.8-Version gehen wir mit dem gesamten Projekt noch einmal in ein Peer-Review, das heißt: Alle bekommen jetzt wirklich alles.

Reviews

Vorher erhielten manche nur Ausschnitte, weil anderes für sie einfach nicht relevant war. Mit dem 0.8-Release aber gibt es nun ein einziges Dokument, das von allen noch einmal in Form des Peer-Reviews durchzugehen und zu kommentieren ist.

Häufig kommt noch sehr viel an Information und an Zusätzen zurück, daraus machen wir dann den 0.9-Release. Mit diesem gehen wir in einen moderierten Review-Workshop: Wir treffen uns alle gemeinsam vor Ort und gehen noch einmal alles durch.

Das Charmante an dieser Phase ist, dass alle den Release inhaltlich kennen und Ihre Anmerkungen schon im Vorfeld gemacht haben. Somit – und das ist meine Erfahrung wie auch meine verfolgte Strategie – ist hier schon fast alles geklärt.

Findings vs. Fehler

Die Kleinigkeiten und Formulierungen, die noch nicht ganz perfekt sind, sind unproblematisch, denn es sind Findings bzw. Auffälligkeiten und werden natürlich auch dokumentiert – aber es sind keine Fehler.

Für diese Dokumentation setze ich eine Review-Checkliste ein, in der wir Folgendes festhalten: Was ist aufgefallen? Wie schwerwiegend schätzen wir es ein? Ist es dramatisch, also „major“, oder weniger kritisch und daher „minor“? Oder ist es einfach nur eine Rückfrage?

Dies stellt für uns die Basis zur Freigabe dar: Wenn wir keine Major-Aspekte haben, sondern nur ein paar Minor-Punkte, kann durchaus die Freigabe erfolgen. Wenn es Major-Punkte gibt, müssen diese zuvor abgestellt werden.

Bei den Minor-Findings ist es bei der Dokumentation sehr wichtig, direkt eine Empfehlung zu geben, wie diese Auffälligkeiten zu ändern sind. Denn in der Regel gehen wir nach dem moderierten Review-Workshop alle wieder zurück an unsere Arbeit – und nicht immer ist die allererste Aufgabe, diese Punkte abzustellen.

Es kann also auch ein paar Tage dauern, bis daran gearbeitet wird. Mit der Dokumentation kann aber jeder sehr gut nachvollziehen, was das Problem war und wie die Empfehlung lautete, das anzupassen.

Der 1.0-Release

Wenn all das passiert ist, also die Review-Checkliste mit allen Findings durchgegangen und alles erledigt worden ist, folgt automatisch der 1.0-Release.

Denn – und das ist das Schöne daran – wir haben jetzt eine Dokumentation, ein Lastenheft, das Review-Protokoll und die Dokumentation über die Abstellung aller Auffälligkeiten beim finalen Review auf 0.9-Basis.

ALLE haben ihr „Go“ gegeben und wir brauchen für diese 1.0-Version entsprechend keine weiteren Unterschriften. Zudem können wir mit 1.0 und dem Review-Protokoll jederzeit alles nachweisen. Das hat bei B. Braun wunderbar funktioniert, auch im offiziellen Vorstellungsmeeting mit dem obersten Top-Management.

Auf dieser Basis folgten zudem u.a. die Aufwandsschätzungen für die zukünftige Entwicklung – denn mit der Erstellung eines Lastenheftes können wir auch diese viel besser unterstützen.