Lastenheft 2.0 – Geheimzutat für erfolgreiche IT-Projekte

Während alle Welt von der Digitalisierung ganzer Geschäftsmodelle fasziniert ist, spielen sich bei der Softwareeinführung in Unternehmen immer noch Dramen ab. Nur 28 Prozent der CRM-Nutzer würden ihr CRM-System weiterempfehlen. Doch nicht nur die gelieferte Qualität enttäuscht, schon während der Implementierung laufen Kosten und Projektdauer oftmals aus dem Ruder. Dabei sollten dank agiler Methodik IT-Projekte endlich rund laufen. Einen Lösungsansatz bietet das Lastenheft 2.0.

foto cc0 pixabay geralt frau sonne baum

foto cc0

Ist es Ihnen beim Frisör auch schon mal passiert, dass das Ergebnis anders als gewünscht ausgesehen hat? Wenn es selbst bei so einfachen Rahmenbedingungen zu Missverständnissen bezüglich Anforderungen kommen kann, steigt diese Gefahr bei komplexen IT-Projekten immens an.

Im früher verbreiteten Wasserfallmodell der Softwareentwicklung wurden daher sämtliche Anforderungen in einem Lastenheft vorab detailliert spezifiziert. Die Umsetzung der Anforderungen erfolgte statisch auf Basis des Lastenhefts – und landete aus Anwendersicht nicht selten weit entfernt von der Ursprungsidee. Agile Entwicklung stellt den Anwender in den Mittelpunkt und impliziert, dass zu Beginn der Entwicklung nicht alle Funktionalitäten vollumfänglich beschrieben sind, sondern zur Projektlaufzeit iterativ und mit Anwender-Feedback erarbeitet werden. Mit der Verbreitung agiler Entwicklung stirbt das Lastenheft aus. Dabei stammt der agile Ansatz aus der Neuentwicklung von Software. Die Realität in den Unternehmen sieht anders aus, denn IT-Projekte sind mehrheitlich keine Neuentwicklung, sondern schlichtes Customizing von Standardsoftware. Diese bringt eine Reihe von Vorteilen mit sich. Ein definierter Funktionsumfang steht bereits »out of the Box« zur Verfügung und muss folglich nicht neu gedacht werden. Anwender profitieren außerdem von der Weiterentwicklung des Tools und den einfließenden Best Practices anderer Kunden.

Standardsoftware ist nur begrenzt agil

Der wesentliche Unterschied zur Neuentwicklung liegt darin, dass Standardsoftware einen unveränderlichen Kern und verbindliche sowie limitierte Customizing-Möglichkeiten beinhaltet. Neben der reinen Parametrisierung ist in der Regel eine Nutzung oder Entwicklung von Add-ons beziehungsweise Zusatzmodulen möglich, um funktionale Erweiterungen des Kerns zu realisieren.

Jede Standardsoftware bringt unterschiedliche Stärken und Schwächen mit. Entscheidend für den Nutzwert ist der Kontext des konkret zu betrachtenden Anwendungsfalls.

Um also die richtige Standardsoftware auszuwählen zu können, müssen grundlegende Anforderungen vorher spezifiziert sein. Die Gefahr, spezifische Anforderungen im Laufe der Implementierung nicht oder nur mit übermäßigem Aufwand umsetzen zu können, ist groß. Und das kann teuer werden:

  • Möglicherweise lassen sich Anforderungen nur mit aufwändiger Zusatzprogrammierung oder kostenpflichtigen Zusatzmodulen erzielen
  • Zusatzprogrammierung ist nicht nur kostenintensiv in der Implementierung, sondern führt zu zusätzlichen laufenden Folgekosten bei der Wartung und Release-Wechseln
  • Zusatzprogrammierung zerstört oftmals den vorgesehenen Workflow und führt zu einer fragmentierten Benutzerführung
  • Schlechte Benutzerführung resultiert in mangelnder Akzeptanz der Anwender
  • Zusätzlich steigt das Fehlerpotenzial
  • Im Worst-Case ist es erforderlich, den Software-Kern zu ändern (seriöse Anbieter werden dies ablehnen, denn damit wird die Release-Fähigkeit und Wartbarkeit zerstört)

Die falsche Software auszuwählen ist schmerzhaft. Es gilt also sicherzustellen, dass eine Standardsoftware möglichst viele Ihrer Anforderungen bereits in der Grundfassung erfüllt. Ferner möchte man frühzeitig erkennen, dass auch darüberhinausgehende Anforderungen umgesetzt werden können – unter Berücksichtigung uneingeschränkter Benutzerfreundlichkeit und vertretbarer Kosten. Um das zu erreichen, ist wiederum eine detaillierte Beschreibung Ihrer Prozesse und der daraus abgeleiteten Anforderungen erforderlich. Für die fundierte Auswahl einer geeigneten Standardsoftware wird also ein Lastenheft benötigt. Und hier beißt sich die Katze in den Schwanz, denn bedeutet dies nicht eine Rückkehr zum klassischen Wasserfall?

Das Lastenheft neu denken

Da agile Methodik nicht mit einem klassischen Lastenheft übereinkommt, man aber nicht auf die Vorteile der agilen Entwicklung verzichten möchte, muss sich das Lastenheft den neuen Rahmenbedingungen anpassen.

