Requirements Engineering im Festpreiskontext - Der Scope wird verhandelt, das Budget gemanagt

Festpreis - ein Wort, bei dem Auftragnehmerinnen und Auftragnehmer von Softwareprojekten gerne zusammenzucken. Vor allem, wenn es im Zusammenhang mit agiler Softwareentwicklung genannt wird. In der Theorie muss der Scope zum Zeitpunkt der Preisverhandlung klar definiert sein. In der Praxis ist zwar das Kernziel definiert, aber die Anforderungen sind zu diesem frühen Zeitpunkt selten vollständig spezifiziert und stabil, was im agilen Vorgehen ja auch bewusst so gewählt ist. Dies führt wiederum zu unterschiedlichen Interpretationen des Umfangs und hohen Schätzunsicherheiten, die im schlimmsten Fall zu einem Scheitern des Projekts führen können. Das Budget spielt aber nicht nur in Festpreisprojekten eine zentrale Rolle, sondern in jedem Softwareprojekt, unabhängig von der gewählten Vertragsform.

In diesem Blog-Beitrag beschäftigen wir uns mit dem Begriff Scope und dem Erwartungsmanagement. Außerdem beleuchten wir Methoden des Requirements Engineering zur Einhaltung eines vorgegebenen Budgets sowie Lösungsansätze für Projekte, in denen das Budget aus dem Ruder zu laufen droht.

Erfolgsfaktor Kommunikation

Eine der größten Fehlerquellen und die Hauptursache für notwendige Anforderungsänderungen sind Missverständnisse in der Kommunikation. Uneinigkeit und unterschiedliche Interpretationen des Projektziels können zu Budgetüberschreitungen, Terminverschiebungen und allgemeiner Unzufriedenheit führen.

Mit der Anzahl der Projektbeteiligten steigt auch die Anzahl der Kommunikationsschnittstellen und damit die Erfolgsrisiken.

Der Requirements Engineer nimmt in Softwareprojekten eine zentrale Rolle ein und bildet die Schnittstelle zwischen allen Stakeholdern. Eine seiner Hauptaufgaben ist es daher, Wissen und Entscheidungen in den verschiedenen Stakeholdergruppen zu verteilen und die Kommunikation zwischen den Gruppen zu fördern, um Interpretationsspielräume zu minimieren.

Erwartungsmanagement

Erwartungen und deren Erfüllung sind eine wesentliche Grundlage für eine effektive und gute Zusammenarbeit aller Stakeholder. Dabei zielt die Erfüllung von Erwartungen auf Zufriedenheit, die Übererfüllung auf Überraschung. Untererfüllte Erwartungen führen zu mehr oder weniger ausgeprägter Unzufriedenheit beim Kunden.

Im Projektkontext sind die Erwartungen mit dem Scope gleichzusetzen. Je früher dieser definiert und umfassend kommuniziert wird, desto besser kann die Erwartungshaltung des Kunden gesteuert werden. Die regelmäßige Überprüfung des zu Beginn dokumentierten Scopes und ein darauf abgestimmtes Vorgehen sind kritische Erfolgsfaktoren für das Gelingen komplexer IT-Projekte.

Scope verhandeln und Budget managen

Nach dem PMBOK-Guide (Projektmanagementstandard) des Project Management Institute ist der Scope „die Arbeit, die geleistet werden muss, um ein Produkt, eine Dienstleistung oder ein Ergebnis mit den spezifizierten Merkmalen und Funktionen zu liefern“. Diese Definition steht jedoch im Gegensatz zur agilen Softwareentwicklung, bei der der Scope nur vage beschrieben und nicht in konkrete Anforderungen (Funktionen) heruntergebrochen wird. Wie kann ein Requirements Engineer unter diesen Bedingungen den Scope so managen, dass er in das vorgegebene Budget passt? Im Grunde gar nicht, denn was nicht definiert ist, kann auch nicht gemanagt werden!

