Beim Lastenheft werden sehr häufig gravierende Fehler gemacht, die zu drastischen finanziellen und zeitlichen Konsequenzen im Projekt führen. Dabei sind einige dieser Fehler einfach vermeidbar, wenn sie nur bekannt wären.
In diesem Bericht finden Sie die destillierten Ergebnisse aus über 10 Jahren Erfahrung im Troubleshooting, über 30 durchgeführten Lastenheft Assessments und über 40 Q&A Speaking Gigs bei Hidden Champions in der Industrie. Ich beschreibe Ihnen hier zwei der sieben Fehler, die beim Erstellen eines Lastenheftes am häufigsten gemacht werden. Wenn Sie alle sieben Fehler nachlesen möchten, laden Sie sich gerne meinen Praxis-Report herunter.
Fehler #1: Pimp my Excel
Immer wieder melden sich Leser, die in ihren Unternehmen die nötigen Anforderungen und Spezifikationen für Projekte schaffen, aber kein Requirements-Engineering-Werkzeug haben. Entsprechend versuchen sie, mit Excel zu arbeiten.
Viele, gerade kleine und mittelständische Firmen haben für ihre Projekte oftmals keine aufwändigen und großen Requirements-Engineering-Tools, wie man sie aus komplexen Projekten kennt.
Diese Tools sind in der Regel recht teuer, oft sehr vielschichtig und relativ komplex zu bedienen. Also nutzen viele Unternehmen – beinahe “traditionell” – Excel als Werkzeug.
Hinzu kommt häufig, dass die fachliche Ausbildung in Sachen Requirements Engineering fehlt: Viele wissen schlicht nicht, was es bedeutet und wie relevant es ist. Entsprechend nehmen sie einfach das, was sie haben – in der Regel Microsoft Office – und versuchen, ihre Requirements damit zusammenzubauen.
Doch Excel geht an dieser Stelle ganz schnell nach hinten los.
- Das Einbinden von Bildern mit einer Fixierung im Dokument ist so nicht vorgesehen. Somit verrutschen die Bilder gerne, wenn neue Zeilen eingefügt werden.
- Die Schreibgeschwindigkeit ist 70% langsamer im Vergleich zu einem Textverarbeitungsprogramm.
- Eine Vergabe von ID muss manuell erfolgen und gepflegt werden.
Die Möglichkeit, solche manuellen Aufgaben in Excel mit VBA zu programmieren, ist verlockend. Leider führt das zu einem Toolmissbrauch, bei dem gerne mal 2000 Mannstunden versenkt werden, ohne vorherige Anforderungsaufnahme an das programmierte Anforderungswerkzeug und mit ungetestetem Code im Praxiseinsatz.
Fehler #2: Vermischte Anforderungen
In Projekten ist häufig nicht klar, was der Unterschied zwischen Lastenheften und Pflichtenheften ist – und warum beide in einem Projekt erstellt werden sollten.
Im extremsten Fall wird versucht, beide zu vereinen, sodass ein Lastenheft gleichzeitig auch das Pflichtenheft darstellen soll. In einem Fall haben wir 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.
Kein Apfel, keine Orange: Vermischung von Lasten- und Pflichtenheft
Ein Lastenheft ist eine technische Beschreibung eines Systems. Damit beschreibt es die Anforderung an ein System, die nach erfolgreichem Abschluss eines Entwicklungsprojektes übrig bleiben. Das bedeutet, in einem Lastenheft beschreibe ich nicht die Anforderung an ein Projekt. Anforderungen wie beispielsweise Termine, Entwicklungsbudget, Ansprechpartner, Prozessvorgaben usw. gehören zu einem Projekt. Sie sind solange wichtig, wie das Entwicklungsprojekt läuft. Ist das Entwicklungsprojekt abgeschlossen, sind diese Anforderungen irrelevant. Sie gehören nicht in ein Lastenheft.
Leider führt diese Vermischung der Anforderungen zu unbrauchbaren und widersprüchlichen Spezifikationen, auf deren Basis eine Aufwandschätzung oder Projektplanung nicht möglich ist.
Möchten Sie wissen, welche fünf weiteren Fehler in der Praxis beim Erarbeiten eines Lastenheftes gemacht werden? Dann laden Sie sich meinen Praxis-Report hier herunter.
