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.
Seit 2010 begleite ich als Mentor innovative Entwicklungsprojekte bei Hidden Champions im Mittelstand. Zu Beginn haben die Projekt- und Entwicklungsleiter mir ihre schwierige Situation geschildert: Sie sollten ein neues Produkt für den Markt entwickeln und haben dazu eine klare Zeitvorgabe bis zum nächsten Messetermin bekommen.
Wesentlich problematischer jedoch war, dass sie gerade mal einen Foliensatz mit den Wünschen aus dem Produktmanagement erhalten haben, ganz nach dem Motto: „Das muss ja wohl reichen.“
Ein Lastenheft ist ein Dokument mit den technischen Anforderungen an das zu entwickelnde System. Somit liegt die Verantwortung für das Lastenheft beim Auftraggeber, in diesem Fall beim Marketing bzw. dem Produktmanagement. In diesem Lastenheft werden die Wünsche und die Anforderungen an das zu entwickelnde Produkt beschrieben.
Auf dieser Basis kann die Entwicklungsabteilung eine Aussage treffen, wie lange es dauern und wie viel es kosten wird. Leider enthalten viele Projekte kein Lastenheft und wenn, dann ist es oft nicht zu gebrauchen. Welches Problem steckt aber dahinter?
Auch wenn die Verantwortung für ein Lastenheft beim Marketing liegt, so ist es häufig der Fall, dass sowohl das fachliche wie auch das methodische Wissen fehlen, ein Lastenheft zu erstellen. Hinzu kommt, dass oft weder die Zeit und noch die Lust vorhanden sind – ganz abgesehen von dem Verständnis für den Sinn und Zweck eines Lastenheftes.
Die Frage lautet hierbei: Muss das dann immer so laufen? Meine Antwort: Nein!
Hier kann die Entwicklungsabteilung die Marketing-Abteilung unterstützen, sodass sie gemeinsam ein Lastenheft erstellen können. Das hat mehrere Vorteile:
Die Entwicklungsabteilung hat in der Regel die fachliche Erfahrung und kann die technischen Anforderungen an ein Produkt viel besser benennen. Zudem bedeutet ein gemeinsam erstelltes Lastenheft auch, dass beide ein gemeinsames Verständnis von den Anforderungen an das Produkt entwickeln.
Ein dadurch gut geschriebenes Lastenheft kann ohne Probleme vom Entwicklungsprojekt übernommen und detailliert werden. So wird viel Zeit und Geld eingespart.
Es läuft hierbei immer auf das eine grundlegende Prinzip hinaus: Ein erfolgreiches Projekt benötigt ein gutes Lastenheft. Und wenn das Marketing in diesen genannten Fällen nicht in der Lage ist, ein Lastenheft zu erstellen, ist es sehr sinnvoll, dass die Entwicklungsabteilung sich hier unterstützend einbringt und dass das Lastenheft gemeinsam erstellt wird.
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.
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.
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.
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.
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.
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
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.
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.
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!
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.
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.
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.
11.08.2015 
16 Minuten
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.
30.06.2015 43 Minuten
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.
16.06.2015 33 Minuten
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.
02.06.2015 38 Minuten
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.
19.03.2015 20 Minuten
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.
05.03.2015 13 Minuten
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.