Effektives Requirements Engineering in Festpreis- und Festumfang-Projekten

Wenn ihr als Dienstleister für Unternehmen arbeitet, die ihre Produktentwicklung auslagern möchten, begegnet euch möglicherweise der eine oder andere Kunde, der von Anfang an einen festen Satz an Anforderungen mitbringt und bereit ist, sofort über einen Festpreis zu verhandeln. In einer solchen Situation ist es entscheidend, die Lage so zu handhaben, dass der Kunde vollständig zufrieden ist und ihr gleichzeitig im Budget bleibt.

Dieser Blogbeitrag soll sowohl als Einführung als auch als Sammlung von Empfehlungen dienen, die euch helfen, solche Projekte und Kunden zu managen – unabhängig davon, ob ihr als Requirements Engineer, Business Analyst oder Projektmanager tätig seid. Auf der anderen Seite soll er Kunden mit etwas Einblick unterstützen, wie Festpreisprojekte am besten gehandhabt werden, damit sie effektiver zusammenarbeiten können.

Bevor wir einsteigen, ist eine kurze Einführung in das Thema erforderlich.

Was bedeutet Festpreis?

Ein Festpreis-Softwareprojekt ist eine Art Vertragsvereinbarung, bei der Auftraggeber und Dienstleister vor Beginn jeglicher Arbeit einen festen Preis für das gesamte Projekt vereinbaren. Dieser Preis bleibt konstant, unabhängig vom tatsächlich aufgewendeten Zeit- oder Ressourcenaufwand zur Fertigstellung des Projekts. Umfang, Liefergegenstände und Zeitpläne werden im Voraus klar definiert und vereinbart.

Vor- und Nachteile

Es gibt mehrere Vorteile und Risiken beim Eingehen eines solchen Projekts:

Vorteile

• Der Kunde definiert den Umfang im Voraus und weiß genau, was er erhalten wird
• Der Kunde kennt den Lieferzeitpunkt und kann seine Arbeit darauf ausrichten
• Bei einer genauen Schätzung weiß der Dienstleister, wie viele Ressourcen er einplanen muss
• Einfache, wenig komplexe Projekte mit kurzem Zeitrahmen sind eine gute Option, da sie helfen, den Fokus zu behalten und das Endziel zu erreichen

Nachteile

• Lieferung und Wert der Software hängen vollständig von der Qualität der vordefinierten Anforderungen und Liefergegenstandsbeschreibungen ab
• Wenig Spielraum für zusätzliche Funktionalitäten, die während der Entwicklung entdeckt werden
• Festpreisprojekte werden meist mit einem Wasserfallansatz abgewickelt, der sich – insbesondere für den Kunden – als äußerst riskant erwiesen hat
• Kostenschätzungen basieren vollständig auf einem anfänglichen Verständnis der Kundenbedürfnisse; während der Entwicklung kann sich dieses Verständnis weiterentwickeln und damit mehr Aufwand erfordern
• Verzögerungen haben einen Kaskadeneffekt: Wird die Abnahme eines Liefergegenstands zu einem bestimmten Zeitpunkt nicht erreicht, kann sich der gesamte Projektzeitplan verschieben
• Der feste Umfang erschwert die Anpassung an Änderungen im Geschäftsumfeld
• Großangelegte Projekte sind mit zu vielen Risiken verbunden

Nach Betrachtung all dieser Vor- und Nachteile lassen sich mehrere Schritte ableiten, um sie gut zu handhaben.

Projektlebenszyklus

Im Folgenden finden sich mehrere Empfehlungen, was ihr tun könnt, um das Projektumfeld im Projektlebenszyklus zu unterstützen.

Schätzungen

Wie bei allen Softwareprojekten bedeutet eine genaue Schätzung eine erfolgreiche Lieferung, einen zufriedenen Kunden und ein Projekt, das sich im geplanten Budget bewegt.

Je nach Größe des Umfangs kann die Schätzgenauigkeit jedoch abnehmen, weshalb Puffer eingeführt werden müssen, um das wachsende Risiko abzufedern.

Um das zu managen, können folgende Maßnahmen ergriffen werden:

• Aufteilen des Umfangs in mehrere kleinere Teilumfänge, die leichter gehandhabt, geschätzt und geliefert werden können
• Trennung der Kundenanforderungen in Risikokategorien sowie entweder Ausschluss oder engmaschiges Management von Hochrisikoanforderungen
• Falls der Umfang zu groß ist und eine Aufteilung nicht möglich ist, kann ein zusätzliches Budget für Design und/oder eine eingehende Anforderungsanalyse verhandelt werden, um ein vertieftes Verständnis des Umfangs für eine genauere Schätzung zu erlangen
• Wenn keines der oben Genannten möglich ist, sollte dem Kunden kommuniziert werden, dass ein Sicherheitspuffer zur Bewältigung aller unvorhergesehenen Risiken angewendet werden muss

