In Projekten von Banken mit externen Partnern treffen häufig unterschiedliche Methoden aufeinander. Für die Lösung der damit verbundenen Probleme gilt es zunächst die Dimensionen der Zusammenarbeit zu analysieren. Drei Grundfragen spielen dabei eine wichtige Rolle.
Im digitalen Zeitalter müssen Banken und Sparkassen vermehrt mit externen Dienstleistern und Partnern zusammenarbeiten.
Partner des Bank Blogs
In Projekten drehen sich viele Diskussionen direkt oder indirekt um unterschiedliche Vorgehensweisen (z.B. Waterfall und Kanban) zwischen externen Dienstleistern (wie z.B. IT-Provider) und den Auftrag gebenden Banken. Beide Seiten haben ihre Berechtigung, die damit verbundenen Probleme in Projekten müssen aber transparent und möglichst früh angesprochen und gelöst werden.
Wo liegt das Problem?
In vielen Projekten zeigt sich immer wieder dieselbe Problematik: Das Grundverständnis des Projektvorgehens zwischen Banken und ihren Partnern divergiert derart stark, dass sich die Stakeholder nicht darüber einig sind, ob wir nun über Milestones oder Umsetzungsprioritäten diskutieren. Es bleibt unklar, ob das Projekt über detaillierte Spezifikationen, eine gemeinsame Vision oder über eine strukturierte Governance gesteuert wird.
Ich habe mehrfach erlebt, dass diese Frage bis zum Ende des Projekts ungeklärt blieb. Wenn auch für Partikularprobleme Lösungswege gefunden und angewandt wurden, so schwelte die Frage immer im Untergrund, poppte jedoch unregelmäßig wieder auf und führte zu hitzig geführten Diskussionen, die zuweilen die Grundfesten der Zusammenarbeit erschütterten und die zielgerichtete Zusammenarbeit disruptiv störte.
3 Grundlagenfragen für eine Zusammenarbeit
Es gibt drei unterschiedliche Grundlagenfragen für eine Zusammenarbeit, über die man sich beim Projektstart einigen sollte:
- Die gemeinsame Vision: Welches gemeinsame Ziel leitet das Projekt?
- Detaillierte Spezifikationen: Welche Lieferobjekte werden per wann geliefert?
- Strukturierte Governance: Wie wird auf das Projekt Einfluss genommen?
Im Optimalfall werden alle drei Grundlagenfragen diskutiert und geklärt. Dafür fehlt in den Projekten aber oft die Zeit oder der Fokus.
Im Folgenden wird dargelegt, wie die Zusammenarbeit zwischen Projektparteien effizient strukturiert werden kann. Dazu wird für jede der Grundlagenfragen aufgezeigt, was sie beinhaltet, welche Vorteile ihre Beantwortung bringen kann, warum eine Einigung scheitern kann, welche Risiken dies birgt und wie diese Risiken gemildert werden können.
1. Eine gemeinsame Vision
Eine gemeinsame Vision stellt sicher, dass beide Parteien mit der Lösung das gleiche übergeordnete Ziel verfolgen. Diese gemeinsame Vision leitet die Lösungsentwicklung und stellt sicher, dass Zwischenziele und Entwicklungsaufträge richtig definiert und priorisiert werden.
Die so erstellten Zielvorgaben dienen somit vornehmlich dazu, die Vision zu erreichen. Selbstverständlich können auf dem Weg zur Umsetzung der Vision trotzdem Stretch-Goals definiert oder Quick Wins realisiert werden. Aber nur mit einer gemeinsamen Vision passiert dies auch im gegenseitigen Bewusstsein, dass damit nicht mehr direkt der Vision gedient wird, sondern gegebenenfalls andere strategische Ziele verfolgt werden.
Jedoch geben viele externe Anbieter von Standardprodukten die Vision nicht gerne aus der Hand, zumal sie nachvollziehbarerweise möglichst marktgerechte Lösungen anbieten wollen. Individuelle Visionen führen aber eben meist zu Individuallösungen, denen es an der nötigen Leverage fehlt. Darum sind diese meist unverhältnismäßig teuer. Im Gegenzug will sich die Bank nicht die Vision des Dienstleisters aufzwingen lassen zumal diese sich nicht zwingend mit deren strategischen Zielen deckt.
Das Fehlen einer gemeinsamen Vision kann dazu führen, dass die Zielvorgaben falsch definiert werden und Priorisierungen falsch vorgenommen werden. Dadurch wird gegebenenfalls effizient entwickelt, aber nicht effektiv. Die entwickelten Programmteile und Funktionen lösen gar nicht das Problem, das mit dem Projekt adressiert werden soll.
Kann keine gemeinsame Vision etabliert werden, muss diese Vision vom Kunden (also auf Bankseite) auf einzelnen Business-Anforderungen heruntergebrochen werden. Dabei muss klar sein, über welche Kanäle und in welcher Qualität (Form, Detaillierungsgrad, etc.) die Anforderungen dem Anbieter übergeben werden und wie diese weiterverarbeitet werden.
2. Detaillierte Spezifikationen
Detaillierte Spezifikationen helfen bei der Planung des Projekts und bereiten die Bank auf organisatorische Neuerungen vor. Dank einer strukturierten Planung kann das Prozessmanagement die neuen Prozesse designen, planen, dokumentieren und deren Umsetzung vorbereiten. Das Risk-Management kann diese auf neue Risiken prüfen und entsprechende mitigierende Maßnahmen einleiten. Benutzer können abgeholt, involviert und frühzeitig geschult werden.
Jedoch obliegt es dabei der Bank, die Vision auf einzelne Funktionen oder Umsetzungspakete herunterzubrechen. Nicht jede Bank hat im Umgang mit externen Dienstleistern die nötige Erfahrung, es fehlt die Schnittstelle zwischen Bankfach und Technik. Oft wird bei der Spezifikation auch zu sehr in alten Mustern verharrt und neue technische Möglichkeiten bleiben unbeachtet. Dadurch bleiben Innovationspotenziale ungenutzt.
Fehlen terminierte Zielvorgaben, die langfristig genug sind oder sind diese zu volatil, muss vor jedem Release auch organisatorisch und administrativ und logistisch kurzfristig (um)geplant werden. Dies führt zu unnötigem Stress im Projekt und kann unter anderem Stakeholder (z.B. Benutzer) gegen das Projekt aufbringen.
Fehlen detaillierte Einzelanforderungen, ist es umso wichtiger, den Stakeholdern die Projektvision näher zu bringen und sie (zum Beispiel im Testing) möglichst früh ins Projekt mit einzubeziehen. Ein konsequentes Erwartungsmanagement und klar definierte Regeln der gegenseitigen Einflussnahme (Governance) minimieren dabei die Unzufriedenheit der Projekt-Stakeholder.
3. Strukturierte Governance
Die Projekt-Governance definiert, in welcher Form und über welche Plattformen die Bank auf die Lösung Einfluss nehmen kann. Nur mit dem Wissen, wie auf die Lösung Einfluss genommen werden kann, wissen Banken, wie mit diesem Feedback umgegangen wird. Im Sinne von Service Level Agreements muss definiert werden, über welchen Kanal die Feedbacks zurückkommen, in welcher Zeit auf welche Dringlichkeiten und Wichtigkeiten reagiert wird und in welcher Form zugehörige Lösungen ausgeliefert werden.
Oft scheitert die Etablierung einer strukturierten Governance in Projekten an den bestehenden internen Prozessen beider Parteien, die jeweils Änderungen unterzogen werden müssten, was beidseitig zu einer inkonsistenten internen Prozesslandschaft führen und Mehraufwände generieren würde (die oft im Projekt-Budget nicht berücksichtigt wurden).
Fehlt die nötige Governance, werden Feedbacks von den Banken mit der falschen Erwartungshaltung platziert. Dadurch kommt es zu Enttäuschungen. Die Bank sieht sich um den Lohn ihres Test- und Dokumentationsaufwands beraubt, während der Partner davon ausgeht richtig zu handeln. Schließlich wurde ja nie versprochen, ob und in welcher Zeit diese Feedbacks berücksichtigt werden.
Die Probleme einer fehlenden Governance kann dadurch abgeschwächt werden, dass die Spezifikationen genug klar und detailliert sind, darauf basierend klare Zielvorgaben (z.B. Milestones) festgelegt werden und deren Einhaltung überwacht wird. Daneben ist es sinnvoll eine gemeinsame Vision zu schärfen. Ist daneben auch noch sichergestellt, dass die spezifizierten Funktionalitäten die Vision effektiv unterstützen, so werden im Projekt weniger Änderungswünsche entstehen. Dadurch wird das Bedürfnis nach einer hochgradig strukturierten Governance sinken.
Wie gehen wir also vor?
Welche Diskussion ist in welcher Situation angebracht? Um diese Frage zu klären ist erstmal eines wichtig: Die Schaffung gegenseitiger Transparenz. Die Stakeholder müssen untereinander aufzeigen, welche Vorgehensmodelle, Arbeitsweisen und internen Prozesse wichtig oder gar unumstößlich sind. Darum müssen die eingangs erwähnten Grundlagenfragen möglichst früh im Projekt gestellt und möglichst offen beantwortet werden.
Allzu oft wird dieser Findungsphase im Projekt zu wenig oder gar keine Zeit und Energie eingeräumt. Man verlässt sich auf vertragliche Vereinbarungen (zum Beispiel Response-Zeiten in SLAs) und verharrt gegenseitig in Erwartungshaltungen, die auf impliziten Interpretationen und Auslegungen beruhen. Aber nur eine transparent und pragmatisch geführte Diskussion schafft die Voraussetzungen, die dem zukünftigen Projekt viele Stolpersteine erspart.
Im zweiten Teil des Beitrags werden mögliche Kollaborationsmodelle zwischen Banken und ihren Dienstleistern vorgestellt.
