Beiträge

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.

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

Spezifikationen: Essentiell – und ungelesen

Warum werden Spezifikationen oft nicht gelesen? Alle wissen, dass sie essentiell sind, dennoch befinden wir uns häufig in Situationen, in denen plötzlich niemand weiß, worum es geht. Weiterlesen

Ein Lastenheft für interne Abteilungen

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

Zwei völlig unterschiedliche Dokumente: Lastenheft vs. Pflichtenheft

Mehrfach durfte ich schon die Erfahrung machen, dass in Projekten nicht allen klar war, was der Unterschied zwischen Lastenheften und Pflichtenheften ist – und warum beide in einem Projekt erstellt werden sollten.

Von Äpfeln und Birnen

Häufig werden diese beiden Dokumente durcheinandergeworfen. Dabei haben Lastenhefte und Pflichtenhefte sehr unterschiedliche und sehr wichtige Zwecke, wenn es darum geht, ein System zu entwickeln. Leider habe ich viele Projekte erlebt, die entweder kein Lastenheft angelegt hatten oder sich das Pflichtenheft sparen wollten.

Im extremsten Fall wird versucht, beide zu vereinen, sodass ein Lastenheft gleichzeitig auch das Pflichtenheft darstellen soll. Ich habe tatsächlich erlebt, dass diese zwei Dokumente sich einzig durch die Farbe der Sätze voneinander unterschieden. Das ist eine Katastrophe und führt mit Sicherheit zu nicht lösbaren Schwierigkeiten. Weiterlesen

Stolpersteine bei der Erstellung eines Lastenheftes – Teil II

Im letzten Beitrag habe ich bereits zwei in der Praxis oft gesehene Stolpersteine bei der Erstellung eines Lastenheftes beschrieben und wie man diese effektiv überwinden kann. Im Folgenden gehe ich auf den dritten typischen Fehler und seine Lösung ein.

3. Es werden keine Rückmeldungen gegeben

Wenn die Erstellung eines Lastenheftes schließlich seinen Lauf nimmt, tauchen schnell die ersten Fragen auf. Zudem hat das Lastenheft vielleicht auch schon einen ersten Stand erreicht, der von anderen Experten gegengelesen werden kann.

In dieser Phase ist der für das Lastenheft Verantwortliche darauf angewiesen, das andere Kollegen und Experten seine Fragen beantworten und ihm ein Feedback liefern. Das geschieht aber häufig nicht und meist werden Ausreden wie “ich habe keine Zeit” oder “das ist jetzt nicht wichtig” herangezogen.

Was ist das Problem?

In dieser Phase passieren zwei Dinge: Zum einen erhält der Verantwortliche keine Rückmeldung. Somit kann er nur das im Lastenheft dokumentieren, was er für richtig hält. Durch die fehlenden Rückmeldungen ergeben sich in der Praxis aber häufig Lücken, fehlerhafte Anforderungen etc.

Zum anderen wird die Arbeit des Verantwortlichen herabgestuft: Es ist ganz klar eine wertende Aussage, keine Zeit zu haben, um dem Kollegen eine Rückmeldung zu geben. Noch schlimmer ist es natürlich, ihm klar zu signalisieren, dass seine Arbeit nicht wichtig ist. Dadurch entsteht Frustration – und mit Sicherheit kein gutes Lastenheft.

Was ist die Lösung?

Den Teammitgliedern muss vonseiten der Führungskräfte im Projekt klar kommuniziert werden, dass sowohl die Arbeit des Verantwortlichen als auch das Lastenheft als Ergebnis sehr hohen Wert für das Projekt haben. Das führt dazu, dass die angesprochenen Experten nun selbst abschätzen müssen, ob Ihre Arbeit wirklich wichtiger ist als das Lastenheft.

Ein weiterer Trick ist, dem Verantwortlichen einen direkten Kanal zu den Führungskräften im Projekt zu geben. Über diesen kann er sich im Zweifel zügig melden, wenn er ein Problem nicht alleine lösen kann.