Ein frühzeitig definierter und klar abgegrenzter Scope ( zum Beispiel über Akzeptanz- und Abnahmekriterien), der in das vorgegebene Budget passt, ist daher Grundvoraussetzung für ein erfolgreiches Festpreisprojekt. Der RE muss daher zunächst gemeinsam mit dem Auftraggeber einen realistischen Scope definieren. Andernfalls kommt es zu einer realitätsfernen Zeitplanung und Budgetüberschreitung. In der Folge gerät das Projekt in Schieflage.

Im Gegensatz zum Scope ist das Budget jedoch genau definiert und kann außerhalb von Change Requests nicht verhandelt werden. Zusammenfassend kann man also sagen: Der Scope wird verhandelt, das Budget wird gemanagt.

Feature-Budget-Mapping

Neben dem unklaren Scope gibt es weitere Gründe für ein ausuferndes Budget:

• Unstrukturierte oder unvollständige Anforderungsdokumentation
• Zunahme neuer Anforderungen oder Anforderungsänderungen
• Golden Handshakes", das heißt unwirtschaftliche Anforderungen, die viel Budget verbrauchen, aber wenig Mehrwert liefern
• Keine Berücksichtigung des ursprünglichen Angebots inkl. Schätzung nach Projektstart

Wie schaffen wir es, den definierten Scope mit dem vorgegebenen Budget in Einklang zu bringen?

Es gibt verschiedene Möglichkeiten, das Budget im Auge zu behalten. Eine von adesso entwickelte Methode ist das Feature-Budget-Mapping. Analog zum agilen Arbeiten wird das Budget in kleine, überschaubare Einheiten zerlegt und auf die zu realisierenden Features, Epics oder ähnliches verteilt. Dieser Budgettopf wird wiederum auf die darunter liegenden Stories verteilt, die absteigend nach Priorität sortiert sind. Ist das Budget aufgebraucht, können keine weiteren Stories für dieses Feature entwickelt werden.

Es darf kein Budget aus anderen Töpfen verwendet werden, da sonst für später zu entwickelnde Merkmale zu wenig Budget zur Verfügung steht und der Nutzen der Methode geschmälert wird. Es ist aber durchaus erlaubt, einen Puffer zu bilden, falls ein Feature mit weniger Aufwand entwickelt wurde als ursprünglich geschätzt.

Durch die Anwendung des Feature-Budget-Mapping kann frühzeitig erkannt werden, wenn ein Feature aufwändiger und damit teurer wird als ursprünglich angenommen. Ein rechtzeitiges Gegensteuern wird möglich.

Design to Budget

Grundsätzlich sollte immer der MVP-Gedanke gelebt und goldene Wasserhähne vermieden werden. Ein Minimum Viable Product (MVP) ist eine erste funktionsfähige Version eines Produktes, die zunächst nur die wichtigsten Features enthält.

Mit gezielten Fragen kann herausgefunden werden, wie relevant eine Funktion ist:

• Wie häufig wird die Funktion benötigt?
• Wie viele Benutzer verwenden die Funktion?
• Gibt es einen Workaround und wenn ja, mit welchem Aufwand und Risiko ist dieser verbunden?

Stellt sich im weiteren Projektverlauf heraus, dass zusätzliche Anforderungen oder Anforderungsänderungen notwendig sind, muss dies aufwandsneutral erfolgen. Es muss geklärt werden, was dafür gestrichen oder ausgetauscht werden kann. Andernfalls muss der Kunde einen Change Request stellen und diesen mit Budget hinterlegen.

Die 80-Prozent-Lösung

Was aber tun, wenn man feststellt, dass eine Funktion teurer wird als veranschlagt?

Zunächst muss die Situation transparent an die Projektleitung kommuniziert werden. In Abstimmung mit dem Entwicklungsteam und dem Fachbereich kann dann ein Lösungsvorschlag erarbeitet werden. Denn in erster Linie müssen die Ziele des Kunden erfüllt werden, nicht unbedingt die konkreten Anforderungen. Das Team kann also eine kostengünstigere Lösung vorschlagen, die das Ziel ebenfalls erfüllt.

