Digitale Exzellenz
Digitale Exzellenz

IT-Großprojekte – den passenden Cocktail aus agil und klassisch mixen

, 3. Februar 2021

Lesezeit: 6 Minuten

IT-Großprojekte – den passenden Cocktail aus agil und klassisch mixen

Auf pures Scrum oder Kanban als Projekt-Framework zu setzen, ist bei Großprojekten schwierig. Agil ist in seiner Urform für einzelne Teams konzipiert. Für eine Skalierung gibt es Hybrid-Frameworks. Viele Entscheider grübeln allerdings, welche Ausgestaltung die Richtige ist. Einige Kriterien helfen bei der Bewertung, um die richtige Dosis Agilität zu finden.

Die großen Banken in Deutschland haben die Weichen für ein Transformationsjahr 2021 gestellt.  Die Commerzbank hat erst kürzlich angekündigt, auf moderne Cloud-Technologien von Microsoft zu setzen. Ziel ist die Auslagerung einer signifikanten Anzahl von Anwendungen. Deutschlands größtes Kreditinstitut, die Deutsche Bank, wird im Rahmen ihres Modernisierungsprojektes zukünftig ebenfalls auf Cloud Services setzen, allerdings auf die von Google. Und die Sparkassen stehen den privaten Geschäftsbanken in nichts nach. Die Finanz Informatik vermeldete bereits im Juli eine Zusammenarbeit mit dem Internetkonzern aus den USA.

Um derartige Projekte, bei denen sich schnell die Rahmenbedingungen durch neue Regulierung oder technologische Standards verändern, besser zu steuern, kommen mittlerweile überall in der Wirtschaft agile Ansätze zum Einsatz. Jeder zweite deutsche Konzern vertraut auf Agilität in der Projektpraxis, hieß es bereits 2018 in einer Bitkom-Studie. Inzwischen werden es wahrscheinlich noch mehr sein.

Agil ist allerdings nicht immer und für jedes Projekt das Maß aller Dinge. Das ursprüngliche Scrum-Modell mit den bekannten Rollenkonzepten ist für ein überschaubares Team ausgelegt. Bei den oben erwähnten IT-Infrastruktur-Projekten, inkl. Organisations-Transformationen bedarf es jedoch einer Lösung, um eine Vielzahl interner Teams und weiterer externer Projektbeteiligten mit mehreren hundert Menschen zu steuern.  

Hybrides Projektmanagement als Erfolgsfaktor     

Für die Verantwortlichen bei Commerzbank, Deutscher Bank und Sparkassen besteht die Herausforderung somit darin, Agilität zu skalieren und eine Projektstruktur mit dem richtigen Mischungsverhältnis aus agilem und klassischem Projektmanagement zu finden. Dazu empfiehlt sich ein Blick auf die Argumente gegen eine 100-Prozent-Dosis:

Ausschlussfaktoren für ein „pures“ Wasserfall-Modell

  • Es fehlt die Anpassungsfähigkeit in einem sehr volatilen Projektumfeld. Dazu gehören insbesondere Compliance- oder Regulatorik-Projekte mit speziellen Vorgaben an die Risiko- und IT-Architektur, das Datenmanagement und die Risikoberichterstattung.
  • Der Kommunikationsfluss ist schwerfällig bei mehreren hundert Projektmitgliedern.
  • Es ist kaum möglich, Rücksprungpunkte mit fortlaufender Projektplanung einzubauen.

Ausschlussfaktoren für „pure“ Agilität:

  • Bei mehrjähriger Laufzeit gibt es keine Gesamtplanungssicht bis zum Projektende und keinen Blick auf das benötigte Gesamtbudget und die Gesamtressourcen.
  • Es existiert ein großes Maß an Basisdemokratie mit vielen Synchronisationsmeetings. Verfechter klar abgegrenzter Berichtswege und Verantwortlichkeiten werden es schwer haben.
  • Die unternehmensinternen Projektrichtlinien, also das Funktionshandbuch mit den Projektrollen sowie den Test- und Abnahmeprozessen, beschreiben – wenn überhaupt – nur ein agiles Projektvorgehen, Hilfestellungen für eine Skalierung existieren in der Regel nicht.

Die Projektwahrheit liegt in der Mitte

Das Management von IT-Großprojekten wird sich irgendwo zwischen agil und klassisch, zwischen Scrum, Kanban und Wasserfall bewegen. Skalierbare Frameworks, die den Anforderungen großer Projekte gerecht werden und mit klassischen Ansätzen kombinierbar sind, bieten sich als Baukasten für eine Hybridform an.

Diese Ansätze basieren auf klassischen agilen Prinzipien. Die bekannten Strukturen des Scrum-Vorgehens bleiben erhalten, sind aber in der Form angepasst, dass sie die gesteigerten Anforderungen und Abhängigkeiten berücksichtigen. Sie enthalten beispielsweise übergeordnete Synchronisationsebenen und zusätzliche Rollen.

Zu den wichtigsten Skalierungs-Frameworks in der Praxis zählen:

  • SAFe® (Scaled Agile Framework)
YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

  • LeSS (Large Scale Scrum)
YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

  • NexusTM
YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

  • Spotify-Engineering-Culture
Vimeo

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von Vimeo.
Mehr erfahren

Video laden

So lassen sich Skalierungs-Frameworks evaluieren und kombinieren

Die Frage, die sich Projektmanager häufig stellen lautet: Welches Skalierungs-Framework ist für mein Projekt das passende? Um das herauszufinden, empfiehlt es sich, das klassische Wasserfallmodell und ein Skalierungsframework gegenüberzustellen und beispielsweise mit einer klassischen Ratingskala zu bewerten. Die folgenden Dimensionen und Kriterien unterstützen dabei und beim Aufstellen von Pro-Contra-Listen.

A.: Projekt-Scope

  • Mächtigkeit des Projekts: Je nach Umfang und Tragweite sollte die Methode die Komplexität des Projektes mit Blick auf Größe, Abhängigkeiten und Kommunikationswege trennscharf abbilden können.
  • Abbildung einer Gesamtplanungssicht: Inwieweit kann ich mit dem Framework einen Blick auf das gesamte Projekt werfen, von Anfang bis Ende? Das ist wichtig für die Steuerung des Budgets und der Projektressourcen.
  • Reaktion auf Projektvolatilität: Was bietet mir die Methode, um schnell auf sich ändernde Rahmenbedingungen zu reagieren?
  • Abgrenzung der Verantwortlichkeiten und Berichtswege: Sieht die Methode vor, dass Verantwortlichkeiten geklärt und die Berichtswege transparent sind?

B.: Projektumfeld

  • Interne Methodenpräferenz: Inwieweit ist die Methode intern bekannt und wurden bereits Projekte nach der Methode organisiert?
  • Referenzprojekte: Gibt es bereits Best Practices zur Methode, auf denen sich aufbauen lässt.

C.: Unternehmens- und Projektkultur

  • Kompatibilität Projekt-Governance: Inwieweit verträgt sich die Methode mit internen Verfahren und Richtlinien bei der Projektabwicklung, beispielsweise mit Test- und Abnahmeprozessen.
  • Kompatibilität Projekt-Tools: Pluspunkte haben zudem Methoden, wenn sie zu den intern genutzten Planungs-Tools und Test-Werkzeugen passen.
  • Mindset: Die Mitarbeiterinnen und Mitarbeiter sollten eine Affinität für die Methode besitzen, die Chemie zwischen Mensch und Methode sollte stimmen.

D.: Projektteam

  • Skalierbarkeit der Projektteams: Die Methode ist auf Projektteams mit mehreren hundert Personen anwendbar.  
  • Kollaboration: Die Methode unterstützt die Vernetzung und Synchronisation der Einheiten untereinander, ohne Reibungsverluste zu erzeugen.
  • Schulungsaufwand: Know-how zur Methode ist im Unternehmen vorhanden oder leicht aufzubauen.

Häufig eingesetztes Projekt-Setting

Liegen sämtliche Einschätzungen zu den einzelnen Kriterien vor, können sich Unternehmen aus den Analyseergebnissen heraus die Framework-Elemente heraussuchen, die am besten zur individuellen Situation passen. Dabei können sie auch zwei oder mehr Projektmanagement-Frameworks zu einem hybriden „Best of“-Modell kombinieren.

In der Praxis hat sich bewährt, dass der inhaltliche Projektteil agil bearbeitet wird – eingebettet in eine klassische Projektsteuerung von Zeit, Budget, Ressourcen und Risiken.

  • Es gibt die klassische Dreiteilung der Projektebenen: Entscheidungsebene, Steuerungsebene, Umsetzungsebene
  • Die Steuerung von Zeit, Budget, Ressourcen und Risiken erfolgt auf der Entscheidungs- und Steuerungsebene mit klassischen Elementen und Rollen (z.B. Sponsor, Auftraggeber, Lenkungsausschuss, Projektleitung, Projekt Management Office)
  • Eine agil skalierte inhaltliche Abarbeitung auf der Umsetzungsebene kann beispielsweise in Form von Sprints durch die agilen Teams erfolgen (z.B. Feature Teams mit allen Scrum-Rollen)
  • Die inhaltliche Verantwortung wird sowohl auf der Umsetzungsebene (ein Team verantwortet ein Teilprodukt) als auch auf übergeordneter Ebene (gesamthaft für das Gesamtprodukt) verankert.
  • Vertikal eingezogene Schnittstellen sorgen für eine regelmäßige inhaltliche und methodische Synchronisation zwischen der Umsetzungsebene und Steuerungsebene
  • Die flankierende operative Projektsteuerung obliegt den klassischen Rollen auf der Steuerungsebene. 

Jedes Projekt ist anders, deshalb werden Unternehmen nicht umhinkommen, diese Bewertung bei Folgeprojekten zu wiederholen. Ein methodischer Ansatz unterstützt allerdings dabei, bestimmte Abläufe zu verkürzen und so schneller zu einem fundierten Ergebnis zu kommen. Zudem senken Unternehmen die Risiken für Projekt-Misserfolge, wie sie immer wieder vorkommen.     


Weitere Blogbeiträge zum Thema Agilität

Foto: Getty Images / Francesco Carta fotografo