Einfach Projekte

Projektmanager sind keine Blitzableiter

Jörg Tausendfreund

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 39:22

Rote Ampel, wachsende Anforderungen, fehlende Ressourcen und ein Lenkungskreis, der fragt: „Warum wurde das nicht früher erkannt?“ Genau in diesem Moment wird Projektleitung in vielen Unternehmen zum Blitzableiter. Wir drehen den Blick weg von Schuld und hin zur Konstruktion des Projektsystems, denn Projektmanagement ist kein Heldensport und Projektleitungen sind keine Risikomagier, keine Ersatzsponsoren und keine Wunderwaffe gegen schlechte Governance. 

Am Beispiel von „Projekt Phönix“ aus einem mittelständischen Medizintechnik-Umfeld zeigen wir, wie Zielkonflikte entstehen, wenn Vertrieb einen Kundentermin zusagt, Regulatory zusätzliche Nachweise fordert, Entwicklung länger braucht und die Produktion Stabilität im Serienprozess verlangt. Das Problem ist nicht mangelnde Professionalität, sondern fehlende Entscheidungswege: Wer priorisiert, wer schützt Ressourcen, wer entscheidet bei Scope Creep, und was passiert, wenn Scope, Termin und Budget nicht mehr zusammenpassen? Wir machen sichtbar, warum Reporting ohne Konsequenz nur beruhigt, aber nicht steuert, und warum Stakeholder-Management ohne gemeinsames Erfolgsbild die Projektleitung zum Übersetzerpuffer macht. 

Konkret benennen wir sechs typische „Projektleiterzangen“ und geben dir einen Mandatscheck mit sieben Fragen an die Hand: Entscheidungsrechte im Konflikt, verbindlicher Ressourcenschutz, Eskalationslogik mit Fristen, Trade-off-Regeln im magischen Dreieck, entscheidungsfähiges Sponsorship, echtes Erfolgsverständnis und der Umgang mit früher roter Ampel. Wenn mehrere Antworten wehtun, hast du sehr wahrscheinlich kein Projektleiterproblem, sondern ein Projektsystem-Problem und das ist gestaltbar. Abonniere den Podcast, teile die Folge mit jemandem mit viel Projektverantwortung und lass uns wissen: Wo nutzt eure Organisation Projektleitung gerade als Blitzableiter statt als Steuerungsrolle?


 

Wenn du Interesse an dem One-Pager zu dieser Folge hast, dann folge dem Link und hol dir den One-Pager kostenfrei bei mir im Stand-Store ab: 
https://stan.store/einfachprojekte/p/mandatscheck-projektleitung


Bist du interessiert an mehr Informationen zu erfolgreicher Projektarbeit? Hier findest Du mehr: https://www.einfachprojekte.de


Wenn dich Klartext zu Projektarbeit interessiert, dann wirst du hier bestimmt fündig. Über diesen Link hast du Zugang zum aktuellen Podcast, zum kompletten Blog und zur Projektmanagement Toolbox:

https://www.1000freund.net/klartext


Deine persönliche Projektleitungskompetenz ist das A und O. Teste Deine doch einfach mal hier:

https://www.1000freund.net/einfachprojekte/kompetenztest-projektleitung


Und wenn Du Fragen, gerne mit mir ins Gespräch kommen magst oder einfach noch mehr Klartext zu Projekten und erfolgreicher Zusammenarbeit suchst, findest Du hier genau das richtige: https://www.1000freund.net/3-wege-zum-klartext


Und hey. Teile gerne die Folge mit deinem Team. Abonniere den Podcast. Lass gerne eine Bewertung da. Und sei einfach wieder mit dabei, wenn es bald wieder heißt: Einfach Projekte 

Schick mir gerne Deine Nachricht...

Wenn Projekte Kippen Und Schuld Sucht

SPEAKER_00

Stell dir einen Lenkungskreis vor, die Projektleitung steht vorne, der Status ist gelb-rot, Termin ist gefährdet, Ressourcen fehlen, Scope ist gewachsen und der Kunde ist nervös. Und plötzlich kommen diese Fragen. Warum wurde das nicht früher erkannt? Warum wurde nicht sauberer geplant? Warum wurde nicht energischer eskaliert? Gute Fragen? Wirklich. Nur fehlt oft eine Gegenfrage. Welche dieser Dinge durfte die Projektleitung eigentlich entscheiden? Denn Projektleitung ist kein Zauberberuf. Auch gute Projektmanager können keine Ressourcen herbeimoderieren, keine Prioritäten hereinlächeln und keine Sponsorentscheidung durch ein schön formuliertes Statusdeck ersetzen. Heute geht es um Projektmanager als Blitzableiter und warum Projektmanagement kein Heldensport sein darf. Seid dabei! Herzlich willkommen mit einem Projekt im Platz. Vor allem immer sechs Gespräch. Herzlich willkommen zurück oder neu dabei bei Einfachprojekte. Ich bin wieder im virtuellen Project Office und heute sprechen wir über eine Rolle, die in vielen Organisationen erstaunlich viel tragen soll. Projektleitung

