iPhone, iPad, Androids - im Jahr 2009 war klar: die neue Generation mobiler Endgeräte konnte nicht länger als Spielzeug einer kleinen Gruppe von Early-Adoptern und Technikfreaks abgetan werden, das mobile Fieber hatte längst eine breite Userschicht erreicht. Bei Cortal Consors, einer der führenden Direktbanken in Europa, hatte man dies schnell erkannt und beschloss, dem Kunden auch auf diesem mobilen Kanal zu begegnen - und ihm gleichermaßen Instrumente zur Beobachung sowie Steuerung seines Depots sowie seiner Konten an die Hand zu geben.

Die Zeit drängte, denn obwohl man mit der Kombination aus Marktinformationen, Trading und Banking ein - zu diesem Zeitpunkt einmaliges - Produkt anbot, hatten doch verschiedene Wettbewerber bereits erste mobile Applikationen entwickelt. Entsprechend groß war auch das Interesse in der Unternehmensspitze, die Entwicklung einer eigenen App schnell und effizient voran zu treiben. Nur neun Monate standen dafür zur Verfügung. Doch der enge Zeitrahmen schuf den Freiraum dafür, sich vom bisher starren aber konsequent angewendeten Projekt-Management-Prinzip zu lösen - und dieses mit Elementen einer agilen Vorgehensweise zu mixen.

Außen klassisch, innen agil

Im Normalfall wäre das Projekt in die Release-Planung aufgenommen worden, in der sämtliche Softwareentwicklungsprojekte organisiert werden . Das ließ der enge Zeitplan nicht zu, denn um alle in der Release-Planung geforderten Formalitäten zu erfüllen, hätte der Betriebsstart um knapp drei Monate verschoben werden müssen.

Auch von in der bis dato angewandten Form des Wasserfall-Prinzips verabschiedete sich die Projektleitung schnell und passte die Methode den eigenen Anforderungen an. Üblicherweise gliederte Cortal Consors die Projektarbeit in fünf Phasen, die nacheinander abzuarbeiten sind. Für das Mobility-Vorhaben wurden die Projektschritte angepasst. Im folgenden sind die ursprünglichen und veränderten Phasen dargestellt.

1. Vorstudie (Initialisation Phase):

Bedeutet: Das Entwicklungsmodell wird auf Basis von evaluierten Anforderungen, Marktstudien, Problemstrukturierung und Schwachstellenanalyse, Definition sowie auf Basis von Randbedingungen wie Zeit und Budget, etc festgelegt. Außerdem werden Web-Entwicklungsprojekte bei Cortal Consors im Rahmen der sogenannten Release-Planung projektiert.

Wie de facto verfahren wurde: Die Geschäftsführung hat das Projekt ohne tiefer gehende Vorstudien beschlossen. Zwar war bekannt, dass auf Kundenseite eine hohe Affinität zu Apple-Produkten bestand, aber für das iPhone war diese nicht speziell abgefragt worden. Wettbewerberlösungen wurden erst während der Konzeptionsphase analysiert. Das Projekt wurde nicht in die offizielle Release-Planung integriert.

2. Spezifikation und Konzeption (Preparation Phase)

Bedeutet: Die fachlichen Anforderungen an die geplante Applikation werden vor Beginn der Konzeptionsphase schriftlich festgelegt. Dabei muss diese unter anderem folgende Kriterien und Formalien erfüllen: Ausgangssituation, Projektziele, Abhängigkeiten zu anderen Projekten, interne Richtlinien und Compliance, Sicherheitsaspekte sowie Anforderung an die Nutzerschnittstelle und Administration.

Wie de facto verfahren wurde: Erst im Verlauf der dreimonatigen Konzeptionsphase - die parallel zur Entwicklungsphase stattfand - wurde die Spezifikation entwickelt und dann schrittweise angepasst. Sie entsprach letzlich jedoch den offiziellen Formalien einer business-planerischen Spezifikation nur wenig, da sie sich vielmehr am Feedback aller Beteiligten orientierte. Es handelte sich um eine um Wireframes ergänzte Spezifikation. Das Pflichtenheft wurde parallel zur fachlichen Spezifikation erarbeitet, aber erst später fertig gestellt, da es noch an die fachliche angepasst werden musste.

3. Programmierung und Testing (Construction Phase)

Bedeutet: Erst wenn das Pflichtenheft beziehungsweise die Spezifikation steht, kann die Entwicklung starten. Jede Abweichung oder Änderung erfordert einen schriftlichen Change Request - und wird damit als Ärgernis angesehen.

Wie de facto verfahren wurde: Der mit der Programmierung beauftragte Dienstleister brachte bereits zum ersten Konzeptions-Workshop einen Prototypen mit - und damit noch vor Erstellung der Spezifikation. Dieser wurde in Workshops, nach Sitzungen des Lenkungsausschusses sowie nach Festlegung des Design-Styleguides im fortlaufenden Turnus den immer wieder neu hinzugekommenen Anforderungen angepasst.

4. User Acceptance Test (Acceptance Phase)

Bedeutet: Die gelieferte Software wird vom Auftraggeber auf Lösungsqualität getestet. Der Anspruch an die Applikation ist, dass nur eine abnahmereife Version dann nach fest definierten Testkriterien und -serien geprüft werden soll.

Wie de facto verfahren wurde: Zwei Monate lang analysierten Tester aus dem Bereich E-Business die Variante für Neukunden, und Kollegen aus dem Bereich Trading and Technologies die für Bestandskunden. Insgesamt wurden dafür pro Tester vier Mitarbeiterwochen benötigt. Die Web-Agentur lieferte bereits während des Testverlaufs final getestete und damit freigegebene Teile der App aus - noch bevor die gesamte App freigegeben worden war. Die Fachanforderer hatten zuvor bereits Prototypen im Rahmen sogenannter Reviews untersucht und dazu Feedback gegeben, sodass sehr praxisnah und frühzeitig Schwächen in der Entwicklung aufgezeigt - und damit auch behoben - werden konnten.

5. Transition

Bedeutet: In dieser Phase erfolgt der letzte Feinschliff. Außerdem wird die Software allen Usern zur Verfügung gestellt (Go Live).

Wie de facto verfahren wurde: Das Go Live erfolgte in Deutschland im Mai 2010, in Frankreich im September 2010. Dokumentation, User-Schulungen, das Aufsetzen eines Helpdesk, Marketing-Maßnahmen und die Inbetriebsnahme folgten den üblichen Standards.