Ein Anwendungsentwicklungsprojekt, das Teil eines seit Jahren laufenden „Programms“ zur umfassenden Modernisierung der Softwarelandschaft eines großen Dienstleistungsunternehmens war, war mit immer neuen Aufwandserhöhungen und Terminverschiebungen konfrontiert. Die Anwendungsentwicklung samt Analyse erfolgte durch ein großes Softwarehaus, das Lasten- und Pflichtenheft hatte ein anderes Unternehmen erarbeitet. Das Vorgehen war als Wasserfallmodell mit Fixpreis vereinbart, jede Anforderungsänderung war daher als Change Request zum Pflichtenheft abzuhandeln.

Als der Projektleiter auf Seiten des Auftraggebers das Handtuch warf, übernahm diese Funktion ein mit dem beauftragenden Unternehmen durch mehrere Vorprojekte vertrauter externer Projektmanager, da interne Ressourcen nicht zur Verfügung standen.

Eine Runde von Interviews mit wichtigen Stakeholdern des Projektes sowie auch schon die ersten Projektsitzungen zeigten ein verblüffend hohes Ausmaß an Change Requests, über deren Berechtigung mit viel Emotion diskutiert wurde. Ein Check der Vertragsgrundlagen zeigte, dass das Pflichtenheft nur wenige Konkretisierungen gegenüber dem Lastenheft enthielt und daher viel Spielraum für Interpretationen blieb. Auf Seiten des Auftragnehmers war ein professionelles Claim-Management installiert, das es verstand, fast jede Anforderung als Zusatzaufwand zu klassifizieren. Die Anwendervertreter auf Seiten des Auftraggebers hingegen verstanden dies als Konkretisierung einer immer schon bestehenden und daher im Auftrag inkludierten Anforderung. Die ständigen Auseinandersetzungen rund um Change Requests hatten die Atmosphäre der Zusammenarbeit vergiftet und die Verfügbarkeit von qualifizierten Mitarbeitern für die Projektarbeit stieß auf Seiten des Auftraggebers zunehmend auf Probleme.

Da das Programm insgesamt und auch dieses Projekt schon längere Zeit gelaufen waren, die Ergebnisse allerdings in keiner angemessenen Relation zum Aufwand standen, musste darauf geachtet werden, in absehbarer Zeit einen Erfolg vorweisen zu können. Glücklicherweise sah auch das Top-Management des Auftragnehmers mittlerweile diese Notwendigkeit. Die bisher lukrierten Mehrumsätze waren zwar wirtschaftlich erfreulich, die Reputation des Unternehmens im Markt drohte allerdings zu leiden, wenn am Ende kein vorzeigbares Ergebnis erzielt würde. Dieses Interesse hatte natürlich auch das Top-Management des Auftraggebers und so konnte hier ein trotz aller Gegensätze gemeinsames Nutzenkalkül der wichtigsten Stakeholder gefunden werden. Die materielle Seite (Finanzierbarkeit der Investition durch den Auftraggeber bzw. die Gesamtkosten des Projektes) war weniger problematisch als es den Anschein hatte, es war vor allem wichtig, dass die neue Anwendung erfolgreich eingesetzt wird. Man führte zwar auf operativer Ebene einen Kleinkrieg über Aufwände, dies war allerdings eine klare Themenverfehlung aus Sicht des externen Engpasses.

Eine grundlegende Maßnahme, um die Arbeitsfähigkeit des Teams wieder herzustellen, war die Entkoppelung von vertraglichen und inhaltlichen Diskussionen. Auf der operativen Ebene des Projektes wurde nur noch über Anforderungen diskutiert, die daraus resultierenden Aufwände und deren budgetäre Bedeckung wurden dann auf der oberen Managementebene verhandelt.

Es musste zur Kenntnis genommen werden, dass die Berufung auf ein nicht aussagekräftiges Pflichtenheft für die Projektarbeit nutzlos war. Man suchte in Dokumenten, Mails und Protokollen nach Aussagen, um zu klären, ob eine Anforderung immer schon vereinbart oder ein Change Request sei. Was die tatsächlich relevanten Anforderungen für die Inbetriebnahme des Systems aus aktueller Sicht waren, blieb dabei ungeklärt.

Um dies zu ändern, erfolgte im Projekt der Umstieg auf ein iteratives Vorgehen mit einer de facto Time & Materials Verrechnung in einem schrittweise konkretisierten Budgetrahmen. Angesichts der in der Vergangenheit ständig gestiegenen Kosten war dies nur scheinbar eine Verschlechterung für den Auftraggeber; er bekam nun für sein Geld immerhin verwertbare Ergebnisse und näherte sich dem Ziel. Im laufenden Projekt das Vorgehensmodell radikal zu ändern gleicht zwar einem Umbau des Schiffes auf hoher See, aber es war ein Schlüssel zum Erfolg.

Mit der Änderung der Themen, über die zwischen den Vertretern des Auftraggebers und des Auftragnehmers auf operativer Ebene gesprochen wurde, konnte der ersatzlose Verzicht auf eine Managementebene auf Seiten des Auftragnehmers durchgesetzt werden. Konkret wurden jene Personen aus dem Projekt abgezogen, deren Fokus das Claim-Management gewesen war. Nun erfolgte die direkte Zusammenarbeit mit den Systemanalytikern des Auftragnehmers. Damit wurde die Ausrichtung am externen Engpass (Inbetriebnahme, nötigenfalls auch zu erhöhten Kosten) auch in diesem Bereich vollzogen.

Diese gravierenden Änderungen im Bereich der Prozesse des Projektes waren allerdings nur durchsetzbar, weil der Rückhalt durch das Top-Management des Auftraggebers für den neuen Projektleiter durch erfolgreiche Projekte in der Vergangenheit gegeben war. Um diese entscheidende Ressource abzusichern, wurde eine Teilung der Inbetriebnahme vorgenommen, die erfolgreiche Inbetriebnahme in einem Teilbereich des Unternehmens für den ein wesentlicher Funktionsbereich der Anwendungssoftware nicht erforderlich war, stärkte die an sich schon bestehende Vertrauensbasis beim Top-Management und schuf endlich ein Erfolgserlebnis für die Mitarbeiter im Projekt. So eine Option steht nur in Ausnahmefällen zur Verfügung, wenn dies der Fall ist, muss sie allerdings genutzt werden.