Schon 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 Mobil-Fieber hatte eine breite User-Schicht erreicht. Die Direktbank Cortal Consors erkannte das und beschloss, den Kunden auch auf diesem Kanal zu begegnen - ihnen also mobile Instrumente zum Beobachten und Steuern ihrer Konten und Depots an die Hand zu geben.

Die Zeit drängte: Verschiedene Konkurrenten hatten bereits damit begonnen, ebenfalls erste mobile Applikationen zu entwickeln. Entsprechend groß war das Inter-esse an der Unternehmensspitze, die Entwicklung einer eigenen App schnell und effizient voranzutreiben. Nur neun Monate standen dafür zur Verfügung. Der enge Zeitrahmen machte es notwendig, sich vom bisher starren, aber konsequent angewendeten Projekt-Management-Prinzip zu lösen - und es mit Elementen einer agilen Vorgehensweise zu mixen.

Außen klassisch, innen agil

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

Die wichtigsten Erkenntnisse

Auch von der bis dato angewandten Form des Wasserfall-Modells verabschiedete sich die Projektleitung schnell. Üblicherweise gliederte Cortal Consors die Projektarbeit in fünf Phasen, die nacheinander abzuarbeiten sind. Für das Mobility-Vorhaben wurden die Projektschritte angepasst.

1. Vorstudie (Initialization Phase)

Bedeutet: Das Entwicklungsmodell wird auf Basis von evaluierten Anforderungen, Marktstudien, Problemstrukturierung und Schwachstellenanalyse sowie von Randbedingungen wie Zeit und Budget festgelegt.

Wie de facto verfahren wurde: Die Geschäftsführung hat das Projekt ohne tiefer gehende Vorstudien beschlossen. Lösungen der Konkurrenten wurden erst während der Konzeptionsphase analysiert.

2. Spezifikation und Konzeption (Preparation Phase)

Bedeutet: Die fachlichen Anforderungen an die geplante Applikation werden vor Beginn der Konzeptionsphase schriftlich festgelegt. Dabei sind folgende Kriterien zu beachten: Ausgangssituation, Projektziele, Abhängigkeiten zu anderen Projekten, interne Richtlinien und Compliance, Sicherheitsaspekte sowie Anforderung an Nutzerschnittstelle und Administration.

Wie de facto verfahren wurde: Erst im Verlauf der dreimonatigen Konzeptionsphase parallel zur Entwicklung wurde die Spezifikation entwickelt und dann schrittweise angepasst. Den offiziellen Formalien einer Business-planerischen Spezifikation entsprach sie nur wenig, vielmehr orientierte sie sich am Feedback aller Beteiligten und arbeitete mit Wireframes. Das Pflichtenheft wurde parallel zur fachlichen Spezifikation erarbeitet, aber wegen der Anpassungen erst später fertiggestellt.

3. Programmierung und Testing (Construction Phase)

Bedeutet: Erst wenn das Pflichtenheft beziehungsweise die Spezifikation steht, kann die Entwicklung beginnen. 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. Dieser wurde in Workshops, nach Sitzungen des Lenkungsausschusses und auf Grundlage des Design-Styleguide fortlaufend den jeweiligen Anforderungen angepasst.

4. User Acceptance Test (Acceptance Phase)

Bedeutet: Die gelieferte Software wird vom Auftraggeber auf ihre Lösungsqualität getestet. Der Anspruch an die Applikation ist der, dass nur eine abnahmereife Version 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. Kollegen aus dem Bereich Trading and Technologies übernahmen die Tests für Bestandskunden. Insgesamt benötigte jeder Tester vier Mitarbeiterwochen. Die Web-Agentur lieferte bereits während des Testverlaufs freigegebene Teile der App aus. Die Fachanforderer hatten zuvor Prototypen im Rahmen der Reviews untersucht und dazu Feedback gegeben. So ließen sich praxisnah und frühzeitig Schwächen in der Entwicklung aufzeigen und beheben.

5. Transition

Bedeutet: In dieser Phase bekommt ein System den letzten Schliff. Außerdem wird die Software allen Usern zur Verfügung gestellt (Go Live).

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

Zu wenig Zeit für Reinkultur

Trotz aller Abweichungen vom normalen Prozedere handelte es sich nicht um agiles Projekt-Management in Reinkultur. Auch dafür reichte die Zeit nicht. Allerdings nutzte das Team die Checkliste aus dem Agile Project Management Guide 2.0 der International Association of Project Managers (IAPM).

Ein Project Owner wurde ebenfalls nicht benannt. Das benötigte fachliche Know-how für die Content-Organisation beziehungsweise die Konzeption der App ließ sich kaum einer einzelnen Person übertragen.

Da es im Haus keinerlei Erfahrungen mit der Entwicklung mobiler Applikationen gab. wurde eine französische Agentur mit iOS-Know-how ins Boot geholt. Als eines der wichtigsten Projekt-Tools stellten sich die ein- bis zweitägigen Workshops heraus - fünf allein in der Konzeptionsphase. Noch während des Workshops und auf Basis der proaktiv erstellten Prototypen konnte die Agentur die systemseitige Spezifikation ausarbeiten. Das versetzte sie in die Lage, ad hoc Einwand bei Wünschen zu erheben, die das Projekt maßgeblich verzögert hätten.

Das Ergebnis der Workshops präsentierte sich nicht als klassische Spezifikation, sondern als Wireframes beziehungsweise Grobentwurf der Applikation. Er stellte das Mapping von User-Interface-Elementen dar, die Inhalte wie News und Kurse liefern sollten. Als offizielle "Business Requirement Specification" wurde der Entwurf zu einem wesentlichen Bestandteil des Agenturvertrags.