Das perfekte Projekt

In einem perfekten Projekt wäre alles ganz einfach:

• Das zu entwickelnde Produkt wäre vollumfänglich bekannt. Sowohl der Kunde als auch der Auftragnehmer wüssten bis ins letzte Detail, wie es am Ende aussehen und was es können sollte.
• Alle Wünsche und Anforderungen des Kunden wären zwischen diesem und dem Dienstleister(n) abgestimmt, vollständig dokumentiert und von allen am Projekt Beteiligten verstanden.
• Basierend auf der Dokumentation würde eine nahezu wasserdichte Planung erstellt, die alle Anforderungen sowie Risiken berücksichtigt.
• Anhand des Plans würde das Produkt entwickelt und natürlich in Time und in Budget fertiggestellt.
• Und wenn das Produkt dem Kunden am Ende übergeben wird, steht fest: Auch an der Qualität gibt es nichts zu bemängeln. Es entspricht vollkommen dem Erwarteten und liefert den Mehrwert, den sich der Kunde davon erwartet hat, oder es übertrifft ihn sogar.

Die Realität

Wie wir alle wissen und um das ein oder andere Mal erfahren durften, kommt dieses Szenario in Wirklichkeit leider nicht, oder nur höchst selten vor.

Oft existiert zu Beginn eines Projekts nur eine sehr vage Vorstellung von dem Endprodukt.  Einige Anforderungen können vielleicht schon sehr konkret beschrieben werden. Andere, vor allem die komplexeren Themenbereiche sind allerdings für die Beteiligten noch mehr oder weniger eine Black Box. Manche Anforderungen erscheinen essenziell und werden daher mit höchster Priorität sowie unter teilweise großem Aufwand umgesetzt, ergeben sich später dann jedoch als überflüssig oder von nur geringem Mehrwert. Schließlich stellt sich dann noch während der Umsetzung heraus, dass dies und jenes in der ursprünglichen Planung vergessen wurde oder auf andere Art und Weise realisiert werden müsste. In Folge müssen die akribisch erstellten Dokumentationen aktualisiert und der Projektplan überarbeitet werden.

Doch wie kann man mit diesen Unsicherheiten umgehen? Ein agiles Vorgehen (bspw. nach dem Scrum-Framework) und ein damit einhergehendes agiles Anforderungsmanagement kann dabei unterstützen, flexibel und effektiv auf sich ändernde Gegebenheiten zu reagieren. Doch was unterscheidet das klassische Anforderungsmanagement von seinem agilen Pendant?

Klassisches und agiles Anforderungsmanagement – eine Gegenüberstellung

Nachfolgend wollen wir einige Faktoren unter Betrachtung beider Ansätze vergleichen.

	Klassisches Anforderungsmanagement	Agiles Anforderungsmanagement
Produktverständnis	Es wird das Ziel verfolgt, das zu entwickelnde Endprodukt bereits zu Beginn vollständig zu erfassen und dessen Entwicklung damit möglichst vorhersehbar und kalkulierbar zu gestalten.	Es wird davon ausgegangen, dass sich das Verständnis für das Produkt im Laufe des Projekts entwickeln muss. Hierfür wird auf Erkenntnisse und regelmäßiges Kundenfeedback  im Laufe der Umsetzung gesetzt.
Anforderungs-Dokumentation	Die Anforderungen werden  in einem Dokument (Lastenheft) vor Beginn der Umsetzung möglichst vollständig und detailliert dokumentiert.	Anforderungen werden in Form von Themes, Epics und User Stories erfasst. Sie werden kontinuierlich (auch während der Entwicklung) angepasst und bewertet. Der Detaillierungsgrad von Anforderungen steigt entsprechend ihrer Priorisierung. Noch in weiterer Zukunft liegende Anforderungen werden erst dann näher betrachtet und beschrieben, wenn sie für die Umsetzung in absehbarer Zeit relevant werden.
Kommunikation	Die Abstimmungen mit dem Kunden erfolgen schwerpunktmäßig zu Beginn des Projekts im Rahmen der Anforderungsaufnahme.	Die Abstimmung mit dem Kunden findet kontinuierlich statt. Regelmäßiges Feedback auch während des Entwicklungsprozesses ist ein wesentlicher Bestandteil.
Änderungen	Änderungen werden über einen Änderungsantrag initiiert, über den in einem Änderungsgremium (Change-Control Board) entschieden wird. Anschließende werden alle Dokumente und Pläne entsprechend angepasst und die Konfigurations-Baseline auf den neuen Stand gehoben	Änderungen werden durch Anpassung bzw. Erweiterung und Priorisierung des Product-Backlog eingesteuert. Durch die iterative Umsetzung in agilen Projekten kann schneller und flexibler auf sie reagiert werden.
Auslieferung des Produkts	Das Endprodukt wird nach Abschluss der Realisierungsphase an den Kunden übergeben.	Eine erste Produktversion steht frühzeitig zur Verfügung und liefert dem Kunden bereits einen Nutzen (MVP – Minimum Viable Product)

Fazit

Klar ist: Das Management von Anforderungen darf nicht mit Beginn der Umsetzung enden. Die wenigsten Projekte kommen ohne Änderungen im Zuge der Umsetzung aus. Sei es, weil sich Anforderungen später als zu unpräzise oder fehlerhaft herausstellen, sich die Wünsche des Kunden ändern, neue Erkenntnisse einen anderen Blick auf das Produkt verschaffen oder Änderungen der Gesetzeslage oder des Marktes Anpassungen erfordern.

Letztendlich kann nicht pauschal das eine oder andere Vorgehen als besser erachtet werden. Beide Ansätze, ob klassisches oder agiles Anforderungsmanagement, haben ihre Berechtigung. In Zeiten komplexer werdender Produkte, sich immer schneller ändernder Rahmenbedingungen sowie neuen Arbeitsstrukturen können agile Vorgehensmodelle ihre Stärken ausspielen. Allerdings ist kein Projekt wie das andere und es muss nicht ausschließlich schwarz oder weiß sein. Aspekte aus beiden Ansätzen lassen sich durchaus sinnvoll miteinander kombinieren. Daher sollte für jedes Projekt beurteilt werden, welcher Mix sich anbietet und wie von den Vorteilen aus beiden „Welten“ profitiert werden kann.