Governance ohne Theater

Governance ohne Theater

Warum „jede Abteilung macht PM anders“ kein Vielfaltssignal ist – sondern ein teures Warnsignal

Hallo, meine lieben Projektleiter:innen im Projekt‑Dschungel!

Hier ist wieder euer Jörg Tausendfreund, Projektmanagement-Erklärer und ich starte heute mit einem Satz, den ich so oft höre, dass ich ihn inzwischen als Frühwarnsystem benutze:

„Bei uns macht jede Abteilung Projektmanagement ein bisschen anders.“

Klingt nett. Klingt tolerant. Klingt nach „Vielfalt“. In der Praxis heißt es fast immer:

• Steuerungsfähigkeit weg.

  
  

• Ressourcen überbucht.

  
  

• Konflikte vertagt.

  
  

• Abhängigkeiten kommen zu spät hoch. 

Und du zahlst dafür – mit Time‑to‑Market, Budgetdrift, Eskalationen und dem letzten Funken Motivation deines Teams.

Und bevor jetzt jemand sagt: „Ja, aber wir sind halt komplex“ – willkommen im Maschinenbau, in der Industrie und im Mittelstand ganz grundsätzlich.

Komplexität ist keine Ausrede, sondern euer Geschäftsmodell.

Die Frage ist nur: Steuert ihr sie – oder steuert sie euch?

Die unbequeme Wahrheit zuerst

Viele Unternehmen glauben, Governance sei Bürokratie. Templates. Gates.

„PMO‑Polizei“.

Und ja: So kann es enden – wenn man Governance falsch versteht.

Governance ist nicht mehr Regelwerk.

Governance ist mehr Entscheidungsfähigkeit.

• Prioritäten setzen,

  
  

• Konflikte entscheiden,

• Ressourcen schützen.

Nicht irgendwann – heute.

Wenn ich dir Governance in einem Satz verkaufen müsste, wäre es dieser:

Governance ist die Antwort auf „Wer entscheidet was – wann – mit welchen Informationen?“

Alles andere ist Theater mit PowerPoint.

Eine Szene, die du kennst:

Neuanlauf, der im Kalender austrocknet

Maschinenbau‑KMU, produktionsnaher Neuanlauf. Der Kunde drückt. Der Vertrieb drückt zurück. Die Linie drückt sowieso immer.

• Konstruktion arbeitet im „Änderungsschleifen‑Modus“.

  
  

• Einkauf kämpft mit Lieferzeiten und Alternativteilen.

  
  

• Produktion will Stabilität, keine Überraschungen.

  
  

• Qualität will saubere Nachweise.

  
  

• IT sagt: „Wir haben auch noch ein ERP‑Thema.“

  
  

• Und du als Projektleitung… sitzt dazwischen wie ein Flughafenlotse ohne Radar.

Dann passiert Folgendes:

1. Es werden Meetings gebaut, weil Entscheidungen fehlen.

   
   

2. Es werden Zwischenlösungen gemacht, weil Prioritäten unklar sind.

   
   

3. Es werden Engpassrollen (z. B. Test, Inbetriebnahme, SPS/Software, Konstruktion) überbucht – weil niemand „Nein“ sagen will.

   
   

4. Und während alle beschäftigt sind, sinkt die Lieferfähigkeit.

Du hast plötzlich fünf Projektpläne – und keinen Plan, der wirklich gilt. Weil jedes Ressort in seinem eigenen „PM‑Dialekt“ spricht und niemand die Schnittstellen regelt.

Der Kernfehler:

Einheitsmethode statt Interoperabilität

Wenn Wildwuchs nervt, kommt die typische Management‑Reaktion:

„Dann rollen wir jetzt eine Methode aus.“

Sieht sauber aus. Scheitert oft an Realität und Akzeptanz.

Warum? Weil du nicht „eine Methode“ brauchst.

Du brauchst Interoperabilität:

gemeinsame Schnittstellen, damit unterschiedliche Projekte trotzdem steuerbar sind.

Metapher für den Maschinenbau: Du brauchst nicht, dass jeder denselben Schraubendreher benutzt. Du brauchst, dass alle dieselben Gewinde und Anzugsmomente verstehen.

Drei Governance‑Fragen, die alles entlarven