Eine erfolgreiche Schätzung ist eine, bei der ihr als Requirements Engineer das Gefühl habt, ein außerordentlich gutes Verständnis des Umfangs zu haben, und bei der sowohl ihr als auch der Kunde mit dem Budget zufrieden sind.

Zusätzlich zum Verständnis des Umfangs sollte auch der Aufwand für folgende Aufgaben berücksichtigt werden:

• Projektaufbau
• Testing
• Meetings
• Dokumentation
• Klärungen, Verhandlungen, Fehler- und Anforderungsanalyse

Nach unserer Erfahrung beträgt dies üblicherweise 30–50 % zusätzlicher Zeit, abhängig vom Kunden.

Designphase

Sobald der Kunde der Kostenschätzung des Arbeitsumfangs zugestimmt hat, kann das Design beginnen.

Während der Designphase ist es neben dem üblichen Designprozess aus Klärung, Backlog-Planung und User-Story-Vorbereitung entscheidend, dass der RE dokumentiert und klar kommuniziert, was der Kunde nicht erhalten wird. Ebenso wichtig ist es, die Zustimmung des Kunden dazu festzuhalten. Das macht die Lieferung für beide Seiten exponentiell einfacher.

Da die vom Kunden erhaltenen Anforderungen die Eckpfeiler des Designs sind, ist ein wesentlicher Teil der Designphase die Sicherstellung eines gemeinsamen Verständnisses darüber, was diese Anforderungen bedeuten – üblicherweise in dokumentierter Form, um potenzielle Missverständnisse weiter zu reduzieren und den Umfang und das Design zu konkretisieren.

Je nach Qualität der ursprünglich erstellten Anforderungen empfiehlt sich ein Prozess des Umschreibens, der Nomenklaturangleichung und der Verfeinerung von Akzeptanzkriterien.

Der Kunde verfügt möglicherweise über einen Product Owner, der die Planung unterstützen kann – oder auch nicht. Der Vorteil von Festpreis- und Festumfang-Projekten besteht darin, dass die Implementierungsreihenfolge dem Kunden normalerweise nicht aufgezwungen wird. Damit besteht Spielraum für eine Priorisierung nicht nach Wert (da alle Anforderungen im Rahmen des Vertrags gleich wertvoll sind), sondern nach logischen, technischen Abhängigkeiten, um die Implementierung so reibungslos wie möglich zu gestalten.

Während der Designphase kann es auch sinnvoll sein, den Prozess für zusätzliche Umfangsanfragen des Kunden bereits zu besprechen. Diese Anfragen werden unweigerlich aufkommen, sobald der Kunde verschiedene Entwurfsversionen der Anwendung zu nutzen beginnt und feststellt, dass die Anforderungen aufgrund menschlicher Fehler, Interpretationsprobleme, Sprachbarrieren usw. nicht genau das widerspiegeln, was er wollte.

In diesen Situationen ist es wichtig:

• Den Kunden und den Willen zu bestärken, das beste Softwareprodukt zu liefern
• Die Grenzen des Vertrags aufzuzeigen
• Nächste Schritte zu besprechen, um das gewünschte Feature liefern zu können – z. B. in einem anderen Vertrag oder durch Ausschluss von etwas anderem
• Auf den in der Designphase vereinbarten Prozess zu verweisen

Weitere Details zur Handhabung von Umfangsänderungen werden weiter unten erläutert.

Lieferung

Wasserfall vs. Agil

Eine Annahme, die beim Thema Lieferung von Festpreis- und Festumfang-Projekten häufig gemacht wird, ist, dass der Kunde alles kommuniziert hat, alle Anforderungen vorliegen und die Kundenbeteiligung daher erst notwendig ist, wenn der gesamte Umfang implementiert wurde.

Wie tausendfach bewiesen, funktioniert dieser Wasserfallansatz in Softwareprojekten aufgrund der schieren Komplexität, die diese Produkte üblicherweise haben, nicht.

Wenn der Kunde genau das erhalten möchte, was er sich vorstellt, auf die Art und Weise, wie er es sich vorstellt, muss er sich aktiv in die Entwicklung einbringen. Üblicherweise kann ein Product Owner den Entwicklungsprozess mit tiefem Fachwissen unterstützen, was die Entscheidungsfindung erheblich beschleunigen kann. Alternativ sollte dem Entwicklungsteam ein Vertreter der Endnutzer zur Verfügung stehen, der bei fundierten Entscheidungen helfen kann, die dem Kunden am besten dienen.

Lieferprozess

Im Lieferprozess sollte der übliche agile Ansatz mit einigen zusätzlichen Vor- und Nachschritten verfolgt werden.

Der übliche agile Ansatz mit Scrum besteht aus den vier agilen Zeremonien: Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective. Diese sollten ausreichen, um eine gesunde iterative Lieferung zur vollständigen Bearbeitung und Entwicklung der Backlog-Elemente zu ermöglichen.