Rollenklärung Statt Opfergeschichte

SPEAKER_00

oder Projektmanagement oder Projektverantwortung oder wie auch immer diese Rolle bei euch heißt. Und direkt vorweg, diese Folge wird keine Opferbedauerfolge. Es geht nicht darum, dass Projektleitungen immer alles richtig machen und die böse Organisation sie unfair behandelt. Nein, es gibt schlechte Projektleitungen, es gibt schlechte Planung und es gibt zu späte Eskalation und unklare Kommunikation gibt es auch. Es gibt sogar Projektleitungen, die Risiken zu weich formulieren, Stakeholder zu spät Einbindungen, Entscheidungen nicht sauber vorbereiten und selbst viel zu lange hoffen. Das gehört alles zur Wahrheit dazu. Projektleitungen bleiben verantwortlich für ihr Handwerk. Für Struktur, Planung, Transparenz, Risiken, Entscheidungsbedarf, saubere Steuerungsimpulse und und und. Aber genau da liegt der Punkt. Sie sind verantwortlich für ihr Handwerk. Nicht für ein schlecht konstruiertes Projektsystem. Nicht für Ressourcen, die nie geschützt werden, nicht für Scope, den andere über Nebenkanäle aufblähen, nicht für Sponsorentscheidungen, die ausbleiben und auch nicht für Prioritäten, die oben strategisch schlingen und unten im echten Linienarbeiten irgendwie untergehen. Diese Folge ist also keine Entschuldigung, sondern sie ist eine Rollenklärung. Und Rollenklärung ist in Projekten oft der Anfang von echter Würde und Wirkung. Der zentrale Widerspruch lautet, Projektmanager sollen in vielen Organisationen alles verantworten, aber bei fast allem um Erlaubnis bitten. Sie sollen Termine halten, aber Ressourcen sitzen in der Linie. Sie sollen Scope kontrollieren, aber Kunden, Vertrieb, Fachbereiche oder Geschäftsführung bringen Zusatzwünsche mit ins Projekt ein. Oder sie sollen auch Prioritäten sichern. Aber Prioritäten werden im Management gesetzt. Und, und, und. Ach ja, vielleicht noch was anderes Wichtiges. Das Tagesgeschäft ruft ja auch immer ganz genau dann an, wenn das Projekt Tempo braucht. Und das ist natürlich die Zwickmühle, in der sich viele Projektleitungen bewegen. Projektleitungen sollen ja Ergebnisse sichern. Aber sie steuern oft nicht das System, das diese Ergebnisse ermöglicht oder verhindert. Und wenn es dann halt knallt, dann steht die Projektleitung ganz vorne. Mit Ampelmaßnahmenplan, aktualisierter Timeline und mit einer erstaunlichen Menge an Aufmerksamkeit auf der eigenen Person. Dann wird Projektleitung zur Blitzableiterrolle. Nicht, weil Projektleitungen keine Verantwortung hätten, sondern weil die falsche Verantwortung an der sichtbarsten Stelle entladen wird. Noch eine wichtige Abgrenzung hier. Methoden- und Projektmanagement-Training bleibt wichtig. Sehr wichtig sogar. Saubere Planung, Stakeholder-Arbeit, Risikomanagement, Kommunikation, Eskalationslogik, klassische, agile oder hybride Steuerung, all das muss man können. Gutes Projektmanagement ist Handwerk und Handwerk braucht Übung, Reflexion und Kompetenzaufbau. Aber wenn Projektleitungen dauerhaft in der Zange hängen, reicht Methodenschulung allein nicht. Dann braucht es den Kompetenzaufbau an den Stellen, an denen Projekte wirklich kippen. Entscheidungsarchitektur, Sponsorship, Priorisierung, Ressourcenschutz, Eskalationslogik und professionelles Nein. Und übrigens auch die Fähigkeit, Widersprüche zu formulieren, dass daraus Entscheidungen werden können. Denn ein GAN-Diagramm schützt keine Ressource. Ein Kanban-Board entscheidet keinen Zielkonflikt und ein Daily ersetzt keine Sponsorship. Das ist unbequem, also ist es wahrscheinlich nützlich, darüber nachzudenken.

Projekt Phönix Als Praxisbeispiel

SPEAKER_00

