Best Practice, Do’s und Dont’s

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.

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.

Sieben Tipps zur Erstellung von Lastenheften – Teil II

Wenn es um die Erstellung von Lastenheften geht, kann man gewisse Fehler vermeiden – wenn man sich von Beginn an bewusst macht, welche diese sind und wie und warum sie entstehen.

In dieser und der folgenden Ausgabe des Blogs möchte ich Euch sieben entscheidende Tipps geben, die die Erstellung von Lastenheften vereinfachen und Fehlerquellen minimieren.

Hier geht es zu den ersten drei Tipps!

Tipp 4: Keine Referenzen auf Personen!

Auch das habe ich immer wieder erlebt: „Kann man nicht noch einmal auf den Kollegen, der den Input gegeben hat, referieren?“

Nein, kann man nicht!Das macht in einem Lastenheft keinen Sinn, und zwar aus zwei Gründen: Zum einen wird dieser Kollege in einem Jahr wahrscheinlich nicht mehr an der Position oder nicht mehr für die Aufgabe zuständig sein. So ist das Projektgeschäft, Projekte wechseln, Kollegen wechseln.

Zum anderen kann daraus der Fehler entstehen, diese Person indirekt oder sogar direkt als Anforderung zu beschreiben: „Das ist die Person, mit der alles geklärt werden muss.“

Also: Keine Referenzen auf Personen im System-Lastenheft. Das ist ganz, ganz wichtig.

Tipp 5: Kein Excel!

Bitte, bitte, bitte kein Excel. Wenn kein Requirements-Management-Werkzeug vorliegt oder ein Austausch mit dem Kunden nicht anders funktioniert, verwendet Word – aber kein Excel.

Erstens kann Excel keine Bilder einbinden: Wenn ich eine Visualisierung im Lastenheft haben will und Excel nutze, schwebt diese gedanklich quasi über den Tabellen. Das heißt vor allem, dass es keine Zuordnung gibt. Wenn dann – wie schon oft erlebt – Inhalte und Referenzen verrutschen, Zeilen gelöscht oder verschoben werden, steht das Bild plötzlich ganz woanders bzw. vielleicht noch auf der gleichen Position, aber mit ganz anderem Kontext.

Bei Word funktioniert das besser, Word kann mit Bildern umgehen.

Zweitens verführt Excel einen dazu, in dieser Tabellensicht eines Requirements-Management-Werkzeuges zu arbeiten. Das ist zwar super, wenn man Profi ist – aber in der Regel sind die Leute, die so ein Artefakt, so ein Lastenheft schreiben, nicht unbedingt Spezialisten für Requirements-Management-Werkzeug-Anwendungen. Das bedeutet, sie haben enorme Schwierigkeiten, in so einer Excel-Tabelle flüssig zu schreiben. Dabei ist genau das viel wichtiger. Ich kümmere mich um den Rest und mache mit meiner Erfahrung alles entsprechend „sauber“.

Mir ist es egal, ob Deutsch oder Englisch, und mir ist auch egal, wie es formuliert ist, Requirements-Grammatik muss hier nicht eingehalten werden, nichts muss eingehalten werden – Hauptsache, die Inhalte werden flüssig heruntergeschrieben, wie sie den Kollegen in den Kopf kommen, und liegen am Stück vor.

Fangen die Leute aber an, in Excel von einem Tab zum nächsten und von einer Zeile zu anderen zu springen, kann genau dieses „Herunterschreiben“ nicht funktionieren.

Also bitte, bitte kein Excel.

Tipp 6: Keine Lösungen beschreiben!

Mit diesem Punkt verhält es sich so ähnlich wie mit dem bereits beschriebenen Pseudo-Code – und auch dieser Punkt ist extrem wichtig: Wir beschreiben im Lastenheft keine Lösungen.

Was wir schon beschreiben können, ist, welche Dinge übernommen werden müssen, aus welchem Grund auch immer. Das ist kein Problem, aber wie eine zukünftige Lösung, die noch zu entwickeln ist, auszusehen hat, gehört hier nicht hin.

Was ich hineinschreibe, ist der Wunsch, die Vorstellung von dem, was ich hinterher brauche – nicht aber, wie es umzusetzen ist. Denn Lösungsbeschreibungen kommen erst auf der Systemebene, nicht auf der Ebene des Lastenheftes.

