Vor einem Jahr wurde ich zu einem gescheiterten SAP-Rollout gerufen. Budget überschritten, Zeitplan gerissen, Stakeholder frustriert.
Der Programmleiter war ein hervorragender Manager. Er hatte 15 Jahre Erfahrung in der Linie. Er führte eine Abteilung mit 80 Mitarbeitern. Seine Leute respektierten ihn. Seine Zahlen stimmten.
Aber das Programm war eine Katastrophe.
Als ich ihn fragte, was schiefgelaufen war, sagte er: »Ich verstehe es nicht. Ich mache das, was immer funktioniert hat. Aber hier funktioniert es nicht.«
Das war das Problem. Er machte das, was in der Linie funktioniert. Aber Programme sind keine Linienorganisationen.
Und die Fähigkeiten, die ihn zum erfolgreichen Manager gemacht haben, waren genau die, die ihn als Programmleiter scheitern ließen.
In den meisten Unternehmen läuft es so:
Ein großes Transformationsprogramm steht an. Man braucht jemanden, der es leitet. Und wen nimmt man?
Einen erfolgreichen Abteilungsleiter. Jemanden, der gezeigt hat, dass er eine Organisation führen kann. Jemanden, der Vertrauen genießt.
Das klingt logisch. Aber es ist ein Fehler.
Denn Linienmanagement und Programmsteuerung sind fundamental verschiedene Disziplinen. Die Fähigkeiten überschneiden sich — aber sie sind nicht die gleichen.
Und in drei entscheidenden Punkten sind sie sogar gegensätzlich.
Ein guter Linienmanager schafft Stabilität.
Er baut Routinen auf. Er definiert klare Prozesse. Er sorgt dafür, dass die Organisation vorhersehbar funktioniert.
Das ist sein Job. Die Linie soll laufen. Jeden Tag. Ohne Überraschungen.
Ein guter Programmleiter schafft Veränderung.
Er bricht Routinen auf. Er hinterfragt Prozesse. Er sorgt dafür, dass die Organisation sich bewegt — auch wenn das unbequem ist.
Das ist der erste fundamentale Unterschied: Der Linienmanager optimiert das Bestehende. Der Programmleiter ersetzt es.
Was in der Linie eine Tugend ist — Stabilität schaffen — ist im Programm ein Problem.
Ich habe das bei dem SAP-Rollout gesehen. Der Programmleiter hatte versucht, das Programm wie eine Abteilung zu führen. Er hatte Routinen aufgebaut. Regelmäßige Meetings. Feste Strukturen. Klare Prozesse.
Aber ein Programm braucht keine Stabilität. Es braucht Dynamik.
Wenn ein Stakeholder seine Meinung ändert, muss man reagieren — sofort. Wenn ein Risiko auftaucht, muss man umplanen — radikal. Wenn eine Annahme sich als falsch herausstellt, muss man den Kurs ändern — ohne zu zögern.
Ein Linienmanager, der auf Stabilität trainiert ist, tut sich damit schwer. Er versucht, das Programm zu stabilisieren. Aber das ist der falsche Instinkt.
Ich habe das Programm übernommen und die erste Sache, die ich gemacht habe: Ich habe die festen Meeting-Strukturen aufgelöst.
Keine wöchentlichen Jour-fixes mehr. Keine starren Agenden. Keine Protokolle, die drei Tage brauchen, bis sie freigegeben sind.
Stattdessen: Meetings, wenn etwas zu entscheiden ist. Agenden, die sich an der aktuellen Situation orientieren. Entscheidungen, die dokumentiert werden — aber nicht durch Gremien laufen.
Das hat funktioniert. Weil das Programm wieder beweglich wurde.
Ein guter Linienmanager arbeitet mit Hierarchie.
Er hat ein Team. Er gibt Anweisungen. Sein Team führt aus. Die Verantwortungslinien sind klar.
Ein guter Programmleiter arbeitet mit Netzwerken.
Er hat kein Team — er hat Stakeholder. Er gibt keine Anweisungen — er verhandelt. Die Verantwortungslinien sind unklar.
Das ist der zweite fundamentale Unterschied: Der Linienmanager steuert durch Macht. Der Programmleiter steuert durch Einfluss.
In der Linie funktioniert Hierarchie. Wenn der Abteilungsleiter sagt »Das machen wir so«, dann wird es so gemacht. Die Mitarbeiter sind ihm unterstellt.
Im Programm funktioniert das nicht. Der Programmleiter hat keine disziplinarische Macht über die Stakeholder. Er kann nicht anordnen. Er muss überzeugen.
Und das ist eine völlig andere Fähigkeit.
Ich habe Linienmanager gesehen, die in ihren Abteilungen brillant waren — aber im Programm hilflos. Weil sie gewohnt waren, dass ihre Anweisungen befolgt werden.
Im Programm wurden ihre Anweisungen ignoriert. Nicht aus Böswilligkeit — sondern weil niemand verpflichtet war, ihnen zu folgen.
Beim SAP-Rollout hatte der Programmleiter versucht, die Stakeholder wie Mitarbeiter zu behandeln. Er hatte Aufgaben verteilt. Er hatte Deadlines gesetzt. Er hatte erwartet, dass die Leute liefern.
Aber die Stakeholder waren keine Mitarbeiter. Sie hatten ihre eigenen Prioritäten. Ihre eigenen Chefs. Ihre eigenen KPIs.
Als ich das Programm übernommen habe, habe ich die Stakeholder nicht wie ein Team behandelt. Ich habe sie wie Partner behandelt.
Ich bin zu jedem einzeln gegangen. Ich habe gefragt: »Was brauchen Sie, um das mitzutragen?« Ich habe verhandelt. Ich habe Kompromisse geschlossen.
Das hat Zeit gekostet. Aber es hat funktioniert. Weil die Stakeholder sich eingebunden gefühlt haben — nicht kommandiert.
Ein guter Linienmanager baut für die Ewigkeit.
Er denkt langfristig. Er investiert in Menschen. Er schafft Strukturen, die über Jahre hinweg funktionieren.
Ein guter Programmleiter baut für die Übergabe.
Er denkt in Phasen. Er investiert in Deliverables. Er schafft Strukturen, die sich selbst auflösen, sobald das Programm fertig ist.
Das ist der dritte fundamentale Unterschied: Der Linienmanager baut eine Organisation. Der Programmleiter baut eine Transition.
In der Linie ist Kontinuität eine Tugend. Man will nicht, dass alles neu erfunden wird, wenn ein Manager geht. Man will Stabilität.
Im Programm ist Kontinuität ein Problem. Ein Programm, das nicht endet, ist kein Programm — es ist eine Dauerbaustelle.
Ich habe Programme gesehen, die seit Jahren laufen. Weil niemand den Mut hatte, sie abzuschließen. Weil der Programmleiter dachte: »Ich muss das perfekt machen.«
Aber perfekt gibt es nicht. Es gibt nur: gut genug, um es an die Linie zu übergeben.
Beim SAP-Rollout hatte der Programmleiter versucht, eine perfekte Struktur aufzubauen. Er wollte sicherstellen, dass alles läuft, bevor er übergibt.
Aber das führte dazu, dass das Programm nie endete. Es gab immer noch eine Optimierung. Noch eine Anpassung. Noch ein Feature.
Als ich das Programm übernommen habe, habe ich eine klare Linie gezogen: Was muss funktionieren, damit die Linie übernehmen kann? Alles andere ist optional.
Wir haben das Programm in vier Monaten abgeschlossen. Nicht perfekt. Aber funktionsfähig.
Und die Linie hat übernommen. Und die Optimierungen? Die kamen später — in der Linie, wo sie hingehören.
Wenn Linienmanagement und Programmsteuerung so verschieden sind — warum nehmen Unternehmen dann immer Linienmanager als Programmleiter?
Drei Gründe:
Erstens: Linienmanager sind verfügbar. Sie sind im Unternehmen. Man kennt sie. Man vertraut ihnen.
Zweitens: Linienmanager haben bewiesen, dass sie führen können. Das ist beruhigend. Man denkt: »Wenn er eine Abteilung führen kann, kann er auch ein Programm führen.«
Drittens: Programme sind teuer. Man will kein Risiko eingehen. Also nimmt man jemanden, der schon erfolgreich war — auch wenn es in einem anderen Kontext war.
Das Problem: Diese Logik ignoriert, dass die Fähigkeiten verschieden sind.
Ein guter Chirurg ist nicht automatisch ein guter Hausarzt. Beide sind Ärzte. Aber die Fähigkeiten sind verschieden.
Genauso: Ein guter Linienmanager ist nicht automatisch ein guter Programmleiter.
Ich habe in 25 Jahren hunderte von Programmleitern gesehen. Erfolgreiche und gescheiterte. Und die erfolgreichen haben drei Dinge gemeinsam:
Erstens: Sie akzeptieren Unsicherheit. Sie versuchen nicht, das Programm zu stabilisieren. Sie akzeptieren, dass es dynamisch ist — und arbeiten damit.
Zweitens: Sie steuern durch Einfluss, nicht durch Macht. Sie wissen, dass sie keine Hierarchie haben — und nutzen stattdessen Netzwerke.
Drittens: Sie bauen für die Übergabe, nicht für die Ewigkeit. Sie wissen, dass ein Programm enden muss — und planen das von Anfang an.
Das sind keine Eigenschaften, die man in der Linie lernt. Man kann sie lernen — aber nicht durch Linienerfahrung.
Man lernt sie durch Programme. Durch Scheitern. Durch Trial and Error.
Wenn Sie gerade ein großes Programm planen — und überlegen, wer es leiten soll — dann fragen Sie sich nicht:
»Wer ist der beste Manager?«
Sondern:
»Wer kann mit Unsicherheit umgehen? Wer steuert durch Einfluss? Wer denkt in Übergaben statt in Strukturen?«
Das kann ein Linienmanager sein — wenn er diese Fähigkeiten hat.
Aber es ist nicht automatisch ein Linienmanager. Nur weil jemand eine Abteilung führen kann.
Programmsteuerung ist eine eigene Disziplin. Und sie braucht eigene Fähigkeiten.
Wenn Sie das verstehen — und danach besetzen — haben Ihre Programme eine deutlich höhere Erfolgschance.
Über den Autor
Rainer V. Hiller ist Senior Program Manager mit 25 Jahren Erfahrung in der Steuerung komplexer Transformationsprogramme — spezialisiert auf regulierte Umfelder, Organisationsrückbau und Compliance-konforme Cloud-Transformation.
Er ist ab sofort verfügbar für Interim-Mandate.
Kontakt: rainer.hiller@dxb-41.consulting
