Umstände und Rahmenbedingungen

Die Umstände im Sinne von Komplexität der Organisation und dazugehöriger Abstimmungsprobleme und Aufwände waren typisch für ähnlich große Organisationen (Banken), hier jedoch in seiner Ausprägung außergewöhnlich herausfordernd. Das hatte großen Einfluss auf das angewendete Vorgehen.

Ein prägender Umstand war, dass der Bereich gerade dabei war eine neue – recht exotische - Projektmanagement Methode einzuführen, die zwingend angewendet werden musste.

Aufgrund von Sparmaßnahmen war die verantwortliche Abteilung auf nur noch eine Handvoll Mitarbeiter zusammengeschrumpft. In der Folge hatte es hier seit über einem Jahr kein einziges Produktionsrelease mehr gegeben.

Strikte Anwendung Projektstandards

Der überwiegende Teil der Projektmitglieder bestand aus externen Mitarbeitern, die zum einen beim Einstieg ins Projekt wenig bis hin zu keinen Kenntnissen des Systemumfelds bzw. der Fachlichkeit hatten und zum anderen alle ihre eigenen Arbeitsmethoden und Gewohnheiten mitbrachten.

Somit lag es auf der Hand Projektstandards einzuführen, um Konsistenz und vorhersehbare Qualität in der Umsetzung zu erreichen. Dafür wurden die wenigen internen Mitarbeiter aus der Umsetzung selber weitestgehend rausgehalten und bekamen nachfolgende übergreifende Aufgaben:

• Einweisung der neuen Projektmitarbeiter im Bereich Vorgehen, Methoden und Tools

• Erstellung der übergreifenden Konzepte, welche Basis für das technische Design und deren Umsetzung waren

• Kontinuierliche Durchführung von Code Reviews und Coachings

Darüber hinaus wurde ein bereits bestehender Review Prozess bzgl. Designdokumenten (Q-STAR) sehr gewissenhaft und stringent durchgeführt, wobei Kollegen aus allen Disziplinen (Analyse, Entwicklung und Test) an einem Review beteiligt waren.

 Stakeholder Management

Das Projektumfeld bestand aus einem komplexen Geflecht von Abhängigkeiten zu diversen Abteilungen und parallel laufenden Projekten, die alle primär ihre eigenen Interessen verfolgten. Außerdem gab es Reorganisationen unmittelbar vor und während des Projektverlaufes. Dazu mussten Projektteams immer um Ressourcen und Prioritäten kämpfen. Des Weiteren gab es einen äußerst umfangreichen Genehmigungsprozess für Produktionseinführungen, der sich über mehrere Abteilungen streckte und durchaus 4-6 Wochen dauern konnte.

Aus der Situation heraus habe ich ein sehr intensives Stakeholder Management betrieben, was folgendes beinhaltete:

• Zusammen mit meinem Auftraggeber habe ich einen Lenkungskreis etabliert, worin alle für das Projekt relevanten Bereiche der Organisation auf L2 Ebene vertreten waren. Ein Lenkungskreis war trotz eines sehr umfangreichen Methodengrundsatz in der Organisation interessanterweise keine Selbstverständlichkeit. Nach Einführung jedoch förderte dieser das Committment in der gesamten betroffenen Organisation. Zudem bot es einen Eskalationsmechanismus, welcher mit größter Vorsicht angewendet wurde.

• Zu anderen relevanten Projekten und Abteilungen habe ich aufwändige Lobbyarbeit betrieben und unter anderem regelmäßig Verhandlungen über Ressourcen und Prioritäten geführt.

• Ein Mitarbeiter war nur für die Bedienung der Genehmigungsprozesse für Produktionseinführungen zuständig.

• Zur Koordination mit der Abteilung, die für die Produktion verantwortlich war, habe ich einen ehemaligen Manager dieser Abteilung aus dem Vorruhestand zurückgeholt und freiberuflich eingesetzt.

 Prince2

Das prinzipielle Projektmanagement Vorgehen des Kunden war Prince2 basiert:

• Mein Vorgänger hatte ein ausführliches Projekt Initialisierungs-Dokument (PID) erstellt, worin sehr genau Umfang, Budget, Zeitvorgaben und Verantwortung festgelegt waren.

• Ich habe alle 2 Wochen einen Projekt Status Report (PSR) mit Statusmeldungen zu allen individuellen Projektmeilensteinen, Projektfinanzen und wesentlichen Issues und Risiken erstellt.

• Es gab Vorgaben für Risiko, Issue und Action Management inklusive Prozessen und Vorlagen.

• Zusätzlich habe ich einen ausführlichen End-of-Project Report erstellt, wo alle wesentlichen Ergebnisse, das angewandte Vorgehen und “Lessons Learned” zusammenfassend beschrieben wurden.
  

 CCPM / ToC

Critical Chain Project Management (CCPM) - Theory of Constraints (ToC)