Tipp 7: Lastenhefte sind keine Pflichtenhefte!

Vermischt Lastenhefte nicht mit Pflichtenheften. Ein Lastenheft ist ein „Wünsch dir was“ – und bleibt ein „Wünsch dir was“.

Ich habe mittlerweile mit mehreren Kunden aus den verschiedensten Branchen genau diese Diskussion geführt. Die Vermischung kommt häufig daher, dass Firmen bzw. Projekte kein Requirements-Management-Werkzeug nutzen. Das bedeutet, wenn sie Lastenheft und Pflichtenheft als einzelne Dokumente sehen, als einzelne Artefakte, müssten sie im Grunde hingehen und Teile des Lastenhefts kopieren, entsprechend ergänzen, verändern, anpassen, löschen und so weiter. Sie müssten inhaltlich quasi Sinnvolles übernehmen bzw. andere Antworten schreiben.

Das führt dazu, dass viele darin doppelte Arbeit sehen bzw. das ganze Organisieren und Verwalten eben nicht entsprechend funktioniert. Wir können aber, solange kein Requirements-Management-Werkzeug da ist, keine Traceability – so nennt sich das fachlich – herstellen. Das heißt, ich kann nicht aus einem Lastenheft eine Anforderung in ein Pflichtenheft ableiten.

Um das zu umgehen, neigen viele Firmen dazu, Lasten- und Pflichtenheft in ein Dokument zu schreiben. Ob diese Teile in zwei verschiedenen Farben dargestellt werden oder das eine Heft quasi mithilfe der Struktur des Dokuments dargestellt wird: Ganz ehrlich – das ist Bullshit.

Lasst das bleiben! Und wenn Ihr doch diesen Weg gehen wollt: Ich gehe da nicht mit. Es führt – auch aus Erfahrungen aus dem Trouble-Shooting – definitiv ins absolute Chaos.

Sieben Tipps zur Erstellung von Lastenheften – Teil I

Wenn es um die Erstellung von Lastenheften geht, kann man gewisse Fehler vermeiden – wenn man sich von Beginn an bewusst macht, welche diese sind und wie und warum sie entstehen.

In dieser und der folgenden Ausgabe des Blogs möchte ich Euch sieben entscheidende Tipps geben, die die Erstellung von Lastenheften vereinfachen und Fehlerquellen minimieren.

Tipp 1: Realistische und strikte Zeitplanung und -einhaltung!

Ihr müsst Eure (und meine) Zeit sinnvoll einplanen – und dranbleiben. Bei meinen Erstgesprächen für die Erstellung eines Lastenheftes mit den Entwicklungsleitern kommt sehr schnell die Frage: „Wie viel Zeit werden wir brauchen?“

Zunächst sind der Footprint-Workshop und der Aufbau der Release-Strategie ganz wichtig – auf diesen beiden Grundlagen basiert schließlich der gesamte Rest. Zeitlich sind sie allerdings nicht so wahnsinnig aufwändig: Diese beiden Punkte sind relativ einfach in ein bis zwei Tagen abzuarbeiten.

Dann geht es um das Erarbeiten der Inhalte (also der Teile 0.3, 0.5, 0.7, 0.8, 0.9, 1.0) – und hier müssen wir zwischen dem Aufwand und der Dauer unterscheiden. Der Aufwand auf Seiten des Projektes entsteht, weil noch fehlende Teile beschrieben werden und viele Inhalte zum Review müssen.

Der Aufwand auf meiner Seite ist ein etwas anderer: Ich kümmere mich mit meinem Erfahrungsschatz und meinem Wissen – quasi mit der Hand auf dem Ganzen – um die Erstellung und das „Hübsch-Machen“. Beim B.-Braun-Projekt beispielsweise belief sich mein Aufwand auf 18 Tage.

Man könnte meinen, dies klinge relativ locker – doch Vorsicht: Aufwand ist nicht Dauer! Denn gleichzeitig bedeutet diese Vorgehensweise auch: Wenn irgendjemand im Projekt etwas sucht oder erarbeitet, ist das eine Phase, in der ich zunächst auf weiteren Input warte. Entscheidend für die Organisation ist hierbei, dass ich je nach Projektphase ca. zwei Tage pro Woche für solche 18-Tage-Projekte einplane.

