Häufig werde ich in letzter Zeit gefragt, wo denn der Unterschied zwischen Programmmanagement und Projektmanagement liege. In der Tat sind die Grenzen in der Praxis oft fließend, werden die Strukturen, Rollen und Aufgaben nicht immer trennscharf definiert und gelebt. Und genau da liegen die Fallstricke für einen Programm-Manager, die Erwartungen der Stakeholder zu erfüllen, weshalb ich heute einmal ein Beispiel zur Veranschaulichung vorstellen möchte.
Zu komplex für Projektmanagement-Methoden
Im vorliegenden Fall wurde ich zu einer großen, komplexen Initiative gerufen, die in mehreren „Teilprojekten“ einzelne Module eines neuen IT-Systems erstellen, anpassen und einführen sollte, dazu eine großangelegte Datenerfassung und ‑Migration umfasste, dieses in mehreren Schritten einzuführende System betreiben und auch nach Abschluss der Implementierung weiter supporten sollte.
Ganz klar: das war 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. Das musste schiefgehen, auch wenn man es mit gutem Projektmanagement leiten wollte.
Nicht nur abliefern, sondern Nutzen maximieren
Nach der „reinen Lehre“ musste mein Programmmanagement einen Mehrwert stiften, der durch das Management der einzelnen Komponenten nicht erreichbar gewesen wäre. Meine Aufgaben lagen also insbesondere in der Koordination der Komponenten, dem Betrachten der Schnittstellen untereinander und mit der Kunden-Organisation, und darin, dass ich den Nutzen des Programms für den Kunden sicherstellte. Diese strategische Nutzensicht für den Kunden unterscheidet im Programmmanagement fundamental von der primär von der operativen Lieferung geprägten Sicht eines Projektmanagers (PM).
In der Realität erwiesen sich die Rahmenbedingungen allerdings für dieses Rollenbild nicht als 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 geraten Programme in die Krise
Bei meinem Boarding war das Programm bereits in Schieflage: erster Meilenstein geplatzt, der Kunde verweigerte die Teilabnahme trotz Lieferung aller Features, weil ihm die Usability und Performance nicht genügte. 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. Verfahrene Situation, Hektik im Key Account und bei den Vertragsanwälten, mein Vorgänger verließ das Programm…
Nun bekommt man nicht die Verantwortung für solch eine Riesen-Initiative, wenn man nicht als PM schon richtig gute Leistungen gezeigt hat. Aber das allein genügt für ein Programm meist nicht, wenn nicht zusätzliche 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 und 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ß.
Programmmanagement funktioniert nur gemeinsam
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. Also musste ich die verfahrenen Positionen (und auch die bereits festgezurrten Claims) zwischen den Parteien auflösen und zurück auf die gemeinsamen Interessen an der Initiative führen.
Das Eingehen meines Auftraggebers auf die Kundenwünsche zur Änderung und Erweiterung des Umfangs nach dem aktuellen Stand der Geschäftsbedürfnisse einerseits und der Neuentwicklung verfügbarer Features und Module andererseits sowie die Bereitschaft des Kunden, dafür auch einen angemessenen Obolus zu entrichten, die benötigte Zeit einzuräumen und Ressourcen bereitzustellen, schlugen schließlich den Knoten entzwei. Hatte man sich vorher über Vertragsinhalte gestritten und sich gegenseitig „belauert“, zog man nun wieder gemeinsam an einem Strang und auch in die gleiche Richtung.
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 als ursprünglich geplant gedauert, die Marge des Auftragnehmers ist etwas schmaler ausgefallen. Dafür ist der Kunde mit dem Gelieferten mit mehr Qualität und Features glücklich, 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 damit durchgängig mehr als Partner denn als Vertragsgegner.
Man muss es eben verstehen, was ein Programm ausmacht – und wie man ein solches richtig managt…
Mehr zum Thema Programmmanagement: Lesen Sie auch…