Abweichend zum Unternehmensstandard wurde entschieden, die Projektmanagement Methode Critical Chain Project Management (CCPM), basierend auf der “Theory of Constraints (ToC)” abteilungs- und projektübergreifend einzuführen. Leider gab es in der Organisation bisher keine Erfahrungen mit dieser Methode, welche auch für mich neu war. Zudem stellte sich heraus, dass die Anwendung der Methode der Abstimmung von Meilensteinen mit anderen Abteilungen und Projekten im Weg stand - ein elementares Problem, da wir sehr viele kritische Abhängigkeiten hatten. Auf mehrfaches Bitten meinerseits wurde das Projekt nach einigen Monaten von der Anwendung der Methode wieder freigestellt.

Planung

In MS-Project habe ich detaillierte Projektpläne erstellt auf Basis von Schätzungen der Projektteammitglieder. Hierzu haben wir uns anfangs aber auch im Laufe des Projektes immer wieder zusammengesetzt. Mitarbeiter wurden hierin auf Aufgaben-Ebene eingeplant und die Auslastung der einzelnen Mitarbeiter ausgeglichen unter Berücksichtigung von Urlaub und sonstigen Abwesenheiten. Somit entstand eine schlüssige und belastbare Planung.

Task Management / Manager

Das Experiment mit CCPM hatte dem Projekt zusätzliche Herausforderungen bereitet, allerdings auch eine sehr positive Errungenschaft zufolge gehabt - nämlich die Rolle des Task Managers.

In CCPM schaut diese Person auf alle Aufgaben (Tasks)- insbesondere den kritischen - um Blockaden die dessen Fertigstellung nicht zulassen, aus dem Weg zu räumen. Diese Rolle haben wir auch nach Beendigung des Experimentes beibehalten, denn sie stellte sich bei der enormen Menge an Aufgaben als besonders hilfreich heraus.

Der Task Manager “jagte” jeder Aufgabe und jedem ToDo bei den Verantwortlichen kontinuierlich und unnachgiebig hinterher und die gesamte Liste wurde in den Meetings mit allen TPL‘s (zweimal pro Woche) durchgegangen.

Issue und Risiko Management

Issues wurden kontinuierlich verfolgt und nachgehalten, sowie daraus resultierende Aufgaben und ToDo’s. Auf regelmäßiger Basis wurden “Risiko Brainstorm Meetings” durchgeführt. Die identifizierten Risiken wurden mit Maßnahmen bzw. Aufgaben belegt und der Status der Risiken wurden aktiv verfolgt. Somit konnte vielen Problemen vorgebeugt werden und das Team war in der Lage, schneller und adäquater auf Issues zu reagieren.

Status Reporting

Gemäß Prince2 Vorgabe fand Status Reporting mittels eines Project Status Reports (PSR) statt. Dieser wurde zweiwöchentlich erstellt und im Lenkungskreis besprochen. Hierin wurde ausführlich berichtet über:

• Wesentliche Ergebnisse seit letztem Bericht

• Nächste Schritte/erwartete Ergebnisse in der kommenden Berichtsperiode

• Status der einzelnen Meilensteine

• Issues

• Wichtigste Risiken

• Projektfinanzen

Projekt Controlling

Das Projektmanagement Tool “Clarity” wurde eingeführt, um ein unternehmensweites einheitliches Projekt Controlling zu etablieren. Zwecks Ressourcen Management wurden die MS-Project Pläne hierin importiert. Die Meilensteine wurden hier ebenfalls übernommen. Zusätzlich zum PSR musste ich in Clarity zweiwöchentlich über die Meilensteine berichten.

Um über die Finanzplanung immer auskunftsfähig zu sein, entwarf ich zusätzlich ein ausführliches Spreadsheet-basiertes System, welches vom PMO Mitarbeiter gepflegt wurde:

• Es gab Excel-Stundenzettel pro Mitarbeiter, in welche ihre Aufgaben mit Start- und Enddatum aus dem MS-Project Plan übernommen wurden.

• Bei den Aufgaben trugen die Mitarbeiter jede Woche neben den geleisteten Stunden, auch Kommentare zu ihren Aufgaben und Planungen ein.

• Die berichteten Stunden wurden vom PMO im Projekt Controlling Spreadsheet importiert/übernommen.

Darauf basierend wurde die Budgetplanung überwacht und Finanzberichte in Clarity erstellt.

Programm Management

Der Kunde setzte Clarity auch für das Programm Management ein. Hierzu wurde wöchentliches Projektreporting bestehend aus einer Powerpoint Folie eingeführt, welches in Clarity hochgeladen wurde. Daraus stellte das Programm Office dann einen Gesamtbericht über alle Projekte für die Programmleitung namens IT Decision Committee (ITDC) zusammen. Hierin war die höchste Management Ebene (CIO der Bank) vertreten. Dieses Reporting stellte sich für Programmzwecke als beeindruckend effektiv heraus.

Test

Das Testteam arbeite nach der T-MAP Methodik. Das Wesentliche dabei war, dass zu jedem Release eine Risikoanalyse unter Einbeziehung der Fachbereiche gemacht wurde, und dass darauf basierend Schwerpunkte in den Testszenarien und Testfällen bestimmt wurden.