Wenn du nur einen Teil dieses Blogs liest, dann diesen. Stell diese Fragen – und beobachte, wie schnell das „PM‑anders“ plötzlich teuer wird:

Die 3 Governance‑Fragen

1. Welche Entscheidung muss heute getroffen werden – und wer trifft sie?

   
   

2. Welche Engpassressource blockiert uns wirklich – und wer priorisiert sie?

   
   

3. Was beenden wir bewusst, damit anderes fertig wird?

Wenn du auf eine dieser Fragen keine klare Antwort bekommst, hast du keine Governance. Du hast Hoffnung. Und Hoffnung ist keine Steuerungslogik.

Die Lösung:

Ein Projekt‑Betriebssystem – minimal, aber verbindlich

Ich nenne es gern ein Minimal Viable Project Operating System.

Nicht, weil ich Englisch so sexy finde (tue ich nicht), sondern weil es den Kern trifft:

• Minimal: so wenig wie möglich

  
  

• Viable: aber so viel wie nötig, damit Steuerung funktioniert

  
  

• Operating System: nicht „Methodenreligion“, sondern Betriebslogik

Wenn dir das zu steif klingt, nenn es einfach Projekt‑Betriebssystem.

Hauptsache: Ihr habt ein gemeinsames Minimum.

Das Projekt‑Betriebssystem besteht aus 6 Bausteinen

1) Gemeinsame Sprache (10–15 Begriffe)

Nicht mehr. Aber diese Begriffe müssen sitzen.

Beispiele: „fertig“, „Abnahme“, „Go‑Live“, „Pilot“, „Serie“, „Projekt vs. Linie“.

Warum? Weil sonst jeder dieselben Wörter sagt – und andere Dinge meint.

2) Projektklassen S/M/L

Nicht jedes Vorhaben braucht denselben Governance‑Overhead.

Drei Klassen nach Risiko/Impact reichen.

Pro Klasse ein paar Leitplanken – kein Methodenhandbuch.

3) Entscheidungslandkarte (1 Seite)

Das ist der wichtigste Teil: Wer priorisiert?

Wer entscheidet bei Ressourcenkonflikt?

Wo sind Eskalationsschwellen?

Wenn das nicht klar ist, ist alles andere Deko.

4) Intake‑ und Portfolio‑Takt

Eine Tür rein. Nicht fünf.

Und ja: Projekte dürfen On hold oder Stop sein – offiziell, nicht heimlich.

Rhythmus: alle 2–4 Wochen ein kurzer Portfolio‑Check, der Entscheidungen erzwingt.

5) Mindesttransparenz über Trigger

Du willst keine Dauerberichte. Du willst „Entscheidungsauslöser“.

Fünf Trigger reichen:

• Engpasskonflikt,

• Nutzen kippt,

• Risiko eskaliert,

• Abhängigkeit blockiert,

• Scope‑Schwenk.

6) Toolbox statt Pflichtset

Eine gemeinsame Toolbox ist gut.

Ein Pflichtset ist oft Gift.

Werkzeuge nach Projektklasse wählen – nicht nach „wir machen das hier immer so“.

Mini‑Blick auf Portfolio‑Chaos: Warum Neuanläufe oft nicht an Technik scheitern

Viele Neuanläufe scheitern nicht an der Konstruktion. Sie scheitern daran, dass parallel 20 „eigentlich auch wichtige“ Vorhaben laufen.

Dann passiert das Unausweichliche:

• Engpassrollen werden auf 140% geplant.

  
  

• Alles ist „kritisch“.

  
  

• Nichts wird fertig.

Das ist kein PM‑Problem. Das ist ein Priorisierungsproblem. Und Priorisierung ist Führung.

Der 90‑Tage‑Weg ohne Big‑Bang

Du brauchst keinen Organisationsumbau. Du brauchst einen Takt, der Entscheidungen erzwingt und Engpässe schützt.

Phase 1: Tage 0–30 – Wahrheit & Priorisierung

• Projektinventur (inkl. Schattenprojekte – ja, die existieren immer).

• Erste S/M/L‑Klassifikation.

• Entscheidet: Top 10 / Next / On hold / Stop.Nicht diskutieren. Entscheiden.

