Anforderungsmanagement in Großprojekten – „eingefroren“ oder doch agil?

Vor kurzem durfte ich einen knappen Blick auf ein Großprojekt werfen, in dem es über einen mehrjährigen Zeitraum darum geht, eine weitreichende IT-Lösung zu implementieren. Mit einer sehr knapp gehaltenen Spezifikation der Anforderungen begonnen, steht man nun kurz vor dem Abschluss des Projekts – zumindest was Termin und Kosten anbelangt. Leider muss die Projektleitung jedoch feststellen, dass es nicht möglich zu sein scheint, „die Kurve“ zum Abschluss der Implementierungsarbeiten zu bekommen: immer wieder kommen aus den Fachbereichen neue Anforderungen.

Kurzerhand wird – wenn auch sehr spät – der Freece Point vereinbart: es sollen keine weitere Änderungsanforderungen angenommen werden. Änderungs- und Erweiterungswünsche werden gesammelt und nach Projektabschluss weiter bearbeitet. So erwartet man, Kosten deckeln und Termine halten zu können.

Insbesondere in SAP-Projekten ist es nicht unüblich, auf genau diese Art vorzugehen: wenig funktionale Anforderungsspezifikation zu Projektbeginn, umfangreiche Änderungswünsche im Zuge des funktionalen Abnahmetests bzw. User Acceptance Test. Dadurch wird ein in Termin und Kosten fixiertes Arbeiten jedoch schwierig: wenn es schlecht läuft bekommt das Projekt in der Endphase eine ungeheuer umfangreiche Bugwelle an Aufwand durch Änderungen oder Erweiterungen, ggf. müssen viele Dinge gar doppelt implementiert werden. Was bis zur Testphase gut verlief, kann „hinten raus“ vollkommen entgleisen.

Fraglich ist, ob ein möglichst früher Freece Point hier weiter hilft: sicherlich gibt das Planungssicherheit doch je früher dieser Schritt passiert, desto schwieriger wird es eine ausreichende (oder gar darüber hinaus …) Kundenzufriedenheit zu erreichen.

Denkbar wäre hier ein Mittelweg: für geschäftskritische und umfangreiche Anforderungen früh einen hohen Spezifikationsgrad erreichen und schnellstmöglich eine gemeinsame Fixierung dieser Anforderungen erreichen (=Freece Point). Alle weiteren – insbesondere auch neu auftauchenden Anforderungen – gehen neben der Implementierung der fixierten Anforderungen in einen agilen Prozess, in dem z.B. in iterativen Timeboxen mit hohem Involvement der Anwender ein beschränktes Budget abgefahren werden kann. Priorisierung und Umfang kann der „Kunde“ durch seinen Input und seine Eingaben selbst gestalten – eine „Spielwiese“ und Implementierungsfeld in einem, in dem der Fokus auf Kundenzufriedenheit liegt.