Und lass uns deswegen mal wieder im Projekt Phönix vorbeischauen. Du weißt ja, das Projekt Phönix ist immer meine neutralisierte Erfahrung, die ich mit dir gerne teilen möchte, sodass wir gemeinsam an einem ganz praktischen Beispiel was lernen können. Und ja, auch diesmal für dich ganz kompakt. Und wir werden da sehen, wie die Projektleitung langsam zur Blitzableiterrolle wird. Das Projekt Phoenix spielt diesmal in einem mittelständischen Zahntechnikzulieferer. Und das Unternehmen entwickelt und produziert Komponenten, Materialien und digitale Prozessbausteine für zahntechnische Labore und zahnmedizinische Versorgungsprozess. Es ist also kein anonymer Konzern, es ist ein gewachsenes Unternehmen, fachlich stark, regulatorisch anspruchsvoll, Medizintechnik eben, kundenorientiert mit hoher Qualitätskultur. Und mit Projekten, in denen Technik, Qualität, Vertrieb, Regulatory Affairs, Produktion, Einkauf und Geschäftsführung oft irgendwie zusammenhängen. Kommen wir zum ersten Bild, zum Auftrag. Ein bestehendes Produkt muss geändert werden. Ein wichtiger Kunde hat neue Anforderungen, gleichzeitig gibt es eine neue regulatorische Richtlinie. Ein technisches Bauteil muss angepasst werden und die Dokumentation aktualisiert. Qualität braucht zusätzliche Nachweise und Regulatory muss die Änderungsbewertung sauber absichern. Die Produktion muss prüfen, ob die Änderung stabil in den Prozess passt und der Einkauf muss eine kritische Komponente neu qualifizieren. Der Vertrieb übrigens hat dem Kunden bereits signalisiert, wir bekommen das hin. Natürlich. Nicht aus Bosheit, sondern aus Kundenorientierung und Wettbewerbsdruck. Und aus dem berechtigten Wunsch, eine wichtige Beziehung zu halten. Das Projekt wird also aufgesetzt, die Projektleitung benannt, der Sponsor ist bekannt, Fachbereiche eingebunden, Kick-Off durchgeführt und alle sagen, das ist strategisch wichtig. Der Sponsor sagt, da stehe ich dahinter, die Projektleitung übernimmt und auf dem Papier sieht erstmal alles gut aus. Meilensteine, Arbeitspakete, Risiken, Stakeholder, Regeltermine, Statusformat, alles da. Projektmanagement findet also statt. Jetzt kommen wir zu einer Sequenz, die ungefähr vier Wochen später spielt. Die Entwicklung braucht länger, weil die technische Änderung doch stärker in bestehende Produktionslogik eingreift. Qualität fordert zusätzliche Nachweise. Regulatory warnt. So können wir das nicht sauber freigeben. Einkauf bekommt die neue Komponente nicht verbindlich zugesagt und die Produktion sagt, wir brauchen einen stabileren Übergang in den Serienprozess. Der Vertrieb übrigens sagt natürlich, der Kunde erwartet aber weiterhin den zugesagten Termin. Und die Projektleitung sieht, was passiert. Der Plan hält nur noch, weil mehrere Menschen gleichzeitig hoffen, sie brauchen Entscheidungen, was hat Vorrang? Termin, regulatorische Sicherheit, Kundenkommunikation, Scope, zusätzliche Ressourcen, Teilfreigabe oder oder oder. Aber die Ressourcen sitzen halt in den Bereichen. Der Scope wächst in kleinen Zusatzwünschchen und der Kunde spricht mit dem Vertrieb. Die Qualität spricht den Standards, die Produktion spricht in Stabilität und der Sponsor sagt, bitte erst noch einmal mit den Bereichen abstimmen. Und übrigens, der Lenkungskreis nimmt Risiken zur Kenntnis. Und das ist der Moment, in dem die Projektleitung in die Zange gerät. Sie soll liefern, aber sie darf nicht entscheiden, was wirklich Vorrang hat. Und damit kommen wir zum dritten Teilbild des Ganzen. Lenkungskreissituation. Der Status ist rot-gelb, die Projektleitung präsentiert sauber, nicht dramatisch, nicht jammernd oder weinend, sondern echt sauber. Terminrisiko, Ressourcenrisiko, Scope-Entwicklung, regulatorische Abhängigkeit, Kundenkommunikation, Entscheidungsbedarf. Und dann gibt die Stimmung.

Lenkungskreis Druck Und Zielkonflikte

SPEAKER_00