Phase 2: Tage 31–60 – Projekt‑Betriebssystem v1

• Entscheidungslandkarte auf eine Seite.

• Intake‑Regel: Ohne Sponsor keine Ressourcenbindung (sonst sammelt ihr nur Arbeit).

• Mindesttransparenz‑Trigger setzen, damit Entscheidungen kommen, bevor’s brennt.

Phase 3: Tage 61–90 – Verankern über Community, nicht über Polizei

• Community of Practice starten (kurz, praktisch: 1 Thema, 1 Muster, 1 Tool).

• Zwei Piloten: unterschiedliche Methoden, aber gleiche Schnittstellen.

• Wirkungssignal‑Review: Was hat sich spürbar verbessert?

Woran du erkennst, dass es wirkt

– ohne KPI‑Theater

Bitte miss nicht 30 Kennzahlen. Das macht nur neue Meetings.

Miss vier Reibungspunkte – die reichen:

1. Engpass‑Overbooking Wie oft sind kritische Rollen >100% verplant?

   
   

2. Entscheidungsdurchlaufzeit Wie lange dauert eine Prioritäts‑ oder Scope‑Entscheidung?

   
   

3. WIP vs Done  Wie viele Vorhaben laufen – wie viele werden fertig?

   
   

4. Überraschungseskalationen Wie oft kommt ein Blocker „plötzlich“ hoch?

Wenn diese vier besser werden, ist Governance keine Theorie mehr. Dann ist sie fühlbar.

Kurzer KI‑Absatz, weil 2026 nun mal 2026 ist

KI ist nicht der Ursprung eurer Governance‑Probleme. Aber KI macht Wildwuchs schneller sichtbar:

Wenn ihr heute schon fünf Projektlogiken habt, dann habt ihr morgen fünf Prompt‑Logiken, fünf Reporting‑Stile und fünf „Wahrheiten“ im Dashboard.

KI skaliert nicht nur Produktivität – sie skaliert auch Inkonsistenz.

Deshalb: Erst Minimum an gemeinsamen Schnittstellen. Dann KI‑Tempo.

Der praktische Selbstcheck:

5 Fragen, die ehrlich sein dürfen

Mach ihn nicht allein. Mach ihn mit 2–4 Schlüsselrollen.

Und ja: Ehrlich sein ist der ganze Punkt.

Also…

1. Wer setzt bei euch Prioritäten – wirklich?  (nicht „im Prinzip“)

   
   

2. Welche Engpassrollen schützt ihr aktiv – und wer darf sie verplanen?

   
   

3. Welche Entscheidung wird seit Wochen vertagt, obwohl sie euch stoppen oder beschleunigen würde?

   
   

4. Welche 10 Begriffe versteht jede Abteilung anders?  („fertig“, „Abnahme“, „Go‑Live“ …)

   
   

5. Woran merkt ihr in 30 Tagen konkret, dass Reibung weniger wird?  (nicht „Gefühl“, sondern Signal)

👉 Mach den Check im Team. Nicht für die Antworten – für das Gespräch, das danach entsteht.

Fazit:

Governance ist kein Korsett.

Governance ist euer Lenkrad.

Wenn jede Abteilung PM anders macht, ist das selten kreativ. Meist ist es ein Symptom:

• Steuerung fehlt.

  
  

• Prioritäten sind verhandelbar.

  
  

• Engpässe werden verheizt.

Die Lösung ist nicht Einheitsmethode.

Die Lösung ist ein Minimum an gemeinsamen Schnittstellen:

• Sprache,

  
  

• Projektklassen,

  
  

• Entscheidungslandkarte,

  
  

• Intake‑Takt,

• Trigger,

• Toolbox.

Wenn ihr das sauber zieht, habt ihr in 90 Tagen spürbar mehr Ruhe im System – und deutlich weniger Theater.

Bis zum nächsten Mal.

Jörg Tausendfreund

Projektmanagement-Erklärer & Verfechter von Regeln und gemeinsamem Vorgehen im Projekt

P.S.: Wenn dir jemand sagt „Governance macht alles nur langsamer“, frag freundlich: „Interessant. Wer entscheidet dann heute, was wir stoppen – damit das Wichtige fertig wird?“ Danach wird es meistens… sehr still.