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 ComplianceCompliance, Sicherheitsaspekte sowie Anforderung an Nutzerschnittstelle und Administration. Alles zu Compliance auf CIO.de

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.