Nicht laut, aber spürbar. Warum wurde das nicht früher klarer adressiert? Warum ist die Entwicklung nicht stärker in der Verantwortung? Warum wurde Vertrieb nicht besser eingebunden? Und warum ist der Kunde nicht vorbereitet? Übrigens, dann kommt auch noch, was ist jetzt Ihr Plan? Und ja, da steht die Projektleitung jetzt. Vorne sichtbar, angreifbar, mit einem Problem, das allzu real für so viele Projektleitungen ist, aber nicht allein durch Projektleitung lösbar ist. Denn die eigentliche Frage lautet: Wer entscheidet jetzt den Zielkonflikt? Wird der Kundentermin neu verhandelt? Wird Scope reduziert? Bekommt die Entwicklung zusätzliche Kapazität? Wird Qualität vorgezogen? Wird Vertrieb offiziell aus der alten Kundenzusage herausgeführt? Oder, oder, oder. Oder soll die Projektleitung bitte einfach noch konsequenter steuern? Ja, das ist das Projekt Phoenix. Und genau darum geht es heute. Projektleitungen dürfen Verantwortung tragen, aber nicht für Entscheidungen haften, die andere nicht treffen. Und das ist der entscheidende Punkt. Das ist die Projektleiterzange, könnte man sagen. Die Projektleiterzange entsteht, wenn Projektleitungen zwischen Anspruch und Wirklichkeit eingeklemmt werden. Nicht durch einen einzelnen Fehler, sondern durch ein System. Ein System, das Verantwortung nach unten delegiert, aber macht Priorisierung und Konsequenz oben. Seitlich oder irgendwo im Nebel hält. Oben heißt es, das Projekt muss liefern, seitlich heißt es, unsere Leute sind ausgelastet. Im Fachbereich heißt es, das muss zusätzlich noch rein. Und der Sponsor sagt, bitte erst noch abstimmen. Und bei der Projektleitung heißt es, mach mal, und das ist zwar sehr schön, aber mach mal ist halt kein Mandat. Es ist ein Satz, der erstaunlich viel Arbeit erzeugt und erstaunlich wenig Entscheidungen hält. Die Zange wird besonders gefährlich, weil sie oft so professionell aussieht. Es gibt einen Projektauftrag, Rollen, Governance, Statusberichte, Sitzungen und sogar einen Sponsor. Zumindest auf der Folie. Aber wenn es ernst wird, zeigt sich, darf die Projektleitung wirklich steuern oder darf sie nur koordinieren, erinnern, bitten, berichten, moderieren und am Ende erklären, warum es nicht gereicht hat. Und das ist der Unterschied. Und wir vertiefen das jetzt mal, indem wir uns sozusagen uns die sechs Ausprägungen dieser Zange anschauen.

Die Sechs Projektleiterzangen

SPEAKER_00