Dies kann nach dem Pareto-Prinzip (auch 80-20-Regel genannt) erfolgen, das besagt, dass 80 Prozent der Ergebnisse mit 20 Prozent des Gesamtaufwandes erreicht werden. Die verbleibenden 20 Prozent verursachen mit 80 Prozent den größten Teil des Gesamtaufwandes und weisen auf Ineffizienz hin. Mit Hilfe dieses Prinzips können Anforderungen identifiziert werden, deren Umsetzung aufgrund mangelnder Wirtschaftlichkeit verschoben oder unterlassen werden kann.

Auf Basis der so erarbeiteten „80-Prozent-Lösung“ und des ursprünglich vereinbarten Scopes werden dann die Verhandlungen mit dem Kunden geführt.

Analyse-Sprint

Wenn das Projekt den geplanten Zeit- und Kostenrahmen massiv überschreitet, ist eine Stabilisierung des Anforderungsrahmens und eine angepasste Neuplanung unumgänglich. Die Umsetzung wird zugunsten einer intensiven Analysephase unterbrochen. Im agilen Vorgehen spricht man von einem „Analyse-Sprint“. Ziel dieses Sprints ist es, einen stabilen Rahmen zu schaffen, der die Grenzen der noch zu implementierenden Funktionalitäten absteckt.

In kleinen, cross-funktionalen Teams werden die offenen Anforderungen so analysiert und detailliert, dass Umsetzungsrisiken und Grenzen klar erkennbar sind. Dabei wird auch die Priorität kritisch hinterfragt und mögliche Streichkandidaten identifiziert. Anschließend wird für jede dieser Anforderungen ein Umsetzungsaufwand abgeschätzt, der auch den Risikoaufwand beinhaltet. Auf dieser Basis wird in der letzten Phase des Analysesprints ein neuer Projektumfang vereinbart. Anschließend wird die Entwicklung mit einem angepassten agilen Ansatz fortgesetzt.

Einen tieferen Einblick, wie man mittels Analyse-Sprint havarierte Projekte stabilisieren kann, bekommt ihr in diesem Beitrag zum Thema „Stabilisierung von havarierten, agilen Projekten“.

Fazit

Auch wenn einige der hier genannten Aufgaben auf den ersten Blick nicht in den Zuständigkeitsbereich des Requirements Engineers fallen, ist er dennoch involviert. Er ist die zentrale Schnittstelle im Projekt, kennt den aktuellen Status oft besser als die Projektleitung und kann Abweichungen vom Plan frühzeitig adressieren. Um Deltas überhaupt erkennen zu können, muss eine Basis, in diesem Fall die Kundenerwartung in Form des Scopes, frühzeitig definiert und strukturiert dokumentiert werden. Während der Projektlaufzeit ist es essentiell, das Budget im Auge zu behalten und Aufwandsprognosen mittels geeigneter Methoden wie dem Feature-Budget-Mapping zu erstellen. Zeichnet sich ein Budgetengpass ab, muss rechtzeitig gegengesteuert werden. Mögliche Vorgehensweisen sind das Aushandeln einer 80-Prozent-Lösung oder die Durchführung eines Analysesprints. Grundsätzlich sollte der MVP-Gedanke konsequent gelebt werden, um nicht mehr zu entwickeln als notwendig (“Design to Budget“). Alle hier genannten Punkte gelten insbesondere im Festpreiskontext, können aber auch auf andere Projektkonstellationen adaptiert werden.

Anforderungen sind euer Steckenpferd und ihr möchtet euch zu diesem Thema austauschen? Dann meldet euch gerne bei uns. Ihr erreicht uns unter ellen.volkert@adesso.de und sarah.roehe@adesso.de.