Best Practice, Do’s und Dont’s

Ein Lastenheft für interne Abteilungen

/in

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.

Nicht benannte Wünsche können nur schwer erfüllt werden

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!

Gebündeltes Wissen und Knowhow für ein gutes Lastenheft

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.

 

Spezifikationen: Problembewusstsein schaffen – und Lösungen finden

/in , ,

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.

Requirements Engineering für komplexe Systeme

/in ,
Weiterlesen

Spezifikationen: Essentiell – und ungelesen

/2 Kommentare/in ,

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

Stolpersteine bei der Erstellung eines Lastenheftes – Teil II

/in

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

/in

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.

Der Unterschied zwischen Lastenheft und Pflichtenheft

/in
Weiterlesen