Im vorliegenden Fall wurde ich in ein komplexes Großprojekt gerufen, das in mehreren "Teilprojekten" einzelne Module eines neuen IT-Systems erstellen, anpassen und einführen sollte, dazu eine großangelegte Datenerfassung und Migration umfasste, das in mehreren Schritten einzuführende System betreiben und auch nach Abschluss der Implementierung weiter supporten sollte.

Zu komplex für Projektmanagement-Methoden

Ganz klar: Es handelte sich nicht mehr um ein Projekt, sondern um ein Programm, denn die einzelnen Komponenten bauten aufeinander auf und ergaben nur zusammen den letztendlich gewünschten Nutzen für den Kunden. Außerdem ging es schon von der Dimension und Dauer her über ein normales Projekt hinaus.

Nicht nur abliefern, sondern Nutzen maximieren

Nach der "reinen Lehre", z.B. nach PMI, musste mein Programm-Management einen Mehrwert stiften, der durch das Management der einzelnen Komponenten nicht zu erreichen gewesen wäre. Meine Aufgaben lagen also insbesondere in der Koordination der Komponenten, dem Betrachten der Schnittstellen untereinander und mit der Kunden-Organisation, sowie darin, dass ich den Nutzen des Programms für den Kunden sicherstellte.

Ein Programm-Manager (PgM) muss demnach zusätzlich zur operativen Leitung des Programms vor allem den Puls des Kunden fühlen. Seine Nutzensicht unterscheidet ihn fundamental von der primär von der Lieferung geprägten Sicht eines Projektmanagers (PM).

Bildquelle: Henning Zeumer

In der Realität erwiesen sich die Rahmenbedingungen für dieses Rollenbild allerdings als nicht ideal: Den Kundenkontakt beanspruchte der Key Account Manager für sich, Änderungen am Vertrag sollten vermieden werden, und der Fokus des Programms sollte aus Lieferantensicht in der Sicherung der Meilensteine und der Marge liegen. Also nicht PgM, sondern Multi- oder Super-PM?!

Mit normalem Projektmanagement in die Krise geraten

Bei meinem Einstieg war das Großprojekt /Programm bereits in Schieflage: Der erste Meilenstein war geplatzt, der Kunde verweigerte trotz Lieferung aller Features die Teilabnahme, weil ihm die Usability und Performance nicht genügten. Im Vertrag stand dazu nichts. Überdies gab es mittlerweile ein paar neue Features, die der Kunde auch gern haben, der Lieferant aber erst nach Abschluss des ersten Vertrags angehen wollte. Die Situation war verfahren, es gab Hektik im Key Account und bei den Vertragsanwälten, mein Vorgänger verließ das Programm…

Bildquelle: Fotolia

Nun bekommt man die Verantwortung für ein solches Großprojekt /Programm nur, wenn man als PM schon richtig gute Leistungen gezeigt hat. Aber das allein genügt für ein Programm meist nicht, wenn nicht zusätzlich PgM-Methodik und -Handeln hinzukommen.

Ich musste also meinen Auftraggeber überzeugen, aus dem Großprojekt ein richtiges Programm zu machen, mit dem Kunden vornehmlich über dessen Nutzen sowie Business Case zu reden, und nutzenstiftende Änderungen als zielführend zu antizipieren. Der Kunde wiederum musste sich auf kostenpflichtige Change Requests einlassen, auch wenn er vertragsmäßig gerade am längeren Hebel saß.

Programm-Manager müssen anders denken als Projektmanager

Nur gemeinsam und mit Blick auf den Nutzen, den die Investition für den Kunden bringen soll, macht eine solche Sinn – schon bei Projekten, und noch viel mehr bei Programmen. Das ist im harten Business-Alltag sicher manchmal ein Spagat – denn auch für den Auftragnehmer muss es sich ja rentieren.

Wo sich im Projektmanagement zwei PMs von Kunden- und Lieferantenseite meist gut ergänzen, ist im Programm oft ein gemeinsamer einziger PgM als Stakeholder-Manager, Gesamtnutzen-Maximierer und Regisseur das bessere Setup. Oder – wie in meinem Programm – die Haupt-Stakeholder beider Seiten sitzen häufig genug zusammen und beraten mit Blick auf einen gemeinsamen Interessenausgleich, wohin die Reise gehen soll.

Dann wird der PgM zum Berater des Boards, zum Verantwortlichen für das Sicherstellen des Nutzens und zum Schnittstellen-Koordinator für die Programm-Komponenten. Nicht sinnvoll ist es, sich als Super-/Multi-PM auf die letztere Funktion zu beschränken, denn dann entkoppeln sich Delivery und angestrebter Nutzen schnell.

Auch ein als Projekt verfahrenes Programm kann gerettet werden

Nach der Sanierung fand die Geschichte jedoch ihr "Happy End": Das Programm erlebte einen nicht ganz schmerzlosen Umbau, konnte aber für alle Beteiligten erfolgreich abgeschlossen werden.

Es hat etwas länger gedauert als ursprünglich geplant, die Marge des Auftragnehmers ist etwas schmaler ausgefallen. Dafür ist der Kunde mit dem Gelieferten glücklich, da er mehr Qualität und Features bekommen hat, und die Investition hat sich für beide Seiten gelohnt.

Sicher aber wäre der Erfolg für den Lieferanten größer geworden, wenn die Initiative von Beginn an als Programm gemanagt worden wäre – ohne die etwas holprige Zwischenphase mit ungleichen Kräfteverhältnissen – und beide Seiten damit durchgängig mehr als Partner denn als Vertragsgegner agiert hätten.

Man muss es eben verstehen, was ein Programm ausmacht – und wie man ein solches richtig managt…