Somit bedeutet dieser Aufwand also eine Dauer von vier Monaten – und das ist nicht unüblich. Bei der Berechnung kommt es auch auf die Größe und die Komplexität des Systems an: Bei überschaubaren Subkomponenten und einem übersichtlichen Entwicklungsteam war das schnellste Lastenheft in ca. drei Wochen erstellt, das aufwändigste dauerte hingegen acht Monate: Hier handelte es sich um ein hochkomplexes, hochintegratives System von Systemen.

Mein Fazit: Unterschätzt die Dauer nicht, auch wenn der Aufwand nicht allzu hoch sein mag.

Plant also die Zeit ein – und vor allem: Bleibt dran! Das ist ein ganz großer Punkt. Immer wieder erstelle ich für Projekte Lastenhefte und merke, dass die Aktivitäten peu à peu weniger werden oder gar im Sande verlaufen.

Hierbei ist der Projektleiter ganz entscheidend, denn ich kann die Motivation des Teams nicht steuern, das kann nur er: Wenn der Projektleiter sich dahinterklemmt, dranbleibt und das Ganze wirklich planmäßig abschließen WILL, dann schaffen wir es auch.

Tipp 2: Weniger ist mehr!

Ich bekomme bei den Vorbereitungen immer wieder zu hören, dass man am liebsten alles und jeden noch in das Lastenheft hineinschreiben möchte. Meine Antwort: „Nein.“

Der große Trick, die große Kunst ist, zu streichen. So lange zu kürzen, bis wir merken: Wenn wir diesen Teil jetzt löschen – diesen Satz, dieses Kapitel, dieses Unterkapitel –, verändern wir den Inhalt entscheidend. Für uns Ingenieure ist es ganz normal, zu viel zu dokumentieren, zu viel hineinzuschreiben – allerdings führt das nicht zu einem Mehrwert im Verständnis, ganz im Gegenteil: Meist führt es nur zu Unklarheiten.

Hier helfen mir die Inhalte der Phasen 1.5 bis 1.8, also die Peer-Reviews, die ich parallel mache und in denen ich ebenso die Frage stelle: „Muss das da rein? Kann man das nicht komprimieren, fokussieren, rausschmeißen?“.

Dieses „weniger ist mehr“ ist ganz wichtig, wenn schließlich Punkt 1.0 in der Welt ist und darauf basierend vielleicht andere, neue Kollegen mit der Umsetzung konfrontiert werden.

Tipp 3: Kein Pseudo-Code!

Pseudo-Code kommt primär im Embedded-Software-Umfeld vor – und gehört dort auch hin. Ich hingegen schreibe keinen Pseudo-Code, denn dies ist eine Lösungsbeschreibung, auf der basierend vor allem Softwareentwickler Quellcodes umsetzen sollen.

Ich mache aber in einem Lastenheft für ein komplexes technisches System auf der obersten Ebene keine Lösungsbeschreibung, die irgendwo ganz unten und viel später eine Embedded-Software im Design umzusetzen hat.

Wenn ich ein Verhalten beschreiben muss, kann ich das wunderbar mit anderen Mitteln machen, aber eben nicht mit Pseudo-Code. Das Gleiche gilt als Bild übrigens auch für die Elektronik und für die Konstruktion.

 

Hier geht es zu den nächsten vier der sieben Tipps

Was gehört ins Lastenheft?

Was gehört ins Lastenheft und was nicht? In diesem Artikel gehe ich darauf ein, welchen Zweck ein Lastenheft hat und was ins Lastenheft für ein technisches System gehört.

Weiterlesen

Was ist eigentlich ein Lastenheft?

Wie immer gibt es dazu auch eine wunderschöne Norm, und gemäß der DIN 69901-5 enthält das Lastenheft “die vom Auftraggeber festgelegte Gesamtheit der Anforderung an die Lieferung und Leistungen eines Auftragnehmers innerhalb eines Auftrags”.

So kann man es bezeichnen. Ich würde einfach das Ganze mal ein bisschen pragmatischer sehen: Das Lastenheft beschreibt in der Regel, womit und wofür etwas gemacht werden soll. Oder bezogen auf meine Schulungen und Trainings: Es ist am Ende des Tages das “Wünsch-dir-was” des Kunden aus seiner Sicht.

Weiterlesen