Teil 1: Ausgangslage - Die Projektsituation

„Das schaffen wir auch ohne Anforderungsmanager!“, lautete auch beim folgenden Praxisbeispiel die ursprüngliche Annahme der Projektleitung. Die Aufgabe war schließlich überschaubar und die Zusammensetzung des Teams analog zu anderen erfolgreichen Projekten.

Ich möchte Ihnen von einer Situation berichten, in der ich als Anforderungsmanager in ein IT-Projekt im Bankenumfeld kurz vor Go-Live der zu entwickelnden Anwendung einsteigen durfte. Das Projektteam bestand aus fähigen Business Analysten zweier Fachabteilungen und Entwicklern der IT-Abteilung. Das Projekt arbeitete seit neun Monaten an der Umsetzung des Buchungssystems, für welches acht Wochen später der Go-Live terminiert war. Der Umsetzungsstand war aber stark unterschiedlich ausgeprägt. Während für die Fachabteilung I die meisten Anforderungen bereits implementiert und der Abnahmetest in Vorbereitung war, erwartete mich kaum Fortschritt bezüglich der Umsetzung der Anforderungen der Fachabteilung II. Und das, obwohl die Projektleitung stets die Termineinhaltung überprüft, Probleme angesprochen, Lösungen eingefordert und eskaliert hatte.

Nachdem ich mich mit der Situation auseinandergesetzt hatte, konnte ich mehrere Probleme aufdecken. Es kristallisierte sich heraus, dass die Business Analysten der Fachabteilung I geübt im Umgang mit Anforderungsdokumenten waren. Ebenso haben sie gemeinsam mit den Entwicklern der IT-Abteilung schon in anderen Projekten zusammengearbeitet. Diese gemeinsame Historie hatte positiven Einfluss auf die Kommunikation und den Wissenstransfer zwischen Fachabteilung und IT, vor allem aber auf das Verfassen und Umsetzen der Anforderungen. Die Fachabteilung II hatte bisher fachliche Dokumentationen nur für eigene interne Zwecke vorgenommen, allerdings nicht als Anforderungs-dokumentation in einem Entwicklungsprojekt.

Ebenso war den Entwicklern das fachliche Umfeld der Fachabteilung II nicht geläufig. So konnten sie auch mögliche Lücken der Spezifikationen nicht erkennen und orientierten sich eng an den Vorgaben der Fachabteilung.

Resultat war, dass die bereits umgesetzten Module ganz und gar nicht dem entsprachen, was sich die Fachabteilung II vorgestellt hatte.

Mehrfache Iterationen zwischen der Spezifikation und Implementation durch Versuch-Irrtum-Vorgehensweisen führte zu Mehraufwänden, Missstimmungen und Terminproblemen. Als die Termine dann scheinbar gänzlich aus dem Ruder liefen, zog die Projektleitung die Reißleine. Sie suchte bewusst eine neutrale externe Unterstützung für die Rolle des Anforderungsmanagers, da die Situation auch emotional bereits sehr angespannt war.

Es zeigte sich, dass viele kleine Puzzleteile an diversen Stellen fehlten. Denn jeder der Beteiligten handelte entsprechend seines individuellen Erfahrungs- und Wissensstandes. Ein wesentlicher Unterschied war jedoch, dass die eine Projektteamhälfte bereits eine Lernkurve aus anderen Projekten hinter sich hatte, während sie bei der anderen Projektteamhälfte noch vor ihnen lag. Wie auch in diesem Projekt brauchen unerfahrene Teams ohne methodische Unterstützung grundsätzlich mehr Zeit für ein bestimmtes Ergebnis oder stolpern gar über diese Lernkurve. Ob es sich lediglich um ein Stottern im Projektablauf handelt, welches sich von selbst einschwingt, oder ob das Projekt daran scheitern könnte, muss die Projektleitung zügig beurteilen. Im Idealfall analysiert die Projektleitung zum Projektbeginn die Risiken und entscheidet sich gegebenenfalls von Beginn an, einen Anforderungsmanager hinzu zu ziehen. Denn die größten Hürden treten meist schon am Anfang der Anforderungsaufnahme auf – wie es auch schon Scott Adams im Dilbert Comic vom 29.01.2006 humorvoll auf den Punkt brachte.