Wenn Projektmanagement nicht ausreicht – Programm-Management

Häufig werde ich in letzter Zeit gefragt, wo denn der Unterschied zwischen Programm- 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.

Wenn Projektmanagement nicht ausreicht – Programm-Management

Häufig werde ich in letzter Zeit gefragt, wo denn der Unterschied zwischen Programm- 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.

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).

Projekte und Programme

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…

Krise oder Chance?

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…

Unsere Abos: für jeden Bedarf das passende Abonnement

 

Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle,
die in Projekten arbeiten. Ihre Vorteile auf einen Blick

Image
Wissensplattform

Zugriff auf die größte deutschsprachige Wissensplattform
für Projektmanagement  (>1.800 Artikeln und Tipps)

Image
Praxisbezogene Beiträge

Praxisbezogene Beiträge
Fachautoren schreiben aus der Praxis für die Praxis.

Image
Tools

Werkzeuge (Tools)
z.B. Checklisten und Vorlagen, Methoden mit Schritt-für-Schritt-Anleitung.

Image
Glossar

Umfangreiches Projektmanagement-Glossar
über 1.000 Fachbegriffen (deutsch/englisch)

Image
Blogbeiträge

Blogbeiträge, Themenspecials, Bücher, Stellenangebote etc.
rund um das Thema Projektmanagement

Alle Kommentare (5)

Guest

Schöner Werbetext für die eigene Person - wenig Mehrwert für den Leser

 

Guest

da kann ich mich nur anschließen. Eine gute Einleitung - und dann? - wenn es wirklich interessant zu werden scheint ist Ende. Schade, denn Programm-Management ist noch eine ziemlich unbekannte Materie und jede praktische Anregung und Erfahrung was ein Programm ausmacht und wie man es aufsetzt, organisiert und steuert wäre hilfreich und interessant.

 

Guest

"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." Versteh ich nicht. Das wäre genau meine Begründung gewesen, warum es ein Projekt und nicht ein Programm ist. Bei einem Programm kann ich einzelne Projekte terminieren und der Rest kann trotzdem weiterlaufen. Bei einem Projekt kann ich nicht einfach ein Arbeitspaket streichen, denn das liefert wichtige Inputs für die anderen Arbeitspakete.

 

Guest

Wenn's einfach wäre könnte es ja jeder... ;-) Bei einem Programm sind die einzelnen Projekte in sich komplette Entitäten mit definierten Produkten. Diese können verändert, vorzeitig beendet oder auch neu aufgesetzt werden, je nachdem was für das Programm bzw. das Unternehmen den besten strategischen Nutzen erbringt. Die Nutzensicht anstelle der Produktsicht ist das Entscheidende. Wenn ich in einem Projekt Arbeitspakete oder Features weglasse, verändere ich die Qualität des Produkts (meist zum Negativen). Bei einem Programm ist das nicht so, denn ich ändere nur, wenn es besseren Nutzen ergibt. Andererseits muss ich aber auch offen für jede den Nutzen steigernde Änderung sein, also offen neue Anforderungen des Kunden mit ihm nutzenstiftend diskutieren. Das mag ein Projektmanager, der seinen vertraglichen Scope zu erfüllen hat, z.B. gar nicht - es sei denn die Erwartung seines Chefs ist, möglichst viele CRs für eine bessere Marge des Projekts zu platzieren. Dies ist der Grundgedanke des Programmmanagements. Aber genau wie im Projektmanagement gibt es hier sehr viele Facetten, von denen ich im Artikel aus Platzgründen halt nur einige anreißen konnte. Brauchbare Literatur findet sich aber leider noch wenig dazu, wohl auch weil das Thema und der Unterschied in der Praxis noch wenig bekannt ist oder erkannt wird. Es ist auch wie gesagt nicht ganz trivial zu verstehen. Und daher gibt es sicher viele Programme, die fälschlich als Projekte und damit suboptimal geführt werden.

 

Guest

Aus meiner mehrjährigen Erfahrung als Trainer für Programm-Management bei Integrata weiß ich, dass bei fast allen Teilnehmern begrifflich vieles unklar ist zwischen Projekt, Multiprojekt, Programm und Portfolio. Vielfach gibt es gar kein Projekt-Portfolio-Management und der Begriff Programm wird gerne für Großprojekte verwendet ohne die besonderen Möglichkeiten aber auch Anforderungen eines Programm Managements überhaupt zu reflektieren. Auch die Verbindung vom Programm Management zum Linien-Management, im Sinne der Anwendern der Ergebnisse der Projekte des Programms ist oft unklar. Mein Ressummee: etwas Geld in die Ausbildung sowohl von Projekt- Programm - und Portfolio- Managern zu stecken, zahlt sich immer aus.