PMO ist tot – Entwicklungsteams brauchen keine Kontrolle von außen

Warum klassisches PMO in modernen Entwicklungsteams nicht mehr funktioniert – und was stattdessen hilft. Eine klare, provokante Einschätzung.

PMO ist tot. Ich schreibe das mit voller Absicht so zugespitzt, weil das Thema zu wichtig ist, um es diplomatisch zu verpacken. Entwicklungsteams brauchen keine externe Kontrollinstanz mehr, die ihnen vorschreibt, wie sie zu arbeiten haben. Die guten Teams brauchen es ohnehin nicht, die schlechten werden es durch PMO nicht besser. Und dazwischen ist kaum noch Raum.

Ich habe mehr Meetings mit Projektmanagern, Product Ownern und Projektbüros hinter mir, als gesund ist. Ich habe Teams erlebt, die durch gutes Management geblüht haben, und ich habe Teams erlebt, die durch den Standard-Apparat eines klassischen PMO erstickt sind. Der Unterschied war nie der Name der Rolle. Der Unterschied war, ob die Menschen, die diese Rolle ausgefüllt haben, den Teams Arbeit abgenommen oder aufgebürdet haben.

Was PMO ursprünglich wollte

Das klassische Project Management Office ist aus einer sinnvollen Idee entstanden. In großen Unternehmen mit vielen parallelen Projekten gab es Chaos. Budgets liefen aus dem Ruder. Abhängigkeiten waren unklar. Prioritäten waren nicht gesetzt. Also kam ein Gremium, das Standards definiert, Risiken abwägt, Portfolios plant und Reports zusammenführt. In der Welt der 1990er und frühen 2000er Jahre war das oft die einzig mögliche Antwort.

Das Problem ist: Wir leben nicht mehr in dieser Welt. Entwicklungsteams haben heute Werkzeuge, die Transparenz fast kostenlos liefern. Pull-Requests sind nachvollziehbar, Deployments sind dokumentiert, Issue-Tracker zeigen Fortschritt in Echtzeit. Ein Manager, der Transparenz herstellen soll, tritt in vielen Unternehmen in einen Raum, in dem bereits alle Fenster offen sind. Er produziert dann Transparenz zweiter Ordnung – Transparenz über die Transparenz – und das ist genau der Moment, in dem Bürokratie entsteht.

Wo PMO heute wirklich schadet

Ich sehe drei konkrete Muster, in denen PMO schadet. Erstens: Status-Theater. Teams müssen wöchentlich Folien bauen, in denen sie erklären, was in ihren Tickets eh schon steht. Das bindet Entwickler-Zeit, die produktiv wäre, und es zwingt alle Beteiligten in eine Sprache, die nie fürs Bauen gedacht war.

Zweitens: Entscheidungsstau. Wenn zwischen dem Team und der echten Entscheidung drei Gremien liegen, dann werden Entscheidungen langsam und defensiv. Das ist das Gegenteil dessen, was ein gutes Engineering-Team braucht. Entwicklerinnen und Entwickler lösen Probleme am besten, wenn sie nah am Problem sind und Konsequenzen tragen. Ein entkoppeltes PMO entkoppelt genau diese Kette.

Drittens: Verantwortungsdiffusion. In Teams mit klassischem PMO wird am Ende nicht mehr klar, wer worum zuständig ist. Das Team sagt, der PM sei verantwortlich. Der PM sagt, das Business sei verantwortlich. Das Business sagt, das Team müsse entscheiden. Die Folge ist, dass niemand mehr wirklich entscheidet, und Projekte rutschen in einen Zustand, in dem viel diskutiert und wenig gebaut wird.

Was stattdessen hilft

Ich halte nichts davon, gegen etwas zu wettern, ohne eine Alternative zu nennen. Was ich in den letzten Jahren in funktionierenden Teams gesehen habe, ist eine andere Art von Struktur. Selbstorganisierte Teams mit klarer Outcome-Verantwortung. Ein oder zwei Menschen, die als Engineering-Management nicht kontrollieren, sondern Hindernisse wegräumen. Eine dünne, aber verbindliche Ebene, die Unternehmenskontext einbringt und Teams vor sich selbst schützt, wenn es sein muss.

Das ist weniger ein „PMO“ im alten Sinne, sondern ein „Enablement Office“. Sein Job ist nicht, dem Team zu sagen, was es tut. Sein Job ist, dafür zu sorgen, dass das Team tun kann, was es tut. Budget zu verteidigen. Blockaden außerhalb des Teams zu lösen. Unternehmensstrategie in eine Sprache zu übersetzen, die im Team anschlussfähig ist.

Das ist ein anderes Mindset. Und ja, es erfordert Menschen mit anderen Fähigkeiten als im klassischen PMO. Es erfordert Ruhe, Vertrauen und einen sehr sauberen Umgang mit Macht. Das ist selten, und deshalb ist gutes Engineering-Management auch selten.

Meine Haltung

Ich arbeite seit vielen Jahren in Strukturen, in denen Teams so viel Autonomie wie irgend möglich haben. Das ist nicht Laissez-faire. Das ist strenge Disziplin an anderen Stellen. Klare Ziele, klare Rollen, klare Erwartungen. Aber innerhalb dieses Rahmens entscheidet das Team. Und das Team liefert.

Wenn ich Unternehmen begleite, die sich in diese Richtung bewegen wollen, ist der erste Schritt oft nicht „wir führen ein neues Framework ein“. Der erste Schritt ist, zu sehen, wie viel Zeit, Energie und Moral gerade in Ritualen verbrannt wird, die niemand mehr braucht. Das auszumisten, ist die unterschätzteste Führungsleistung unserer Zeit.

PMO als Begriff wird es weiter geben. Manche werden ihn sinnvoll mit Leben füllen. Für mich ist die klassische Version tot. Und ich finde das nicht traurig. Ich finde es fällig.