Programm vs. Projekt – der richtige Management-Ansatz vermeidet Schieflage

Häufig werde ich gefragt, wo denn der Unterschied zwischen Programm- und Projektmanagement liege. In der Tat sind die Grenzen zwischen Programm vs. Projekt 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 wenig zur Veranschaulichung beitragen möchte.

Zu komplex für Projektmanagement-Methoden

Programme sind große, komplexe Initiativen, die in mehreren „Teilprojekten“ einzelne Module eines neuen Ergebnisses erstellen, anpassen und einführen sollen. Dazu ist meistens eine großangelegte Datenerfassung und ‑Migration oder ein Um- bzw. Einbau bestehender Anlagen und Ausrüstung nötig. Weiter muss man oft das (die) in mehreren Schritten einzuführende System (Anlage) bereits operativ betreiben und auch nach Abschluss der (Teil-)Implementierungen (weiter) supporten bzw. warten. Ein Programm umfasst also mehrere einzelne Komponenten, die aufeinander aufbauen und nur zusammen den letztendlich gewünschten Nutzen ergeben. Außerdem geht es im Allgemeinen schon von der Dimension und Dauer her über ein normales Projekt hinaus.

Und noch eine Besonderheit: Programme beginnen oft mit einer Vision, bei der noch niemand weiß, wie diese konkret Realität werden soll. Es gibt also nicht wie in Projekten eine Inhalts- und Umfangsbeschreibung, die man abarbeiten könnte, sondern diese muss erst entstehen: Viele Teilkomponenten müssen innerhalb des Programms erst erdacht und definiert werden, um dann später zum gemeinsamen Zielergebnis integriert werden zu können. Auch die Dauer eines Programms ist durch die Komplexität nicht immer festgelegt, und die sich auf dem Weg ergebenden Veränderungen können selbst das Ziel noch beeinflussen oder gar verändern.

Ein anschauliches Beispiel ist die erste Mondlandung, von J.F. Kennedy 1962 propagiert, noch im gleichen Jahrzehnt realisiert zu werden. Was es dazu gebraucht hat (Startrampe, Trägerrakete, Mondfähre, lebenserhaltende Systeme, Flugberechnung und -kontrolle usw.) musste erst erdacht und erfunden werden. Alle Flüge im Apollo-Programm vor Apollo 8 dienten ausschließlich der Erkundung und Erprobung des Systems vor der eigentlichen Mondreise. Und das Programm war mit dem Erfolg noch lange nicht abgeschlossen, sondern wurde zur weiteren Forschung und Verbesserung fortgeführt.

Den strategischen Nutzen maximieren

Nach der „reinen Lehre“ muss Programm-Management einen Mehrwert stiften, der durch das Management der einzelnen Komponenten nicht erreichbar ist. Die Aufgaben liegen insbesondere in der Koordination der Komponenten, dem Betrachten der Schnittstellen untereinander und mit der (Kunden-)Organisation, und darin, den Nutzen des Programms für den Kunden sicherzustellen. Ein Programm-Manager (PgM) muss zusätzlich zur operativen Leitung des Programms vor allem den Puls des Kunden fühlen, und abwägen, was am besten in die Strategie dessen Geschäfts passt. Seine strategische Nutzensicht unterscheidet ihn fundamental von der primär von der Lieferung geprägten Sicht eines Projektmanagers (PM).

Der Fokus auf die Maximierung des (Kunden-)Nutzens bedeutet auch, dass Änderungen nicht „notwendiges Übel“ am ursprünglich festgelegten (Projekt-)Inhalt und -Umfang sind, sondern implizit vorgesehen, so, wie sich die Notwendigkeit, z.B. in Gestalt zusätzlicher Komponenten, und/oder ein Zusatznutzen über die Laufzeit hinweg ergeben. Auch das unterscheidet PgM vom Multi- oder Super-PM, wo die Lieferleistungen und -Zeiträume zu Beginn festgelegt werden.

Programmmanager müssen anders denken als Projektmanager

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 verlies 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 hinzukommt.

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

Programmmanager 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, einer von Kunden- und einer von Lieferantenseite, meist gut ergänzen, ist im Programm oft ein gemeinsamer PgM als Stakeholder-Manager, Gesamtnutzen-Maximierer und Regisseur das bessere Setup.

Die Haupt-Stakeholder beider Seiten sitzen überdies 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, Verantwortlicher für das Sicherstellen des Nutzens und 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.

Der Erfolg entscheidet sich schon beim Setup

Damit wird aber auch implizit deutlich, dass bereits das Setup einer Initiative entscheidend ist, ob es richtig gemanagt werden kann oder nicht. Ein Down-Sizing von Programmen zu Groß- oder Multi-Projekten wird genauso wenig erfolgreich sein wie der Versuch, ein Programm mit Projektmanagement-Mitteln und -Denken zum Ziel zu führen. Der richtige Management-Ansatz von Anfang an vermeidet spätere Schieflage – und wenn es bereits passiert ist, kann ein Wechsel das Mittel der Wahl zur Stabilisierung sein. Man muss es aber verstehen, was ein Programm ausmacht…

Lesen Sie mehr zum Thema – klicken Sie hier …