Das erste ist Verantwortung ohne Mandat. Das ist im Prinzip der Klassiker. Die Projektleitung ist verantwortlich für Termin, Ergebnis, Budget und so weiter und so fort. Das ist alles ganz wunderbar. Aber was darf sie wirklich entscheiden? Darf sie Scope reduzieren, darf sie ressourcen verbindlich einfordern oder darf sie Prioritäten in Frage stellen? Meistens nicht. Dann wird Verantwortung zur Zumutung. Ganz bestimmt sogar. Denn Verantwortung ohne Mandat ist nicht professionell. Es ist einfach Verschleiß mit Rollenbeschreibung. Und bei Phoenix würde das ja zum Beispiel heißen, die Projektleitung ist verantwortlich für den Liefertermin, aber sie darf dem Vertrieb nicht irgendwie allein sagen, die Sekundenzusage ist nicht mehr haltbar. Oder sie ist verantwortlich für Qualität im Projekt, aber sie darf die Qualitätsfreigabe nicht einfach anders priorisieren. Und dann wird aus Steuerung ein sehr gepflegtes, manchmal auch verzweifeltes Bit. Könntet ihr bitte, wäre es möglich, wir bräuchten dringend, könnt ihr das priorisieren? Natürlich braucht Projektleitung Kooperationsfähigkeit, megamäßig sogar. Aber ein strategisches Projekt, das strukturell auf Bitten basiert, das ist nicht gesteuert. Das ist höflich abhängig und komplett unprofessionell. Und höfliche Abhängigkeit ist auch keine Projektarchitektur. Also Projektleitung macht Entscheidungsbedarf sichtbar. Sponsor und Lenkungskreise müssen Mandat und Trade-offs klären und dann aber auch schnell entscheiden oder Projektleitung entscheiden lassen. Könnt ihr euch aussuchen. Ressourcen ohne Verbindlichkeit. In Projektplänen stehen Ressourcen ganz oft wunderbar und sehen auch verfügbar aus. 40% hier, 30% dort, eine Schlüsselperson mit temporärer Unterstützung, ein Fachbereich mit zugesagter Mitwirkung. Klingt alles gut. Bis am Montagmorgen, das Tagesgeschäft halt einfach brennt. Dann ist dieselbe Schlüsselperson plötzlich nur kurz weg. Der Fachbereich muss eben mal neu priorisieren und die zugesagte Mitwirkung wird zur freundlichen Absichtserklärung. Die Projektleitung darf dann brav den Plan aktualisieren. Natürlich gelb. Rot wäre ja wieder irgendwie unangenehm. Und ein Beispiel aus Phoenix, wenn das da passiert, dann würde die Expertin aus Regulatory Affairs, die ist im Plan für zwei Workshops, also im Plan für zwei Workshops eingeplant und auch für die Änderungsbewertung. Und dann kommt irgendwie eine Auditvorbereitung dazwischen, nur kurz, und ja, dann ist sie weg. Und der Entwicklungsingenieur soll die technische Anpassung vorziehen und dann braucht ein anderes Kundenprojekt kurzfristig Unterstützung. Nur diese Woche. Und, und, und. Alles nachvollziehbar, zusammen, aber tödlich für die Verbindlichkeit in diesem Projekt. Wenn Ressourcen nicht geschützt sind, dann sind sie nicht zugesagt. Dann sind sie gehofft und Hoffnung ist kein Kapazitätsmodell. Also Projektleitung plant Kapazität, Linie und Sponsor müssen Sie schützen oder offiziell neu entscheiden. Damit sind wir schon bei Zange Nummer 3. Stakeholder ohne gemeinsames Erfolgsbild. Stakeholder Management klingt manchmal so, als ginge es vor allem darum, Menschen gut einzubinden. Das stimmt. Aber es reicht nicht. Denn Stakeholder haben nicht nur Informationsbedarfe, sie haben unterschiedliche Erfolgsbilder. Für Vertrieb ist Phönix erfolgreich, wenn der Kunde den zugesagten Termin und natürlich das entsprechende funktionierende Produkt bekommt. Für Qualität ist Phoenix erfolgreich, wenn die Änderung sauber nachweisbar und auditfähig ist. Und für die Produktion zum Beispiel ist Phoenix erfolgreich, wenn der Prozess stabil läuft. Alle haben recht, und genau deshalb wird es schwierig. Projektleitungen sollen Stakeholder managen, als wären unterschiedliche Erwartungen nur eine Frage guter Kommunikation. Das sind sie aber nicht. Oft sind es echte Zielkonflikte. Und wenn Erfolg nicht gemeinsam definiert ist, dann wird die Projektleitung zum Übersetzerpuffer oder irgendwie gelegentlich zum diplomatischen Sandsack. Und später heißt es dann, das Projekt hatlich geliefert. Die ehrliche Frage wäre aber, was genau hätte es denn für wen liefern sollen? Und wer hat diesen Zielkonflikt entschieden? Das immer wieder bei der Rollenklärung. Projektleitung moderiert Erwartungen, Führung muss Erfolg definieren und Zielkonflikte entscheiden. Und Schwuppsliws sind wir schon bei Zange Nummer 4 von 6. Scope ohne Schutz. Scope Creep klingt erstmal wie ein methodisches Problem, ist es aber oft nicht. Natürlich braucht es sauberes Change Management. Natürlich müssen Anforderungen dokumentiert, bewertet und entschieden werden. Aber in der Praxis kommt Scope Creep selten als offizieller Änderungsantrag mit Fanfare daher. Es kommt als kleiner Wunsch, als nur noch diese Anpassung, das braucht der Kunde unbedingt. Das ist doch im Sinne des Projekts und wenn wir schon dabei sind. Und jedes Mal soll die Projektleitung freundlich, lösungsorientiert und kundenorientiert bleiben. Das ist erstmal sehr schön. Nur leider gilt halt, wenn Scope wachsen darf. Aber Zeit, Budget und Ressourcen gleich bleiben, wächst nicht nur der Leistungsumfang, sondern es wächst auch ganz kräftig die Lüge. Bei Phoenix wächst das Scope auch ganz leise. Der Kunde wünscht eine zusätzliche Dokumentationsvariante, der Vertrieb möchte eine kleine Zusatzoption, weil es die Akzeptanz verbessert und die Produktion möchte eine Anpassung im Prozessübergang. Alles sinnvoll, alles begründbar. Aber zusammen ändert es das Projekt. Und wenn niemand entscheidet, was dafür rausgeht, später kommt oder teurer wird, dann wird Scope-Schutz zur Projektleitungsfantasie, aber jenseits jeder Realität. Ein Projektumfang braucht Schutz. Und dieser Schutz ist keine administrative Kleinigkeit, es ist eine Führungsentscheidung. Und aus der Rollenperspektive gilt halt wieder, Projektleitung zeigt Auswirkungen, Sponsor und Change Governance entscheiden, was rein, raus, später oder teurer. Und damit sind wir schon bei Zange Nummer 5. Sponsorship ohne Entscheidung. Ein Sponsor ist eine wunderbare Rolle, wenn sie gelebt wird. Leider wird Sponsorschaft in manchen Projekten mit dem Grußwort verwechselt. Da kommt dann der Grüßonkel und sagt ein paar nette Wörtchen. Beim Kickoff ist der Sponsor da. Er sagt, dass es strategische Bedeutung hat, betont Vertrauen in das Team und wünscht nochmal ganz herzlich viel Erfolg. Dann verschwindet er in der oberen Atmosphäre der Organisation und taucht wieder auf, wenn es nicht läuft. Das ist aber kein Sponsorship. Das ist irgendwie Projektpartnerschaft mit sporadischer Wetterbeobachtung oder so. Ein echter Sponsor kümmert sich, schützt Prioritäten, entscheidet bei Zielkonflikten, räumt Hindernisse aus dem Weg, stellt Ressourcen sicher. Bei Phoenix wäre Sponsorship nicht bitte nochmal mit Vertrieb, Qualität und Entwicklung abstimmen. Das ist Rückdelegation mit höflicher Stimme oder so, sondern das wäre irgendwie, wir entscheiden jetzt den Kundentermin und der wird neu verhandelt, weil regulatorische Freigabe den Vorrang hat. Oder sowas ähnliches. Wenn der Sponsor nur interessiert ist, aber nicht entscheidet, bleibt die Projektleitung halt allein mit einem sehr gut informierten Problem. Und gut informierte Probleme sind immer noch Probleme. Deswegen wieder Rollenperspektive, Projektleitung berichtet. Und übrigens nicht nur für Interesse, sondern sie berichtet, damit Sponsoren Entscheidungen treffen können. Und damit sind wir schon bei der letzten Zange. Reporting ohne Konsequenz. Projektleitungen berichten. Viel. Status, Risiken, Abhängigkeiten, Maßnahmen ampeln, Entscheidungsbedarf, nächste Schritte. Und dann manchmal passiert erstaunlich wenig. Risiken werden irgendwie zur Kenntnis genommen, Entscheidungen vertagt und Ressourcenthemen werden dann einfach nochmal besprochen. Abhängigkeiten bleiben offen und Reporting wird irgendwie zum Ritual. Das ist nicht Steuerung. Ein Statusbericht ist aber kein Beruhigungsdokument. Es ist ein Steuerungsinstrument. Ein guter Statusbericht beantwortet nicht nur, wo stehen wir, sondern auch, welche Entscheidung braucht dieses Projekt jetzt, damit es führbar bleibt. Und wenn diese Frage irgendwie nicht zu einer Entscheidung führt, dann haben wir halt einfach ein Problem. Bei Phoenix, ja, bei Phoenix hat die Projektleitung berichtet. Vielleicht sogar ausreichend früh und vielleicht sogar sauber. Aber wenn der Lenkungskreis aus jedem Entscheidungsbedarf ein weiteres Prüfmeeting macht, dann wird halt Steuerung vertagt. Und die Projektleitung darf beim nächsten Termin erklären, warum das Risiko immer noch da ist. Überraschung, weil niemand entschieden hat. Und damit wieder Rolleneinordnung. Projektleitung liefert Transparenz. Governance muss daraus Entscheidungen machen.