Zusammenfassung

Diese Stolpersteine zu kennen und zu berücksichtigen, kann dazu führen, dass die Erstellung des Lastenheftes deutlich reibungsloser und erfolgreicher abläuft.

Entscheidend ist, sich nach der Entscheidung für ein Lastenheft die nötige Zeit zu nehmen, um die richtige Person auszuwählen, d.h. also eine Person, die qualifiziert, erfahren und zudem wirklich motiviert ist.

Danach gilt es, sich einen ordentlichen Überblick zu verschaffen – und ihn auch zu behalten. Das Team darf das große Ganze nicht aus den Augen zu verlieren, wenn es sich in die Masse der vorliegenden Dokumente vertieft.

Und schließlich ist es entscheidend, das gesamte Projekt zur Mitarbeit zu bewegen und die Motivation zu fördern. Die Führungskräfte des Projektes müssen den hohen Stellenwert des Lastenheftes klar kommunizieren und dem Verantwortlichen direkte Kommunikationswege freihalten.

Wenn diese Stolpersteine vermieden werden, ist ein Projekt einem wirklich guten Lastenheft und einem erfolgreichen Abschluss ein ganzes Stück näher gekommen!

Stolpersteine bei der Erstellung eines Lastenheftes – Teil I

Bei der Erstellung eines Lastenheftes gibt es immer wieder Hürden, die dazu führen, dass ein Lastenheft nie fertig wird. In diesem zweiteiligen Artikel gehe ich auf die drei typischen Stolpersteine ein, die ich in der Praxis immer wieder vorfinde.

1. Die falsche Person ist verantwortlich

Endlich ist die Entscheidung gefallen: Für das Projekt soll ein Lastenheft erstellt werden. Dann wird geklärt, wer das Lastenheft schreiben soll – und zwar möglichst sofort, denn jetzt muss es plötzlich ganz schnell gehen: Das Lastenheft soll am besten gestern fertig sein und eine dafür verantwortliche Person wird gebraucht – also wird oft voreilig entschieden:

Derjenige, der nicht schnell genug einen Schritt nach hinten gemacht hat, wird ausgewählt. So bekommt nicht derjenige die Aufgabe, der die entsprechende Qualifikation dazu hat, sondern der, der sozusagen zur falschen Zeit am falschen Ort war.

Was ist das Problem daran?

Wenn ich nicht die Qualifikation habe und damit auch nicht die Erfahrung, ist die Wahrscheinlichkeit hoch, dass ich die Aufgabe vor mir herschiebe. Das führt häufig dazu, dass viel zu spät begonnen wird, das Lastenheft zu schreiben.

Irgendwann folgt dann die Erkenntnis, dass immer noch kein Lastenheft vorliegt. Also muss alles noch schneller gehen – und das Lastenheft wird irgendwie zusammengeschrieben. Da Zeit, Lust und Fähigkeit fehlen, ist es in dieser Situation kaum möglich, ein wirklich vernünftiges Lastenheft zu erstellen.

Was ist die Lösung?

Suche in deinem Unternehmen oder Projekt die Person heraus, die sich wirklich mit Begeisterung um ein Lastenheft kümmern wird. Lass dir Zeit bei dieser Suche: Es macht wenig Sinn, den erstbesten anstatt den allerbesten für diese Aufgabe zu finden.

2. Es wird zu kompliziert gestartet

Man will doch ein Lastenheft für ein komplexes System schreiben, also muss man mit dem Naheliegenden beginnen und sämtliche Dokumente zusammensuchen, die man in die Finger kriegen kann.

Dann wird sich durch all diese Dokumente gewühlt, um einen Überblick zu bekommen – nur um anschließend festzustellen, dass man keine Ahnung hat, was man mit dem „Ergebnis“ anfangen soll.

