„Vergesst“ eure Fehler einfach!

Wie könnt ihr in großen Entwicklungsprojekten mit bis zu 20.000 Projekttagen zum richtigen Zeitpunkt Aufwände reduzieren, Projektrisiken minimieren und Ressourcen konzentriert einsetzen? Wie könnt ihr verhindern, dass klare Alarmsignale während der Entwicklungszeit nicht einfach übergangen werden? Im Folgenden möchte ich euch zunächst einige Phänomene zeigen, die wiederholt in größeren Projekten auftreten. Anschließend gebe ich euch dann einige Tipps, wie ihr besser mit diesen Problemen umgehen könnt.

Rahmenbedingungen großer IT-Entwicklungsprojekte

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

Ein Beispiel: Die Erwartungen eurer Auftraggeber bestehen hinsichtlich

• versprochener und vermeintlicher Kosteneinsparungen in Millionenhöhe durch potenzielle Prozessverbesserungen.
• Anforderungen des Gesetzgebers in Bezug auf 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 bimodaler IT.

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

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

Weitere Umfeldbedingungen des gewählten Beispiels sind Budgets in zwei- bis dreistelliger Millionenhöhe, mehrere Vendoren (Auftragnehmer) in der Realisierung, die zusammenarbeiten müssen und ein ausgelagerter Testbereich. Zwar arbeiten die Fach- und IT-Teams ambitioniert an der Konzeption, jedoch müssen so viele Änderungswünsche berücksichtigt werden, dass die Abnahme der Konzepte erheblich unter Zeitdruck gerät.

Selbstredend verfügt ihr über eine „Project Charter“ und alles, was „State of the Art“ ist. Ihr habt den Überblick über alle Anforderungen, organisatorisch verantwortliche Einheiten im Projekt oder entsprechend besetzte Teilprojekte. Reporting-Wege haltet ihr auch ein. Ihr habt ein Toolset zur Projektplanung eingerichtet und die entsprechenden Reports an die Entscheidungsboards, einschließlich Meetings, liegen vor. Diese werden von euch an die Projektgremien zur Beurteilung und Entscheidung übergeben.

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

Herausforderungen großer IT-Entwicklungsprojekte

Sagen wir, die Laufzeit eures Projektes beträgt drei bis fünf Jahre. Trotz guter Organisation läuft es aber nicht ganz rund, denn es gibt Unstimmigkeiten, Aufwandsphänomene, Verzögerungen in der Konzeption, Fallbearbeitungen und somit Projektplanänderungen. Wie kann das sein? Ich verrate es euch:

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

Missverständnisse in der Beschreibung der Testfälle bis hin zur Testerwartung führen in eurem Projekt zu Verzögerungen in der wichtigen Testphase des System Integration Test (SIT). Laufende Fehler werden von euch zu spät zu den dazugehörigen Teilprozessen strukturiert und nicht konsequent abgearbeitet. Stattdessen bearbeitet ihr nur die offensichtlich größten Problemfälle und zwar in der Hoffnung, dass Fehler (defects), die bereits während der Programmierung entstanden sind, im weiteren Projektverlauf korrigiert 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 könnt ihr hier rechtzeitig das Steuer rumreißen? Ein Alarmsignal ist eine Defect-Anzahl in drei- bis vierstelliger Höhe, deren Detailliertheit in ihrer Gesamtheit undurchschaubar wird und dadurch zu einer massiven „Unschärfe“ führt.

Daher rate ich euch, einfach ein Drittel der gefundenen Fehler „wegzuwerfen“ und zu vergessen. Weggeworfen wird dabei nicht einfach ein Drittel aller Fehler, sondern nur die als leicht klassifizierten. Das geschieht in der Annahme, dass diese Fehler für die Entwicklung des Systems nicht relevant sind. Unter diese leichten Fehler subsummieren sich beispielsweise Testdaten-Phänomene, Bedienungsfehler, die zu Missverständnissen führen, falsche Belegungen von Datenfeldern – etwa „Muss- statt Kann“-Befüllungen und umgekehrt, fehlerhafte Testdaten sowie das Fehlen eines stabilen Testbestands.

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

Dieser Beitrag ist auch im Banken-Blog erschienen.