Mandatscheck Mit Sieben Fragen

SPEAKER_00

Und deswegen möchte ich dir, also sozusagen zur Gegenwehr oder zur Bearbeitung dieser Zange, möchte ich dir einen Projektleitungs-Mandatscheck näher bringen. Ja, und der Mandatscheck, das ist irgendwie kein Schuldformular, also für keinen, nicht für Projektleitung sponsoren oder für die Linie oder sonst irgendwas, es ist ein Realitätscheck. Und er beantwortet eine einfache Frage. Kann diese Projektleitung steuern oder bedient sie gerade irgendwie die Funktion des Blitzableiters für ein schlecht konstruiertes Projektsystem? Der Check hat im Prinzip sieben Fragen. Ich reiße es hier jetzt für uns ganz bewusst kompakt an und wenn dich die ausführliche Version mit allen Details interessiert, du weißt es ja, ich lege dir immer einen One-Tager für diese Podcast-Folgen auch zurecht und du kannst dir denen gerne kostenfrei runterladen. Also, erste Frage wäre, welche Entscheidungen darf die Projektleitung wirklich treffen? Also nicht theoretisch und nicht irgendwie im Rollenpapier, sondern im echten Konflikt. Das muss halt einfach aufgeschrieben sein, was die Projektleitung dann wirklich auch darf. Übrigens, eigentlich gehört es in ein gutes Projektsystem ganz an den Anfang. Zweitens, welche Ressourcen sind verbindlich geschützt und was passiert, wenn die Linie sie trotzdem abzieht? Ohne das ist auch jeder Plan Makulatur. Also jeder Projektplan basiert ja auf der zumindest angenommenen Verfügbarkeit von Ressourcen. Wenn das nicht gegeben ist, ist alles andere Quatsch. Drittens, wer entscheidet bei Konflikten zwischen Linie, Sponsor, Fachbereich und Projekt? Und bitte auch innerhalb welcher Frist? Ganz klassisch, auch das sollte eigentlich geklärt sein für jedes Projekt. Wie findet Eskalation statt? Also wenn wir eine Entscheidung brauchen, die wir nicht treffen können oder die wir nochmal von einer anderen Stelle aus treffen lassen müssen. Viertens, was passiert, wenn Scope, Termin und Budget nicht mehr zusammenpassen? Also gibt es da eine Entscheidungslogik oder nur Erwartungsdruck? Und das wissen wir. Scope, Termin und Budget, das ist ganz klassisch, das magische Dreieck. Veränderst du eins, veränderst du mindestens ein weiteres. Das ist Projektmanagement-Grundlagenwissen, irgendwie erste Stunde in der Projektweiterbildung. Und das sollten auch eigentlich alle kapiert haben. Fünftens ist der Sponsor entscheidungsfähig oder nur interessiert? Interesse ist ja nett, Entscheidungen sind besser. Und auch da wieder, ich muss halt oder wir sollten dafür sorgen und die Sponsoren sollten wissen, was ihre Rolle ist, dass sie eben einfach das Projekt gut unterstützen und zwar verantwortlich. Und nicht irgendwie immer wieder nur reinschneiden, wenn es gerade doof ist. Sechstens gibt es ein gemeinsames Verständnis von Projekterfolg jenseits von Zeit, Budget und Scope. Also so etwas ähnliches wie Nutzen, Akzeptanz, Wirkung, Qualität, Lernwert. Also was zählt eigentlich wirklich? Und das wie das Thema mit den Stakeholdern, was ich gerade vorhin erzählt habe. Wenn wir kein gemeinsames Projektverständnis haben, schaut jeder aus seiner Brille und jeder aus seiner eigenen Erfolgsmessung. Und dann sind wir schon auf dem Weg in den Hauptgrund. Und siebtens übrigens, wird eine frühe rote Ampel unterstützt oder bestraft. Also diese Frage zeigt halt ziemlich schnell, ob ihr Steuerung wollt oder Beruhigung. Und ganz wichtig, das ist fast so ein kleines bisschen wie, wollt ihr angelogen werden oder wollt ihr wirklich echte Transparenz, mit der ihr was anfangen könnt. Die Frage ist eigentlich ganz einfach und eigentlich gar nicht stellenswürdig. Übrigens, wenn mehrere der Antworten auf diese sieben Fragen wehtun, dann habt ihr wahrscheinlich kein Projektleiterproblem, sondern dann habt ihr ein Projektsystem-Problem. Und das ist erstmal grundsätzlich eine gute Nachricht. Warum? Warum? Systeme kann man gestalten. Und das Ganze kannst du ja dann in den berühmten Montags-Move packen. Also ein wann löst man diese Dinge am besten? Am Montag. 15 Minuten Mandatsklärung. Ganz, ganz einfach auf das dementsprechende aktuelle Projekt schauen und mal einfach gemeinsam analysieren, wie ihr diese sieben Fragen da dementsprechend durchgehen könnt. Und dann sind wir nämlich schon beim Unterschied zwischen Beschwerde und Steuerung. Wie gesagt, die sieben detaillierten Fragen findest du im OnePager. Und eins möchte ich hier nochmal sauber abgrenzen. Methoden und Projektmanagement-Training, Kompetenzentwicklung bleiben wichtig. Aber wenn Projektleitungen dauerhaft in der Zange hängen, braucht es mehr als Methodenschulung. Das ist dann kompletter Quatsch. Dann braucht es Kompetenzaufbau an den Stellen, an denen Projekte kippen. Projektleitungen müssen lernen, Widersprüche präziser zu formulieren und Entscheidungen besser vorzubereiten. Sponsoren müssen lernen, ihre Rolle nicht als Statusinteresse, sondern als Führungsverantwortung zu verstehen. PMOs müssen lernen, nicht nur Berichte zu sammeln, sondern Entscheidungsqualität zu erhöhen. Und übrigens Linienorganisationen müssen lernen, dass Projektpriorität nicht bedeutet, wenn gerade nichts anderes brennt. Und übrigens, Geschäftsführungen müssen lernen, dass strategische Projekte nicht dadurch strategisch werden, dass sie so heißen. Sie werden strategisch, indem man sie schützt. Und deswegen vielleicht nochmal ein ganz kleiner Blick hier auf Führung.