Also sucht man Beispiele und Vorlagen aus anderen Projekten, denn vielleicht findet man dort die richtigen Hinweise, wie ein Lastenheft aussehen soll. Und so vergeht die Zeit …

Was ist das Problem daran?

Bei dieser Vorgehensweise, die ich häufig in Projekten sehe, stürzen sich die Teammitglieder direkt in alle gefundenen Dokumente und versuchen, diese zu analysieren. Je weiter sie sich in die Tiefe bohren, umso mehr verlieren sie den Blick für das große Ganze. So vergeht viel Zeit, während ein wirkliches Ergebnis ausbleibt.

Was ist die Lösung?

Zunächst einmal muss sich das gesamte Projekt den richtigen Überblick verschaffen. Dabei hilft zum Beispiel das „System Footprint“: Mit dieser Visualisierung bekommen alle einen Überblick darüber, was überhaupt in ein Lastenheft hinein soll. Jetzt erst kann man den nächsten Schritt gehen und aus den vorliegenden Dokumenten das heraussuchen, was wirklich notwendig ist.

Den dritten Stolperstein bei der Erstellung eines Lastenheftes – fehlende Rückmeldungen – und meine Lösungsansätze dazu erläutere ich im nächsten Beitrag.

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!

5 Schritte zur erfolgreichen Systemabgrenzung im Lastenheft

Eine erfolgreiche Systemabgrenzung hilft im Lastenheft zu entscheiden, wo drinnen und wo draußen ist.

Ein System existiert niemals alleine, sondern interagiert immer mit anderen Systemen oder Menschen. Die Grenzen zeigen uns, was im System drinnen und draußen ist. Gleichzeitig ermöglicht uns die Systemgrenze auch, die Schnittstellen des Systems zu identifizieren und festzulegen, was über die Systemgrenzen hinweg ausgetauscht wird. Schnittstellen sind der entscheidende Faktor in einem System. Weiterlesen

Sieben Möglichkeiten um Requirements zu finden

Um Requirements an ein System zu finden müssen wir eine Übersicht erlangen. Das bedeutet, sich die Zeit zu nehmen, um alle relevanten Quellen zu sammeln und sich einen Überblick zu verschaffen. Weiterlesen

Episoden

SF008: Fünf Mythen rund ums Lastenheft

11.08.2015 16 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

Seit über 10 Jahren beschäftige ich mich als Systemingenieur mit Lastenheften und mir sind einige Mythen über den Weg gelaufen, mit denen ich aufräume.

Denn diese Mythen halten sich hartnäckig und sind oftmals mit ein Grund, warum Projekte in Schwierigkeiten kommen. In der Episode wirst du erfahren, warum Lastenheft oft inhaltlich falsch sind und was du dagegen tun kannst.

Die fünf Mythen rund ums Lastenheft:

  • Mythos #1: Es ist effektiv das Lastenheft und das Pflichtenheft in ein Dokument zu packen
  • Mythos #2: Wir machen Scrum und brauchen kein Lastenheft
  • Mythos #3: Ein Lastenheft kann nicht mehr verändert werden
  • Mythos #4: Projektanforderungen gehören ins Lastenheft
  • Mythos #5: Ein Lastenheft zu erstellen braucht Monate

SF005: Wie kann ich Lastenhefte miteinander verknüpfen?

30.06.2015 43 Minuten

On Air in dieser Episode

avatar Maik Pfingsten
avatar Oskar von Dungern

Lastenhefte in komplexen Systemen können einen Umfang einnehmen, der nicht so ohne weiteres handbar ist. Gerade wenn auch noch das Variantenmanagement mit hinzu kommt.

Durch den Einsatz der semantischen Verknüpfung und der Fundamental Modeling Concepts können wir dieser Herausforderung entgegentreten. Ich bin im Gespräch mit Dr. Oskar v. Dungern, der sich seit Jahren mit dieser Methode beschäftig und sie in der Praxis einsetzt.

