Tschüss Lastenheft

Digitale Transformation ist eine dynamische Angelegenheit. Geschwindigkeit und Flexibilität sind entscheidende Erfolgsfaktoren. Die Umsetzung von Transformationsprojekten muss agil sein – und doch sind nach wie vor Feature-bezogene Listen und Lastenhefte bei der Auswahl digitaler Lösungen und Plattformen weit verbreitet. Die Systemauswahl auf der Basis von Lastenheften stammt aus der Zeit plangetriebenen Projektvorgehens (– oft als Wasserfallmodell bezeichnet) wo Anforderungen, Planung und Umsetzung weitgehend im Voraus festgelegt wurden. Oft mit überschaubarem Erfolg.

Dieses tradierte Vorgehen stößt heutzutage, bei agilen Projekten, nicht nur an seine Grenzen, es konterkariert geradezu den agilen Ansatz. Warum? Lastenhefte haben eine starre Struktur. In ihnen werden Anforderungen, oft detailliert, im Voraus definiert. Damit wird der Fokus auf spezifische Funktionen gelegt, ohne die eigentlichen Geschäftsziele vor allem aber die notwendige Flexibilität zu berücksichtigen.

Lastenhefte sind ungeeignet

Es gibt genügend Argumente warum Feature-Listen und Lastenhefte für die Systemauswahl in agilen Projekte ungeeignet sind. Hier die, aus meiner Sicht, (Ge-)Wichtigsten.

• Fehlende Flexibilität: Agile Projekte leben von dynamischen, iterativen Anpassungen. Ein detailliertes Lastenheft legt die Anforderungen viel zu früh fest und macht spätere Änderungen, die sich aus neuen Erkenntnissen oder sich wandelnden Bedürfnissen ergeben nur mit großem zusätzlichem Aufwand möglich..

• Fokus auf Funktionen statt auf Wert: Eine Feature-Liste beschreibt, was eine Software leisten soll, aber nicht, warum bestimmte Funktionen wichtig sind. Unternehmen laufen Gefahr, Lösungen auszuwählen, die zwar viele Features haben, aber am Ende nicht die eigentlichen Geschäftsprobleme lösen.

• Hoher Aufwand ohne echten Mehrwert: Das Erstellen eines Lastenhefts ist zeitaufwendig, und oft sind viele der erfassten Anforderungen zum Zeitpunkt der Umsetzung nicht mehr relevant oder müssen im Rahmen der Transformation ohnehin überarbeitet werden.

• Eingeschränkte Innovationsfähigkeit: Innovation entsteht durch Experimente, Feedback und kontinuierliche Verbesserung. Ein Lastenheft zementiert einen Weg und behindert damit diesen Prozess, weil wenig Raum für explorative Entwicklungen existiert.

Ziele und Nutzen bestimmen die Auswahl

So weit, so gut. Aber wie sehen die Alternativen aus? Hierzu vielleicht vorab eine kurze Erklärung im Kontext der Agilität. Ein agiler Ansatz konzentriert sich auf Ziele, Nutzen und iterative Entwicklung. Daher sollten diese Faktoren auch bei der Systemauswahl zum Tragen kommen. Die Nachfolgenden Prinzipien und Vorgehensweisen haben sich in der Praxis bewährt und sind pragmatisch umsetzbar.

• Value-based Selection: Statt Feature-Listen werden die übergeordneten Geschäftsziele definiert. Welche Ziele sollen unterstützt, welche Probleme sollen gelöst werden? Welchen Mehrwert soll das System bieten?

• Proof of Concept (PoC) und Pilotprojekte: Systeme werden nicht nur theoretisch evaluiert, sondern in einem kleinen, realen Szenario getestet. Dadurch lassen sich Stärken und Schwächen frühzeitig erkennen.

• User Stories statt Feature-Listen: Anstatt Funktionen zu definieren, wird aus der Perspektive der Nutzer beschrieben, welche Bedürfnisse sie haben und wie das System sie unterstützen soll.

• Iterative Auswahl und Anpassung: Statt eine endgültige Entscheidung auf Basis eines Lastenhefts zu treffen, wird das System schrittweise eingeführt und mit einsprechendem Feedback kontinuierlich verbessert.

• 
  

Durch diese Ansätze fokussiert sich die Softwareauswahl auf echten Mehrwert und ermöglicht es, schnell reale Erkenntnisse zu gewinnen und auf Veränderungen flexibel zu reagieren – genau das, was ein digitales Transformationsprojekt braucht.