Führung Und Projektsystem Richtig Bauen

SPEAKER_00

Führung darf von Projektleitungen auf jeden Fall Professionalität erwarten. Unbedingt. Saubre Planung, klare Kommunikation, frühe Eskalation, Risikoarbeit, kein Wegducken und schon gar kein Jammern. Das System ist schuld als Pauschalantwort, aber Führung muss aufhören, Projektleitungen als Ersatz für Governance und Entscheidungen zu benutzen. Wenn Sponsorentscheidungen fehlen, kann Projektleitung sie nicht herbeizaubern. Wenn Ressourcen nicht von anderen Stellen geschützt werden, kann Projektleitung sie nicht aus Kalendern heraus oder herein moderieren. Und wenn Scope politisch wächst, kann Projektleitung das Scope nicht einfach wegdiskutieren. Das mag ein bisschen unangenehm sein, aber es ist halt einfach Fakt. Und eine ganz wichtige Perspektive ist ja auch, das alles steuert nicht. Also wer bessere Projekte will, macht Projektleitungen nicht einfach härter. Das ist ja auch Quatsch, sondern er macht Projekte führbarer. Klare Mandate, geschützte Ressourcen, entscheidungsfähige Sponsoren und ehrliche Priorisierung sind da schon mal ein ganz guter Anfang. Und vielleicht noch ein Reporting, auf das dann Konsequenzen folgen. Das klingt irgendwie weniger glamourös, als die Suche nach der nächsten coolen Projektmanagement-Methode oder wir machen dann nochmal ein Projektmanagement-Training, dass unsere Projektleitungen es wirklich verstehen. Nein, das wirkt. Wenn wir ein Projektmanagements-System haben, das funktioniert, in dem sich dann kompetente Projektleitungen bewegen. Und die Wirkung ist in Projekten immer noch hilfreicher als irgendwie Heldenverehrung mit Burnout-Risiko.

