Herausforderungen und Lösungsansätze für große IT-Projekte

Am Ende großer Entwicklungsprojekte besteht oft die Gefahr, dass niemand mehr den Gesamtüberblick hat. Mit dem Mut zur radikalen Vereinfachung kann diesem Problem frühzeitig entgegengetreten werden.

Herausforderungen bei großen Entwicklungsprojekten in IT-Anwendungslandschaften.

Wie können in großen Entwicklungsprojekten mit bis zu 20.000 Projekttagen zum richtigen Zeitpunkt Aufwände reduziert, Projektrisiken minimiert und Ressourcen konzentriert eingesetzt werden? Wie kann verhindert werden, dass klare Alarmsignale während der Entwicklungszeit nicht einfach übergangen werden? Im Folgenden werden Phänomene aufgezeigt, die wiederholt in größeren Entwicklungsprojekten auftreten und es wird erläutert, wie besser mit diesen umgegangen werden kann.

Rahmenbedingungen großer IT-Entwicklungsprojekte

Komplexe Front- und Middle-Office-Systeme der Finanzinstitute, die oftmals seit 15 Jahren in Betrieb sind, erfordern jüngst, ausgelöst durch gesetzliche Auflagen, massive Veränderungen in Anwendung und Technik.

Erwartungen der Auftraggeber bestehen hinsichtlich

Versprochener und vermeintlicher Kosteneinsparungen in Millionenhöhe durch potenzielle Prozess-Verbesserungen.
Anforderungen des Gesetzgebers in Reporting, Kundenkontakten, Geschäftsabschlüssen und Transparenz des Angebots.
Geplanter Budgeteinsparungen in der nächsten Abschreibungsperiode nach Produktivsetzung.
Versprochener Einsparungen durch die Umsetzung mittels agilem Projektmanagement und der Organisation gemäß bimodaler IT.

Zur Finanzierung werden interne Auftraggeber gesucht, die während der Konzeption weitere Ziele für die Anwendung definieren.

In diesem Szenario sorgt ein Dutzend oder mehr unterschiedlicher Fachbereiche für eine Vielzahl von neuen Anforderungen und Verbesserungswünschen, die Erleichterungen im Bearbeitungsprozess und der Datenversorgung erbringen sollen.

Weitere Umfeldbedingungen sind: Budgets in zwei- bis dreistelliger Millionenhöhe, mehrere Vendoren, sprich Auftragnehmer, in der Realisierung, die zusammenarbeiten müssen, ein ausgelagerter Testbereich. Da ambitioniert durch die Fach- und IT-Teams an der Konzeption gearbeitet wird, jedoch viele Änderungswünsche berücksichtigt werden müssen, erfolgen die Abnahmen der Konzepte erheblich unter Zeitdruck.

Selbstredend gibt es eine „Project Charter“ und alles was so „State of the Art“ ist, wie Überblick über alle Requirements, entsprechend verantwortliche organisatorische Einheiten im Projekt, entsprechend besetzte Teilprojekte. Reporting-Wege werden eingehalten. Ein Tool Set zur Projektplanung ist eingerichtet, die entsprechenden Reports an die Entscheidungsboards einschließlich Meetings liegen vor und werden an die Projekt-Gremien zur Beurteilung und Entscheidung übergeben.

Augenscheinlich ist das Projekt perfekt organisiert – es gibt verantwortliche Teilprojektleiter, Experten, Juristen in den Teilprojekten, die jeweils Fachkonzepte in ausreichender Menge und vorgegebener Qualität erstellen.

Herausforderungen großer IT-Entwicklungsprojekte

Die Projektlaufzeit beträgt drei bis fünf Jahre. Was aber läuft dann nicht so richtig oder sorgt für Unstimmigkeiten, Aufwands-Phänomene, Verzögerung in der Konzeption, Fallbearbeitung und somit Projektplanänderungen?

Die geplante Reihenfolge der Bearbeitung von Teilprojekten erweist sich als die falsche Reihenfolge, weil mit den vermeintlich besser überschaubaren Teilprojekten zuerst begonnen wird.
Komplexe Teilprojekte werden mit zu wenig Experten und Generalisten besetzt.
Viele Iterationen beim Erstellen der Fachanforderungen werden notwendig.
Bei der Umsetzung in IT-nahe Konzeptionen zeigen sich erhebliche Ungenauigkeiten in den Fachkonzepten, die häufig Rückfragen der Entwickler und wiederum erneute Anpassungen der IT-Konzepte und damit nachfolgend der Fachkonzepte bewirken.
Fachbereiche beharren oft auf ihren konzeptionellen Vorgaben.
In der Mitte des Projektverlaufs zeigt sich, dass die Bearbeitung der Teilprojekte sich nur bedingt parallelisieren lässt: Die Zahl der notierten Themen im „Backlog“ nimmt zu und die Anzahl der sog. „Change requests“ steigt.
Eine Fokussierung auf wenige Fachexperten führt zu Engpass-Situationen im Projekt
Der Know-how-Transfer von der Anforderung und der Konzeption zur Entwicklung ist zeitaufwendiger als gedacht

Missverständnisse in der Beschreibung der Testfälle bis hin zur Testerwartung führen zur Verzögerung in der wichtigen Testphase des System-Integration-Test (SIT). Laufende Fehler werden zu spät zu den dazugehörigen Teilprozessen strukturiert und nicht konsequent abgearbeitet. Stattdessen werden nur die offensichtlich größten Problemfälle bearbeitet in der Hoffnung, dass im „Fahrwasser“ der in der Programmierung bearbeiteten „defects“ weitere Fehler „trockengelegt“ werden.

Eine negative Begleiterscheinung in diesem Szenario ist, dass die Bereitschaft der Fachbereiche sinkt, die angebotene Lösung zu akzeptieren und „versteckte“ Kröten zu schlucken.

Hinweise zum „Gegensteuern“

Wie lässt sich rechtzeitig umsteuern? Ein Alarmsignal ist eine „Defect“-Anzahl in hoher drei- bis vierstelliger Höhe, deren Detailliertheit in ihrer Gesamtheit undurchschaubar wird und dadurch zu einer massiven „Unschärfe“ führt: ein zehn Meter langer Flickenteppich der „Pseudo-Genauigkeiten“.

Daher ist es sinnvoll, radikal einfach ein Drittel der gefundenen Fehler „wegzuwerfen“ und zu „vergessen“. Weggeworfen wird dabei nicht einfach ein Drittel aller Fehler, sondern die als leicht klassifizierten Fehler, in der Annahme, dass sie für die Entwicklung des Systems nicht relevant sind. Unter diese leichten Fehler subsummieren sich: Test-Daten-Phänomene, Bedienungsfehler, die zu Missverständnissen führen, falsche Belegung von Datenfeldern, zum Beispiel „Muss- statt Kann“-Befüllung und umgekehrt, sowie fehlerhafte Testdaten bis hin zum Fehlen eines stabilen Testbestands.

Durch rechtzeitiges Clustering von gefundenen Fehlern zu den dazugehörigen Teilprozessen, dem konsequenten rechtzeitigen auch räumlichen „Teaming“ von Entwicklern, Testern und Fachexperten und dem Mut, leichte Fehler einfach zu vergessen, kann ein Großprojekt trotz anfänglicher tayloristischer Aufgabenteilung gut und mit weniger Stress für alle Beteiligten gemeistert und „in time“ in Produktion übergeben werden.