Linie vs. Projekt
- Jörg Tausendfreund
- 9. Juni
- 9 Min. Lesezeit

Ihr habt kein Kommunikationsproblem.
Ihr habt ein Entscheidungsproblem.
Hallo, meine lieben Schnittstellenakrobaten, Ressourcenflüsterer und Freunde der gepflegten Abstimmungsschleife!
Hier ist wieder Jörg Tausendfreund und es gibt einen Satz, der in Projekten erstaunlich oft fällt und fast immer nach Vernunft klingt:
„Wir müssen besser kommunizieren.“
Klingt gut. Klingt kooperativ. Klingt nach erwachsenen Menschen mit Meetingraum und Moderationskarten. Nur leider ist es oft die falsche Medizin.
Natürlich kann schlechte Kommunikation Projekte beschädigen. Keine Frage. Unklare Erwartungen, fehlende Transparenz, politische Zwischentöne und schlecht informierte Stakeholder sind echte Risiken.
Aber viele Projekte scheitern nicht daran, dass zu wenig gesprochen wird.
Sie scheitern daran, dass niemand entscheidet, wenn Linienlogik und Projektlogik kollidieren.
Und genau da wird es spannend. Oder, um es weniger freundlich zu sagen:
Ihr könnt noch so viele Abstimmungsmeetings einrichten. Wenn niemand klärt, was gilt, wenn das Tagesgeschäft die Projektressource zurückhaben will, habt ihr kein Kommunikationsproblem.
Ihr habt ein Entscheidungsproblem mit Kalenderanhang.
Die Szene, die fast jeder kennt
Das Projekt ist offiziell strategisch wichtig.
Natürlich.
In der Präsentation steht Top-Priorität. Der Sponsor sagt Rückendeckung zu. Die Projektleitung plant sauber. Die Linie nickt. Das Team startet. Alle sind motiviert. Der Projektauftrag klingt vernünftig. Die Ampel ist selbstverständlich grün.
Drei Wochen später brennt das Tagesgeschäft. Eine Schlüsselperson wird aus dem Projekt gezogen. Nur kurz. Nur diese Woche. Nur ausnahmsweise. Nur weil es wirklich nicht anders geht.
Danach beginnt das bekannte Ritual:
Ein Abstimmungsmeeting.
Ein aktualisierter Statusbericht.
Ein Gespräch mit der Bereichsleitung.
Eine neue Planung.
Ein bisschen Frust.
Ein bisschen Verständnis.
Ein bisschen „wir müssen das gemeinsam lösen“.
Alle bleiben freundlich. Niemand will blockieren. Und trotzdem verliert das Projekt Zeit, Energie und Glaubwürdigkeit.
Das ist kein Ausrutscher.
Das ist ein Muster.
Die Linie ist nicht der Feind
Jetzt bitte nicht falsch abbiegen.
Die Linie ist nicht böse.
Die Linie hält den Laden am Laufen. Sie schützt Fachlichkeit, Qualität, operative Stabilität, Kundenzusagen, Standards, Auslastung und oft auch die Nerven der Organisation.
Ohne Linie gäbe es keine Verlässlichkeit.
Ohne Fachbereiche gäbe es keine Kompetenz.
Ohne operative Stabilität wäre jedes Transformationsprojekt nur ein hübscher Brandbeschleuniger mit Governance-Folie.
Also nein: Die Linie ist nicht der Feind.
Aber die Linie folgt einer anderen Logik als das Projekt.
Die Linie denkt in Stabilität, Effizienz, Fachstandards und Tagesgeschäft.
Das Projekt denkt in Veränderung, Ergebnisdruck, Meilensteinen und bereichsübergreifendem Fortschritt.
Beides ist legitim.
Problematisch wird es erst, wenn beide Logiken auf dieselben Menschen zugreifen — aber niemand vorher klärt, was im Konfliktfall gilt. Dann entsteht kein produktives Zusammenspiel. Dann entsteht ein permanenter Aushandlungsraum.
Und die Menschen zahlen den Preis.
Wenn alles Priorität hat, hat nichts Schutz
Priorität erkennt ihr nicht daran, was in der Präsentation steht.
Priorität erkennt ihr daran, was geschützt wird, wenn es unbequem wird.
Wenn ein Projekt offiziell strategisch wichtig ist, aber im ersten Linienbrand seine Schlüsselperson verliert, dann hatte dieses Projekt keine Priorität.
Es hatte eine schöne Formulierung.
Das ist ein Unterschied.
Viele Organisationen behandeln Priorität wie ein Etikett. Man klebt es auf Vorhaben, damit sie wichtiger aussehen.
Top-Priorität.
Strategisch relevant.
Geschäftskritisch.
Zukunftssichernd.
Transformationsrelevant.
Alles sehr beeindruckend.
Aber wenn im Konfliktfall niemand entscheidet, was dafür pausiert, geschützt, verschoben oder entlastet wird, ist Priorisierung nur Dekoration.
Und Dekoration liefert keine Projekte.
Sie sieht nur nett aus, während andere arbeiten.
Projektleitungen sollen liefern — dürfen aber oft nicht entscheiden
Eine der größten Schieflagen zwischen Linie und Projekt ist diese:
Projektleitungen tragen Ergebnisdruck.
Sie sollen Termine halten.
Sie sollen Budgets erklären.
Sie sollen Risiken steuern.
Sie sollen Stakeholder beruhigen.
Sie sollen Fortschritt sichern.
Aber die wichtigsten Hebel liegen oft außerhalb ihres Zugriffs.
Die Menschen hängen in der Linie.
Die fachlichen Prioritäten liegen in den Bereichen.
Die operativen Zielsysteme belohnen lokale Stabilität.
Die Entscheidungsmacht sitzt beim Sponsor oder im Steering Committee.
Die informellen Prioritäten laufen über Nebenkanäle.
Und mittendrin steht die Projektleitung. Sie soll liefern, aber darf oft nur bitten.
Das nennt man dann Matrixorganisation.
In der Theorie ist die Matrix ein kluger Versuch, Fachkompetenz und Veränderung miteinander zu verbinden.
In der Praxis wird sie schnell zu einem System, in dem alle irgendwie zuständig sind, aber niemand den Konflikt besitzt.
Das Projektteam sieht das Problem. Die Linie spürt die Belastung. Das Steering Committee kennt die Ampel. Die Mitarbeitenden versuchen täglich zu erraten, was wirklich Vorrang hat.
Und die Entscheidung bleibt zwischen den Ebenen hängen.
Sehr kollegial. Sehr teuer.
RACI rettet euch nicht, wenn niemand Macht bewegt
Jetzt kommen gern die üblichen Reparaturversuche.
Wir brauchen eine klarere RACI /oder VMI.
Wir brauchen ein neues Rollenmodell.
Wir brauchen bessere Statusreports.
Wir brauchen ein stärkeres PMO.
Wir brauchen ein agileres Vorgehen.
Wir brauchen ein neues Tool.
Kann alles helfen.
Aber nur, wenn es das richtige Problem löst.
Eine RACI-Tabelle kann wunderbar aussehen und trotzdem wirkungslos bleiben, wenn die verantwortliche Person keine Ressource schützen kann.
Ein Steering Committee kann prominent besetzt sein und trotzdem nichts steuern, wenn es nur Statusberichte hört, Risiken abnickt und Entscheidungen vertagt.
Ein PMO kann wunderschöne Ampeln konsolidieren und trotzdem nur Symptomverwaltung betreiben, wenn es keine Entscheidungslogik für Ressourcen, Prioritäten und Eskalationen etabliert.
Agile Teams können Dailys machen, Reviews durchführen und Backlogs pflegen — und trotzdem in derselben alten Abhängigkeit zur Linie feststecken.
Und KI kann Risiken, Abhängigkeiten und Überlastung schneller sichtbar machen. Aber KI entscheidet nicht, welche Priorität gilt und wer den Preis trägt.
Schlechte Governance wird durch bessere Tools nicht automatisch besser.
Sie wird nur schneller sichtbar.
Fünf typische Schnittstellenlügen
Wenn Linie und Projekt sich gegenseitig ausbremsen, hört ihr häufig Sätze, die harmlos klingen. Leider sind sie oft Frühwarnsysteme.
1. „Die Ressource ist ja nur kurz weg.“
Nur kurz ist in Projekten eine gefährliche Zeiteinheit.
Denn aus „nur kurz“ wird eine Woche. Aus einer Woche wird eine neue Abhängigkeit. Aus einer Abhängigkeit wird ein verschobener Meilenstein. Aus dem verschobenen Meilenstein wird ein gelber Status. Aus Gelb wird irgendwann Rot.
Und später fragt jemand:
„Warum wurde das nicht früher eskaliert?“
Weil es offiziell nur kurz war.
2. „Das klären wir gemeinsam.“
Gemeinsam klingt gut.
Aber manchmal heißt gemeinsam nur: Niemand will final entscheiden.
Nicht jeder Konflikt ist ein Missverständnis. Manche Konflikte sind echte Trade-offs. Wenn zwei wichtige Ziele nicht gleichzeitig erreichbar sind, hilft kein gemeinsames Klärungsgefühl. Dann braucht ihr eine Entscheidung.
Was bleibt?
Was geht raus?
Was wird verschoben?
Wer bekommt die Person?
Wer trägt die Konsequenz?
Gemeinsam vorbereiten: ja.
Gemeinsam im Nebel stehen: nein.
3. „Das Steering Committee ist informiert.“
Schön. Informiert ist nicht entschieden.
Ein Steuerungsgremium, das nur Status hört, Fragen stellt und Risiken zur Kenntnis nimmt, ist kein Steuerungsgremium.
Es ist ein betreutes Vorlesen von Projektfolien.
Ein gutes Steering Committee entscheidet Zielkonflikte.
Es schützt Prioritäten.
Es akzeptiert bewusst Risiken.
Es verschiebt Vorhaben.
Es gibt Ressourcen frei.
Es nimmt politische Verantwortung.
Wenn es das nicht tut, heißt es vielleicht Steering Committee.
Aber es steuert nicht.
4. „Wir müssen besser kommunizieren.“
Vielleicht? Vielleicht müsst ihr aber auch endlich sagen, wer entscheiden darf.
Kommunikation klärt, was Menschen wissen, verstehen und miteinander aushandeln.
Führung entscheidet, was gilt, wenn nicht alles gleichzeitig möglich ist.
Diese Unterscheidung ist brutal wichtig.
Denn wenn ihr ein Entscheidungsproblem wie ein Kommunikationsproblem behandelt, bekommt ihr mehr Meetings, mehr Protokolle und mehr höfliche Unklarheit. Aber kein schnelleres Projekt.
5. „Das Projekt bleibt Top-Priorität.“
Gut. Was wird dafür gestoppt? Diese Frage ist der Lackmustest.
Wenn eine neue Top-Priorität entsteht und nichts anderes pausiert, verschoben oder entlastet wird, habt ihr keine neue Priorität gesetzt.
Ihr habt nur eine weitere Erwartung auf einen ohnehin überfüllten Tisch gelegt.
Und dann wundert ihr euch, dass alles langsamer wird.
Das ist kein Ressourcenproblem.
Das ist Portfolio-Romantik.
Die E-Mail-Kette der organisierten Unklarheit
Lasst uns das einmal anders anschauen. Nicht als Werkstatt-Szene. Sondern als kleine E-Mail-Kette, wie sie in erstaunlich vielen Organisationen existieren könnte.
Montag, 08:12 Uhr — Bereichsleitung an Projektleitung:
„Wir müssen Person X diese Woche leider kurzfristig ins Tagesgeschäft ziehen. Nur bis Freitag. Projekt bleibt natürlich wichtig.“
Montag, 09:03 Uhr — Projektleitung an Sponsor:
„Ressourcenabzug gefährdet Meilenstein M2. Bitte Klärung der Priorität.“
Montag, 13:47 Uhr — Sponsor an Projektleitung:
„Danke für die Info. Bitte einmal mit der Linie abstimmen und Lösungsvorschlag mitbringen.“
Dienstag, 10:15 Uhr — Projektleitung an Bereichsleitung:
„Können wir Ersatz oder Mindestkapazität sichern?“
Dienstag, 16:22 Uhr — Bereichsleitung:
„Schwierig. Tagesgeschäft hat gerade Vorrang. Aber das Projekt soll natürlich nicht leiden.“
Mittwoch, 11:30 Uhr — PMO:
„Bitte Status aktualisieren. Ampel?“
Mittwoch, 11:42 Uhr — Projektleitung:
„Gelb.“
Natürlich Gelb. Rot wäre ja auch sehr direkt gewesen.
Und dann diskutieren alle wieder über Kommunikation.
Dabei steht die eigentliche Frage längst im Raum:
Wer entscheidet bis wann, ob Person X im Projekt bleibt, ersetzt wird oder der Meilenstein offiziell neu geplant wird?
Das ist der Unterschied zwischen Beschwerde und Entscheidungsfrage.
Nicht:
„Die Linie unterstützt zu wenig.“
Sondern:
„Wer entscheidet bis Freitag 12 Uhr, ob die zugesagte Kapazität geschützt wird — oder welche Konsequenz offiziell gilt?“
So beginnt Schnittstellenführung.
Was reife Schnittstellenführung braucht
Wenn ihr Linie und Projekt besser verbinden wollt, braucht ihr kein 80-seitiges Governance-Handbuch. Ihr braucht ein paar klare Prinzipien.
1. Konflikte sichtbar machen
Ein Zielkonflikt ist kein Störfall.
Er ist Information.
Wenn das Projekt Tempo braucht und die Linie Qualität sichern will, ist das kein persönlicher Konflikt. Es ist ein echter Steuerungskonflikt.
Wenn eine Schlüsselperson gleichzeitig im Tagesgeschäft und im Projekt unverzichtbar ist, ist das kein Kalenderproblem. Es ist ein Kapazitäts- und Prioritätskonflikt.
Wenn ihr diese Konflikte nicht sichtbar macht, wandern sie nach unten.
Und dann müssen Mitarbeitende täglich interpretieren, was Führung nicht entschieden hat.
Das ist unfair.
Und ineffizient.
2. Entscheidung vor Abstimmung
Abstimmung ist nicht schlecht.
Aber Abstimmung darf Entscheidung nicht ersetzen.
Ein guter Grundsatz lautet:
Jede wiederkehrende Schnittstellenstörung muss in eine Entscheidungsfrage übersetzt werden.
Nicht:
„Wir haben immer wieder Ressourcenthemen.“
Sondern:
„Welche kritischen Rollen werden für dieses Projekt bis wann mit welcher Mindestkapazität geschützt?“
Nicht:
„Die Prioritäten sind unklar.“
Sondern:
„Welches Vorhaben pausiert, wenn dieses Projekt wirklich Vorrang bekommt?“
Nicht:
„Die Eskalation dauert zu lang.“
Sondern:
„Wer entscheidet innerhalb von 48 Stunden, wenn eine Blockade länger als fünf Arbeitstage besteht?“
Das klingt nüchtern.
Genau deshalb hilft es.
3. Kapazität als Vertrag behandeln
Kritische Ressourcen werden nicht „bei Bedarf“ organisiert. Sie werden verbindlich vereinbart.
Nicht als abstrakte FTE-Zahl, die in der Planung gut aussieht und im Alltag nichts bedeutet. Sondern konkret:
Welche Fähigkeit wird gebraucht?
In welchem Zeitraum?
Mit welcher Mindestverfügbarkeit?
An welchen Tagen?
Welche Linienpeaks sind bekannt?
Unter welchen Bedingungen darf die Ressource abgezogen werden?
Was passiert dann: Ersatz, Replanung, Scope-Reduktion oder Entscheidung im Portfolio Board?
Ja, das ist unromantisch. Aber Projekte scheitern selten an zu wenig Romantik. Sie scheitern häufiger an zu viel Hoffnung.
4. Eskalation entdramatisieren
Eskalation ist kein Alarmismus.
Eskalation ist Führung.
Wenn eine Entscheidung auf Teamebene nicht lösbar ist, weil Zielkonflikte, Ressourcen oder politische Konsequenzen höher liegen, dann gehört sie nach oben.
Nicht als Vorwurf. Nicht als Drama. Nicht als persönliches Versagen.
Sondern als definierter Entscheidungsweg.
Eine gute Eskalationsregel ist nüchtern:
Wenn eine Blockade länger als fünf Arbeitstage besteht oder ein kritischer Meilenstein innerhalb der nächsten zehn Arbeitstage gefährdet ist, erstellt die Projektleitung eine Ein-Seiten-Eskalation mit Sachverhalt, Optionen, Empfehlung und Konsequenzen.
Der Sponsor entscheidet innerhalb von 48 Stunden — oder leitet an das Portfolio Board weiter.
Fertig.
Keine Oper.
Keine Schuldshow.
Keine fünf Wochen politisches Warmreden.
Nur Führung.
5. Sponsoren nicht als Grußwort verwenden
Ein Sponsor ist nicht die Person, die beim Kick-off lächelt, die strategische Bedeutung betont und danach bei Erfolgen gratuliert.
Das ist ein Festredner.
Ein Sponsor schützt Prioritäten. Er trifft Trade-offs. Er setzt Macht ein. Er beseitigt Hindernisse. Er trägt Konsequenzen. Er entscheidet, welcher Preis für welche Priorität gezahlt wird.
Wenn ein Sponsor nur eröffnet und lobt, ist er kein Sponsor.
Dann ist er dekorativer Projektpate. Und davon werden Projekte selten schneller.
Der kompakte Realitätscheck
Wenn ihr wissen wollt, ob euer Problem wirklich Kommunikation ist — oder längst Entscheidung, Mandat und Schnittstellenführung — dann nehmt euch diese Fragen vor.
Nicht hübsch beantworten. Ehrlich reicht.
Wer entscheidet final, wenn Linienpriorität und Projektpriorität kollidieren?
Welche Schlüsselpersonen sind gleichzeitig in Linie und Projekt kritisch gebunden?
Wo trägt die Projektleitung Ergebnisverantwortung ohne ausreichende Entscheidungsmacht?
Welche Konflikte werden regelmäßig „abgestimmt“, obwohl eigentlich entschieden werden müsste?
Gibt es eine klare Regel, wann ein Ressourcenkonflikt eskaliert wird?
Welche Bereichsziele stehen dem Projekterfolg faktisch entgegen?
Wer schützt das Projekt vor kurzfristigen Linienprioritäten?
Welche Entscheidungen werden außerhalb der offiziellen Gremien getroffen?
Woran erkennen Mitarbeitende im Alltag, was im Konfliktfall wirklich Vorrang hat?
Welche eine Schnittstellenregel würde sofort Druck aus eurem Projekt nehmen?
Wenn mehrere Antworten weh tun, seid ihr vermutlich nahe an der Wahrheit.
Und das ist gut.
Denn echte Verbesserung beginnt nicht dort, wo alle zufrieden nicken.
Sie beginnt dort, wo ein Zielkonflikt endlich beim richtigen Namen genannt wird.
Kompetenzaufbau statt Schnittstellentheater
Schnittstellen zwischen Linie und Projekt werden nicht automatisch besser, nur weil Menschen netter miteinander sprechen.
Nettigkeit hilft. Aber sie ersetzt keine Entscheidungsarchitektur.
Was ihr braucht, ist Kompetenzaufbau an den Stellen, an denen Projekte wirklich stecken bleiben:
Zielkonflikte erkennen.
Beobachtungen in Entscheidungsfragen übersetzen.
Kapazität realistisch vereinbaren.
Eskalationen ohne Drama gestalten.
Sponsorenrollen schärfen.
Portfolio-WIP begrenzen.
PMO-Arbeit von Reporting zu Entscheidungsqualität entwickeln.
Linie und Projekt nicht gegeneinander ausspielen, sondern mit klaren Regeln verbinden.
Das ist keine Methodenromantik. Das ist Führungsarbeit.
Und ja: Das ist anspruchsvoller als ein weiteres Meeting.
Aber auch deutlich wirksamer.
Denn wenn Projekte strategischer werden, wenn KI, Digitalisierung, Automatisierung und Veränderung immer tiefer in Fachbereiche hineinreichen, dann reicht operative Projekttechnik allein nicht mehr. Dann wird Schnittstellenführung zur Kernkompetenz.
Nicht irgendwann.
Jetzt.
Fazit: Die Schnittstelle zeigt, ob eure Strategie Konsequenzen hat
Die Schnittstelle zwischen Linie und Projekt ist kein Nebenschauplatz. Sie ist einer der Orte, an denen eure Organisation zeigt, ob Strategie echte Konsequenz hat — oder nur Folienqualität.
Wenn ein Projekt offiziell wichtig ist, aber im Konfliktfall keine Kapazität geschützt wird, ist es nicht wichtig.
Wenn ein Steering Committee nicht entscheidet, sondern nur Status konsumiert, steuert es nicht.
Wenn Projektleitungen liefern sollen, aber keine Entscheidungsmacht über die relevanten Bedingungen haben, entsteht Scheinsouveränität.
Wenn jedes Projekt Top-Priorität ist, hat nichts Schutz.
Und wenn ihr auf echte Zielkonflikte mit mehr Abstimmung reagiert, bekommt ihr wahrscheinlich mehr Abstimmung. Aber nicht mehr Steuerung.
Die entscheidende Frage lautet deshalb nicht:
„Wie können Linie und Projekt besser kommunizieren?“
Die bessere Frage lautet:
„Welche Konflikte behandeln wir noch als Kommunikationsproblem, obwohl längst eine Führungsentscheidung nötig wäre?“
Dort beginnt die Arbeit.
Nicht im nächsten Statusmeeting.
Nicht im nächsten Tool.
Nicht in der nächsten RACI-Tabelle.
Sondern in der klaren Entscheidung, wer im Konfliktfall was entscheiden darf, welche Kapazität wirklich geschützt wird und welche Priorität auch dann gilt, wenn es unbequem wird.
Alles andere ist freundliche Unklarheit.
Und freundliche Unklarheit ist in Projekten oft nur die höflichste Form von Stillstand.
Euer Jörg Tausendfreund
P.S. Wenn euer Projekt nur so lange Top-Priorität ist, bis das Tagesgeschäft ruft, dann habt ihr keine Priorität. Ihr habt ein hübsches Etikett mit kurzer Halbwertszeit.




Kommentare