Projekte scheitern nicht an Methoden – sondern an Haltung
Projekte scheitern nicht an Tools – sie scheitern an dem, worüber wir nicht sprechen
70 % aller Projekte scheitern.
Nicht, weil irgendwo ein Jira-Board fehlt.
Sondern wegen Mustern, die in keinem Projektplan stehen.
Wir kennen die Bilder:
Status-Ampeln auf sattgrün, PowerPoint-Folien im Corporate Design – und alle wissen: So stimmt das niemals.
Zeit, ehrlich zu werden: Projekte sind keine technischen Vorhaben. Sie sind Organisationsentwicklung auf Zeit. Und genau dort fängt es an, weh zu tun.
1. Jedes Projekt ist eine Organisation – nur eben auf Zeit
In jeder Projektbeschreibung steht irgendetwas von Scope, Deliverables und Meilensteinen. Was fast nie drinsteht: Kultur, Entscheidungslogik und Haltung.
Dabei ist jedes Projekt eine Mini-Organisation – mit:
eigener Struktur (Rollen, Gremien, Eskalationswege)
eigener Kultur (wie hier wirklich gesprochen, entschieden, verschwiegen wird)
eigener Haltung (Wie gehen wir mit Unsicherheit, Macht, Fehlern um?)
Wenn wir das ignorieren, passiert Folgendes:
Das Team ist motiviert, die Methode sauber – und trotzdem kommt nichts Wirkliches raus.
Unklare Rollen führen zu Reibungsverlusten.
Verdeckte Machtspiele fressen Energie.
Ständig wechselnde Prioritäten zerstören Fokus.
Kurz: Alles, was in der Excel-Tabelle unsichtbar bleibt, entscheidet über Erfolg oder Frust.
Haltungsbasierte Organisationsentwicklung setzt genau hier an:
Sie versteht Projekte als sozio-technische Systeme. Tools, Menschen, Strukturen und Haltungen wirken immer gemeinsam. Wenn wir nur an den Tools drehen, drehen wir an der Oberfläche.
Pragmatiker-Frage fürs nächste Projekt-Setup:
Nicht nur: „Was sind die Deliverables?“
Sondern: „Welche Muster, Regeln und Haltungen prägen unser Miteinander – und behindern uns vielleicht?“
2. Agilität ist tot – als Methode gesehen
Scrum, Kanban, SAFe, PRINCE2 – die Toolbox ist voll. Und trotzdem scheitern rund 70 % aller Projekte. Der Grund liegt selten im Framework. Sondern im System, in dem es landen muss.
Ein paar Klassiker:
Prioritäten ändern sich wöchentlich. Und irgendwer nennt das dann „agil“. In Wahrheit ist es Kopflosigkeit.
Entscheidungen dauern Monate. Daily Stand-ups sind sinnlos, wenn es für jede Entscheidung drei Steering Committees braucht.
Führung ruft Selbstorganisation aus – und kontrolliert dann jeden Schritt. Autonomie ohne Vertrauen ist nur ein anderes Wort für Zynismus.
Keine Fehlerkultur. Alle spielen „Alles grün“, bis es zu spät ist. Agilität ist tot, wenn sie als Methodenkorsett eingeführt wird.
Echte Agilität beginnt dort, wo:
Strukturen Entscheidungsfähigkeit ermöglichen,
Kultur Offenheit zulässt,
Haltung Verantwortung teilt – statt sie nur zu predigen.
Frameworks sind Werkzeuge. Wirksam werden sie erst, wenn sie auf eine Organisation treffen, die bereit ist, sich selbst zu hinterfragen.
Frage fürs nächste Meeting:
„Was in unserer Organisation verhindert gerade, dass wir erfolgreich sind?“
Nicht: „Brauchen wir ein anderes Tool?“
3. Projektleiter:innen sind keine Taskmaster – sie sind Organisationsentwickler auf Zeit
Die alte Rolle: planen, steuern, überwachen.
Die neue Realität: Rahmen bauen, Blockaden lösen, Organisation gestalten.
Projekte sind keine Maschinen, die man „anschaltet“. Sie sind soziale Systeme. Mit Konflikten, Machtfragen, Unsicherheiten und unausgesprochenen Erwartungen. Wer hier nur Aufgaben verteilt, verliert.
Was Projektleiter:innen heute wirklich tun müssten:
Rollen klären. Wer entscheidet? Wer berät? Wer informiert? Rollenunklarheit ist einer der größten Produktivitätskiller.
Entscheidungswege sichtbar machen. Nichts lähmt Projekte mehr als Warten auf Antworten. Klare Entscheidungslogiken schaffen Tempo – und Verbindlichkeit.
Feedback- und Fehlerkultur etablieren. Fehler sind Lernmomente – wenn man sie offenlegt. Versteckte Fehler werden teuer.
Haltung vorleben. Offenheit, Klarheit, Mut – oder eben Misstrauen und Machtspiele. Projektleiter:innen sind Klimaanlagen: Sie stellen die Temperatur ein, in der gearbeitet wird. Projekte sind Mini-Organisationen.
Wer sie aktiv gestaltet, erhöht die Chance auf echten Mehrwert – nicht nur auf „Projekt abgeschlossen“-Häkchen.
Frage an Dich, wenn Du Projekte führst:
„Welche Blockade kann ich heute konkret aus dem Weg räumen, damit mein Team besser arbeiten kann?“
4. Die größte Lüge: „Wir haben alles im Griff“
Status-Meeting. Alle Folien perfekt, Ampeln grün, alle lächeln. Danach gehen alle raus und sagen im Flur: „Das fliegt uns um die Ohren.“ „Alles im Griff“ ist die gefährlichste Lüge im Projekt.
Sie sorgt dafür, dass:
Risiken vertuscht,
Probleme geschönt,
Chancen vergeben werden.
Aus Vertrauen wird Angst. Aus Lernen wird Kosmetik. Am Ende ist das Scheitern eine Überraschung, die keine war. Ein Projekt sollte kein Theaterraum sein, in dem wir die perfekte Fassade spielen.
Es sollte ein Raum für radikale Transparenz sein:
Risiken offenlegen, bevor sie eskalieren.
Probleme als gemeinsame Aufgabe begreifen – nicht als Schuldfrage.
Fortschritt ehrlich messen, statt Zahlen schönzufärben.
Führungskräfte, die sagen: „Danke fürs Ansprechen“ – nicht: „Wer ist schuld?“
Frage für Dein nächstes Status-Meeting:
Nicht: „Sind wir im Plan?“
Sondern: „Welche Wahrheit trauen wir uns heute noch nicht auszusprechen?“
5. Ohne Feedback- und Fehlerkultur ist jedes Projekt nur Theater
Schöne Folien, strukturierte Reports, agile Rituale – und trotzdem hat jede:r Angst, Fehler zuzugeben. Dann spielen alle Projekt – statt eines zu machen. Projekte scheitern selten an der Methode. Sie scheitern am fehlenden Mut, ehrlich zu sein.
Eine belastbare Feedback- und Fehlerkultur bedeutet:
Feedback ist Routine. Nicht nur in der Retro, sondern im Alltag.
Fehler sind Lernchancen. Wer sie offenlegt, spart Geld und Nerven. Wer sie versteckt, vervielfacht sie.
Mut zur Klarheit. Radikale Ehrlichkeit ist unbequem – aber der schnellste Weg zu Vertrauen.
Projekte sind soziale Systeme. Ohne psychologische Sicherheit ist jedes Reporting nur die Illusion von Kontrolle.
Konkreter Schritt - Entwickelt eine einfache Feedback-Charta im Team:
Wann geben wir Feedback, wie, wozu, und was lassen wir sein? Aus Unsicherheit wird so Verbindlichkeit.
6. Scoping: Die vergessene Königsdisziplin
Scoping ist die erste Organisationsentwicklungs-Übung im Projekt – und die meistignorierte. Ohne klaren Scope gibt es kein klares Projekt.
Ohne eindeutiges Ziel gibt es:
keine echte Planung,
keine Ausrichtung,
keine Messbarkeit.
Trotzdem hört man erstaunlich oft:
„Ihr wisst doch, wie es geht – fangt halt schon mal an.“
Ergebnis:
Chaos,
Zielkonflikte,
Projekte, die nicht mal sauber mit Unternehmenszielen verknüpft sind.
Wer nicht weiß, wo er hinwill, kann die Organisation nicht steuern. Scope ist kein Formular. Scope ist eine Entscheidung: Was tun wir (noch) nicht?
Meine These:
Wer Scoping überspringt, entwickelt keine Projekte – sondern Zufallsexperimente. Und das hat nichts mit Agilität zu tun. Nur mit Inkompetenz.
Frage an Dich:
Wann hast Du zuletzt erlebt, dass Scoping wirklich ernst genommen wurde – inklusive der Entscheidung, was bewusst nicht gemacht wird?
7. Transformation beginnt dort, wo Methoden an ihre Grenzen stoßen
Ob Führung, Scrum, Kanban oder klassisches Projektmanagement – überall zeigt sich das gleiche Muster:
Transformation beginnt dort, wo das bisherige Verständnis nicht mehr trägt.
Wo Führung aufhört zu funktionieren, weil Kontrolle und Alles-wissen-wollen in komplexen Umfeldern scheitern – und ein anderer Umgang mit Nichtwissen, Beziehung und Vertrauen nötig wird.
Wo Scrum aufhört, Methode zu sein, und zum Spiegel wird: Es zeigt Spannungen, Konflikte, Machtfragen. Die Frage ist nicht mehr: „Halten wir den Guide ein?“, sondern: „Was wird durch Scrum sichtbar – und was machen wir damit?“
Wo Kanban mehr zeigt als Arbeit, nämlich Haltung: Wie wir mit Limiten umgehen, mit Blockern, mit Prioritäten. Das Board wird vom Steuerungsinstrument zum Diagnosewerkzeug.
Wo klassisches Projektmanagement an seine Grenzen stößt, weil Gantt-Diagramme Stabilität versprechen, die die Realität nicht mehr hergibt. Der Plan ist Hypothese, nicht Wahrheit.
Allen gemeinsam ist:
Nicht die Methode entscheidet, sondern die Haltung, mit der wir sie leben. Transformation ist kein neues Framework. Transformation ist die Bereitschaft, die eigenen Bilder von Führung, Kontrolle, Verantwortung und Erfolg neu zu justieren.
8. Projekte als Trainingsräume für Organisationen
Projekte sind mehr als Auftragsarbeit. Sie sind Mini-Organisationen, in denen Zukunft geübt wird.
In Projekten wird sichtbar:
wie wir führen,
wie wir entscheiden,
wie wir mit Unsicherheit umgehen,
wie ehrlich wir miteinander sind.
Wenn wir Projekte bewusst als Entwicklungsräume gestalten:
erkennen wir Muster, die auch im großen System wirken (Konflikte, Machtspiele, Entscheidungsstaus),
entwickeln wir Führung, Kultur und Zusammenarbeit weiter,
schaffen wir Strukturen, die skalierbar sind: klare Rollen, transparente Entscheidungswege, belastbare Feedbackkultur.
Organisationsentwicklung passiert nicht neben Projekten. Sie ist das Projekt – wenn wir es zulassen.
Frage fürs nächste Projekt-Review:
Nicht nur: „Haben wir geliefert?“
Sondern: „Was hat uns als Organisation in diesem Projekt reifer gemacht?“
Und jetzt?
Wenn Du bis hierher gelesen hast, dann vermutlich, weil Du eines kennst:
Projekte, die „eigentlich gut aufgesetzt“ waren – und trotzdem schleichend kaputtgingen.
Rituale, die perfekt liefen – und nichts verändert haben.
Führungskräfte, die Kontrolle nicht loslassen konnten – und damit jede Transformation im Keim erstickt haben.
Die schlechte Nachricht: Methoden allein werden das nicht lösen.
Die gute Nachricht: Du musst nicht die ganze Organisation „transformieren“, um etwas zu bewegen.
Du kannst im nächsten Projekt anfangen:
Scope wirklich klären.
Rollen und Entscheidungswege radikal transparent machen.
Lügen-Statusrunden beenden.
Eine echte Feedback- und Fehlerkultur einfordern – und vorleben.
Dich selbst als Organisationsentwickler:in auf Zeit verstehen.
Vielleicht scheitern dann nicht weniger Projekte an der Komplexität der Welt. Aber deutlich weniger an unserer Weigerung, ehrlich hinzuschauen.