Zusammenfassung Und Montag-Move

SPEAKER_00

Und deswegen lass uns mal auf diese Folge kurz gemeinsam zurückschauen und zusammenfassen. Projektmanager sind keine Blitzableiter. Sie sind keine Ersatzsponsoren und keine Risikomagier und irgendwie keine Konfliktentsorger und schon gar keine Wunderwaffe gegen schlechte Governance. Und übrigens auch nein, das heißt nicht, dass Projektleitungen aus der Verantwortung sind. Ganz im Gegenteil, gute Projektleitung heißt, die richtigen Widersprüche sichtbar, entscheidbar und bearbeitbar zu machen. Und aber eben auch nicht alles allein zu lösen, sondern das System so klar zu sehen, dass die richtigen Entscheidungen an der richtigen Stelle landen. Die sechs Zangen zeigen, wo es häufig kippt. Also Mandat ohne, oder andersrum, Verantwortung ohne Mandat. Ressourcen ohne Verbindlichkeit, Stakeholder ohne gemeinsames Erfolgsbild, Scope ohne Schutz, Sponsorship ohne Entscheidungen und Reporting ohne Konsequenz. Wenn diese sechs Punkte ungeklärt bleiben, dann wird Projektmanagement schnell zum Heldensport. Menschen kompensieren, beschwichtigen, retten, übersetzen und arbeiten nach. Und dann kittet irgendwie persönliche Energie, strukturelle Lücken, bis es halt nicht mehr geht. Das kann eine ganze Weile gut gehen. Und genau das ist das Gefährliche. Denn am Ende sieht es aus wie ein starkes Projektmanagement, ist aber nur ein grottenschlecht konstruiertes System mit sehr stark belasteten Menschen, die es irgendwann nicht mehr schaffen. Und deshalb die Endfrage: Wo nutzt eure Organisation Projektleitung gerade als Blitzableiter statt als Steuerungsrolle? Und wenn dir jetzt gerade ein konkretes Projekt eingefallen ist, dann ist das vielleicht dein Montag-Move. Nicht härter arbeiten, nicht noch ein Status-Deck, nicht noch ein Methoden-Refresh, sondern einfach mal Mandat klären. Was darf die Projektleitung entscheiden? Was ist verbindlich geschützt? Wer entscheidet Zielkonflikte und was passiert, wenn Scope, Termin und Budget nicht mehr zusammenpassen. Vielleicht auch noch, was heißt Erfolg wirklich? Wenn dir übrigens diese Folge geholfen hat oder du dir vorstellen kannst, dass sie einem anderen hilft, abonniere sie gern, empfehle sie gern weiter. Teil die Folge aber auch gerne mit jemandem, der gerade viel Projektverantwortung trägt und vielleicht zu wenig Mandat hat. Den Link zum OnePager findest du in den Shownotes. Und ich sage dir einfach ganz herzlichen Dank, dass du heute wieder mit mir hier dabei warst, über Projekte nachgedacht hast mit mir. Und ich wünsche dir, bis wir uns hier das nächste Mal wieder treffen. Natürlich allseits erfolgreiche Projekte. Bis dann. Vielen Dank, dass du heute mit dabei hast.