Inhalt der Episode

  1. Warum ist semantische Verknüpfung so hilfreich?
  2. Was sind Probleme im Umgang mit komplexen Lastenheften?
  3. Was kann Fundamental Modeling Concepts bewirken?
  4. Wie kann ich Traceability verbessern?

SF004: Lastenheft erstellen – Schritt für Schritt

16.06.2015 33 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

Ein Lastenheft zu erstellen ist oft Buch mit sieben Siegeln. Ich zeige meine Vorgehensweise, um erfolgreich ein Lastenheft zu erstellen.

Während meiner über 10 Jahren Erfahrung als Troubleshooter habe ich eine sehr effektive und schnelle Vorgehensweise entwickelt, um ein Lastenheft zu erstellen. In dieser Episode gehe ich auf die einzelnen Schritte ein und gebe Tipps und Tricks weiter.

Inhalt der Episode

  1. Warum eigentlich Lastenhefte?
  2. Wie gehe ich vor, um ein Lastenheft zu erstellen?
  3. Tipps und Tricks aus der Praxis

SF003: Tipps um Schnittstellen zu beschreiben

02.06.2015 38 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

Schnittstellen sind oft der Grund für fehlerhafte Systeme. Um so wichtiger ist es, sie zu identifizieren und zu beschreiben.

Ich habe eine Hörerfrage zur Schnittstellenbeschreibung erhalten. In dieser Episode gehe ich darauf ein, wie wichtig Schnittstellen sind, wie Schnittstellen identifiziert und in einem Lastenheft beschrieben werden können. Denn fehlerhaft oder gar nicht beschriebene Schnittstellen ist einer der Hauptgründe, warum komplexe Systeme später nicht richtig funktionieren. Ich erläutere, wie Schnittstellen zu identifizieren sind, wie ich Pattern nutze, um Schnittstellen zu beschreiben und gebe meine Tipps aus der Praxis.

Inhalt der Episode

  1. Warum müssen wir uns über Schnittstellen Gedanken machen?
  2. Wie können wir Schnittstellen identifizieren?
  3. Was für Tipps und Tricks gibt es?

LH002: Lastenheft vs. Pflichtenheft

19.03.2015 20 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

Lastenheft? Pflichtenheft? Was ist was und was gehört wo rein? In dieser Episode erkläre ich zu Zusammenhänge und zeige die fünf größten Denkfehler auf.

Ich erlebe häufig, das in vielen Projekte der Zusammenhang zwischen Lastenheft und Pflichtenheft nicht klar ist. Deshalb gehe ich in dieser Episode darauf ein, wie Lastenheft und Pflichtenheft zusammenhängen. ich erkläre, wer für das Lastenheft und wer für das Pflichtenheft zuständig ist. Zum Schluss räume ich mit den fünf größten Denkfehlern zum Lastenheft auf.

Inhalt der Episode

  1. Warum gibt es Lastenheft und Pflichtenheft?
  2. Wie hängen Lastenheft und Pflichtenheft zusammen?
  3. Was sind die fünf größten Denkfehler?

LH001: Der System Footprint Podcast

05.03.2015 13 Minuten

On Air in dieser Episode

avatar Maik Pfingsten

In der Episode erfährst du, warum es den System Footprint Podcast gibt, wer ich eigentlich bin und was der Podcast für dich bringen kann.

In dieser Episode erzähle ich, warum ich den Podcast und den Blog gestartet habe. Ich berichte über die Ideen, die ich gerade umsetze und wie du davon profitieren kannst. Wenn du ein Entscheider im Technologieumfeld bist und Fragen zu Lastenheften hast, oder Hilfe brauchst, werde ich für dich eine nützliche Anlaufstelle aufbauen.

Inhalt der Episode

  1. Wer steckt hinter dem Podcast?
  2. Warum gibt es den System Footprint Podcast?
  3. Was habe ich geplant?