Es muss drei Herausforderungen meistern, und zwar

1.)     detailliert sein, weil das Customizing nicht aufheben kann, was der Standard nicht kann

2.)     mit Freiheitsgraden versehen sein, um die Kreativität in der Umsetzung zu erhalten

3.)     so geschrieben sein, dass Sie und der spätere Implementierer das gleiche Verständnis der Anforderungen erhalten.

Wie sieht ein Lastenheft 2.0 aus? Mit Lastenheft verbindet man oft endlose Tabellen mit detaillierten Beschreibungen, bis hin zum einzelnen Button. Das Lastenheft 2.0 verwendet zur Anforderungsbeschreibung für einen nicht beteiligten Fach-Experten verständlichen Fließtext in Form von User Storys. User Storys werden aus Sicht des späteren Anwenders geschrieben. Sie beschreiben detailliert, wie der Prozess abläuft und welche Unterstützung die Software dabei bieten muss. Unterschieden wird dabei zwischen manuellen, teilautomatisierten und vollautomatisierten Abläufen. Auch die Interaktion mit anderen Softwaresystemen, sprich Schnittstellen, kann so beschrieben werden.

So entstehen die User Storys zu Ihren Prozessen, etwa dem Kampagnenmanagement, der Angebotserstellung oder der Bearbeitung von Kundenanliegen. Diese bilden die Kapitel des Lastenhefts 2.0.

Wie aber entstehen die User Storys? In User Storys fließen mehrere Elemente ein, insbesondere

  • Erfahrungen aus bestehenden Prozessen,
  • Wünsche an den künftigen Prozess,
  • Best Practices aus anderen Unternehmen, Abteilungen oder Softwaretools.

In der Regel werden die groben Abläufe in Workshops definiert und dann von einzelnen Fachexperten detailliert ausgearbeitet und der Gruppe zur Freigabe zurückgespielt. Die IT unterstützt dabei als Sparringspartner und mit Informationen zu Bestandsystemen. Ergänzend können Visualisierungen in Form von Mock-ups helfen, sich das spätere Tool besser vorzustellen.

Diese Vorgehensweise hat sich in der Praxis bewährt, denn die späteren Anwender sind stark involviert und finden sich in den User Storys wider. So können sie diese mit gutem Gewissen freigeben.

Es kann ergänzend sinnvoll sein, sich einige Tools anzuschauen und sich inspirieren zu lassen. Dabei sollte man sich nicht von Hochglanzfeatures blenden lassen, sondern immer den individuellen Nutzen für den eigenen Anwendungsfall genau bewerten. Ein Softwareanbieter kann Ihnen nicht abnehmen, sich selbst Gedanken zu Ihren Prozessen zu machen.

Warum sich das Lastenheft 2.0 doppelt bezahlt macht

Aus dem Lastenheft 2.0 lässt sich das Pflichtenheft 2.0 ableiten. Dabei wird das herstellerneutrale Lastenheft in Workshops mit dem designierten Implementierungspartner zum herstellerspezifischen verbindlichen Pflichtenheft umgeschrieben. Je geringer die erforderlichen Änderungen sind, desto näher kann die Umsetzung am Standard erfolgen. Auch in diesem Prozess bleibt ein gemeinsames Verständnis des Dokuments erhalten, so dass die Risiken in der Umsetzung minimiert werden. Konflikte bezüglich der Umsetzbarkeit der Anforderungen werden schon hier ausgetragen – im Zweifelsfall kann noch der Ausstieg erfolgen. Die verbleibenden Risiken der Umsetzung sollten im Projektvertrag adressiert werden, auf den im Rahmen dieses Beitrags nicht näher eingegangen werden kann.

Weiterer Vorteil: Das Pflichtenheft dient auch als Basis für die Implementierung. Denn für die agile Entwicklung sind als Basis User Storys ohnehin erforderlich und liegen somit schon vor. Der Arbeits- und Kostenaufwand für das Lastenheft 2.0 macht sich somit in der Implementierungsphase bezahlt.

Fazit

Wer ohne detailliertes Lastenheft eine Standardsoftware auswählt, riskiert hohe Folgenkosten, erhöhten Zeitaufwand und mangelnde Nutzerakzeptanz. Klassische Lastenhefte sind nicht geeignet für heutige agile Einführungsmethodik. Hier hilft das Lastenheft 2.0, das aus User Storys besteht und nicht nur die Grundlage für die Softwareauswahl, sondern auch für die spätere erfolgreiche Implementierung bildet.

Ulf Loetschert, Berater bei buw consulting und Experte für die Auswahl und Implementierung von CRM-Systemen

https://buw-consulting.com/crm/


Staugefahr bei Projekten zur digitalen Kundenkommunikation bei privaten Banken

Welche Branchen verschwenden das meiste Geld in Projekten?

Warum scheitern IT-Projekte?

Die volkswirtschaftliche Bedeutung von Projekten ist enorm

Budgetkontrolle ist auch in agilen Projekten möglich

Ab in den Urlaub: So laufen Projekte auch in Abwesenheit rund

Projekte agil und zuverlässig umsetzen mit Ideen aus Lean und Critical Chain

 

Schreiben Sie einen Kommentar