Daneben werden folgende Begleit-Meetings empfohlen:

• Vor dem Sprint Planning den Anforderungsumfang überprüfen und klar kommunizieren, was der Kunde erhalten wird und was nicht
• Ein wöchentliches Meeting mit dem Kunden zur Besprechung offener Themen, Fragen oder Fehler
• Ein wöchentliches Meeting mit dem Entscheidungsträger zu Fehlern, potenziellen zusätzlichen Umfängen und dem Projektstand

Es kann auch großen Nutzen bringen, dem Kunden so früh wie möglich Mockups oder kleine Proof-of-Concept-Lösungen bereitzustellen, damit er entscheiden kann, ob der gewählte Implementierungsansatz für ihn funktionieren würde. Helft dem Kunden bei der Entscheidung, indem ihr auch die möglichen Konsequenzen – sowohl positive als auch negative – aufzeigt, damit er fundierte Entscheidungen treffen kann.

Fehlerbehandlung

Nach jeder Lieferiteration wird erwartet, dass der Kunde die gelieferten Anforderungen testet. Während dieses Testprozesses können und werden Fehler auftreten, die in folgende Kategorien fallen:

• Fehler, die eine oder mehrere Anforderungen eindeutig nicht erfüllen
• Fehler, die den Geist einer Anforderung nicht erfüllen
• Fehler, die zusätzlichen Umfang darstellen

Wer auch immer diese Fehler analysiert, sollte als erstes den Fehler einer dieser Kategorien korrekt zuordnen und dann eine entsprechende Antwort geben.

• Bei eindeutigen Fehlern sollten diese für einen weiteren Sprint eingeplant werden
• Bei Fehlern im Graubereich soll eine Diskussion über Wert vs. Kosten geführt werden; wenn das Kosten-Nutzen-Verhältnis zu ungünstig erscheint, muss der Fehler ausgeschlossen werden
• Fehler, die zusätzlichen Umfang darstellen, oder neue Feature-Anfragen sollten einem späteren Vertrag zugeordnet werden

Obwohl wir intuitiv die beste Software für unseren Kunden liefern und alle Probleme lösen wollen, ist schlicht nicht genug Budget vorhanden, um das zu ermöglichen.

Vertragsabschluss

Wenn ein rigoroser Lieferansatz befolgt wurde, war hoffentlich die Lieferung des vollständigen Umfangs innerhalb des Budgets möglich. Je nach Zeitrahmen der Zusammenarbeit wurden mehrere Ergebnisse und Resultate erzielt, auf denen ihr aufbauen könnt:

Ergebnisse (Outputs):

• Dokumentation
• Softwarecode und -funktionalität
• Tests zur Unterstützung der Funktionalität (entweder Testhistorie oder automatisierte Testpläne)
• Backlog ungelöster Fehler/Aufgaben, die als außerhalb des Umfangs definiert wurden

Resultate (Outcomes):

• Ein sehr gut definierter und eingespielter Lieferprozess
• Hervorragende Interaktion und Einbindung des Kunden
• Verständnis des zusätzlichen Aufwands neben den Anforderungen

Diese können als Eingaben für folgende Schritte genutzt werden:

• Der Backlog an Fehlern/Aufgaben kann eine Gelegenheit für einen neuen Vertrag sein, um die Anwendung zu verfeinern und Verbesserungen vorzunehmen
• Aufbauend auf den bereits bestehenden Prozessen kann dem Kunden versichert werden, dass die Lieferung schneller als bei anderen Anbietern erfolgen wird
• Zukünftige Schätzungen werden mit demselben Kunden genauer sein

Abschließende Gedanken

Wenn man in einem so eingeschränkten Kontext arbeitet, ist es wichtig, sich stets an die Spielregeln zu erinnern. Obwohl das natürliche menschliche Verhalten darin besteht, den Kunden zu unterstützen und ihm das Leben leicht zu machen, kann das dem Ziel, im Umfang und im Budget zu bleiben, entgegenwirken.

In der Lage zu sein, erschwingliche Alternativen anzubieten und schwierige Situationen in Festpreisprojekten zu bewältigen, ist das tägliche Brot eines Requirements Engineers. Der Kunde kann etwas völlig außerhalb des Umfangs anfordern, und es ist wesentlich, offen zu bleiben und zu versuchen, ihn mit Ideen zu unterstützen, die noch in den Umfang passen. Als letztes Mittel gibt es immer die Option, ein wohlformuliertes „Nein” zu sagen, mit dem Ziel, an die Grenzen der Vertragsvereinbarung zu erinnern.

Vereinbarungen über Prozesse sollten frühzeitig getroffen werden, um Überraschungen und negative Emotionen auf beiden Seiten zu vermeiden.

Der Umgang mit solchen Projekten kann anspruchsvoll sein, ist aber äußerst lohnend, wenn man an der ursprünglichen Planung festhalten kann.