Zertifiziert ins Abseits: Was PRINCE2, SAFe und Scrum wirklich taugen – und warum KI die Frage neu stellt

Ich werde jetzt etwas sagen, das Trainingsanbieter nicht hören wollen, HR-Abteilungen nicht wahrhaben wollen und viele Projektmanager insgeheim wissen, aber selten aussprechen: Ein Zertifikat macht niemanden zu einem besseren Projektmanager.

Das ist kein Angriff auf PRINCE2, SAFe oder Scrum. Alle drei Frameworks haben ihren Platz, ihre Logik, ihren nachweisbaren Nutzen – wenn man versteht, wofür sie entwickelt wurden. Aber die Zertifizierungsindustrie, die sich um sie herum aufgebaut hat, verkauft eine Illusion: dass methodisches Wissen kausal mit Projekterfolg zusammenhängt.

Es hängt nicht!

Gleichzeitig stellt der Einzug von KI in Planung, Steuerung, Entwicklung und Dokumentation die gesamte Frage neu auf – und radikaler, als die meisten Methodenadvokaten bereit sind zuzugeben.

Ich habe vierzehn Jahre als CIO Projekte verantwortet. Seit 2020 begleite ich als Interim Manager und Berater mittelständische Unternehmen bei IT-Transformationen, ISMS-Aufbau und strategischer Führung. Was ich in dieser Zeit gesehen habe, ist kein Plädoyer für oder gegen ein bestimmtes Framework. Es ist eine Bestandsaufnahme, die ich mir vor zehn Jahren gewünscht hätte.

Drei Frameworks – und die Frage, die sie wirklich beantworten

Der erste und häufigste Fehler in der Methoden-Debatte: Frameworks werden verglichen, als würden sie dasselbe lösen wollen. Das tun sie nicht.

PRINCE2 wurde entwickelt, um eine spezifische Katastrophe zu verhindern: Projekte, bei denen am Ende niemand sagen kann, wer welche Entscheidung hätte treffen dürfen, wer für den Schaden verantwortlich ist und warum niemand früher eingegriffen hat. Es ist ein Gouvernanz-Framework, kein Entwicklungsframework. Die sieben Prinzipien, sieben Themen und sieben Prozesse sind die konsequent durchgezogene Antwort auf eine Frage, die in öffentlichen Beschaffungsprojekten und Großunternehmen regelmäßig ignoriert wird: Wer entscheidet was – und auf welcher Grundlage?

Der Business Case als zentrales Steuerungsinstrument ist kein bürokratisches Relikt. Er ist die Formalisierung einer Frage, die jedes Projekt beantworten muss:

Warum machen wir das überhaupt – und unter welchen Bedingungen würden wir aufhören?

Das Ausnahmeprinzip – delegierte Autorität mit definierten Toleranzen, Eskalation nur bei Abweichung – ist kein Misstrauensvotum gegenüber dem Projektmanager. Es ist die einzige Art, einen Lenkungsausschuss davon abzuhalten, sich in operative Details einzumischen, für die er weder die Zeit noch die Information hat.

SAFe löst ein anderes Problem: die Koordination von Agilität im Großformat. Wenn zwanzig Scrum-Teams an einem Produkt arbeiten, ohne Synchronisation, entstehen Abhängigkeitsprobleme, Integrations-Hölle und strategische Drift. Der Agile Release Train als virtuelle Organisationseinheit, das Program Increment als synchronisierter Planungs- und Lieferrhythmus, WSJF als ökonomisches Priorisierungswerkzeug – SAFe ist der Versuch, Lean-Agile-Prinzipien auf Unternehmensebene zu operationalisieren.

Es ist komplex. Manche sagen: zu komplex.

Und sie haben in bestimmten Kontexten recht. SAFe in einem Unternehmen mit drei Entwicklungsteams einzuführen ist wie einen Sattelzug zu kaufen, um Brötchen zu holen. Das eigentliche SAFe-Problem ist nicht das Framework. Es ist die Tendenz von Organisationen, SAFe-Strukturen einzuführen, ohne das Lean-Agile-Mindset zu entwickeln, das diese Strukturen voraussetzen.

PI Planning mit Wasserfall-Führung produziert keine Agilität. Es produziert aufwändig geplanten Wasserfall mit agiler Terminologie.

Scrum ist das Gegenteil von PRINCE2 in fast jeder Dimension: radikal schlank, absichtlich unvollständig, empirisch statt plangetrieben. Der Scrum Guide 2020 hat dreizehn Seiten. Das ist keine Nachlässigkeit – es ist eine Designentscheidung. Scrum gibt Teams einen Rhythmus und eine Struktur für Inspektion und Adaption, definiert drei Verantwortlichkeiten, fünf Events und drei Artefakte – und überlässt alles andere dem Team.

Die Stärke von Scrum liegt nicht in seiner Vollständigkeit. Sie liegt in seiner Ehrlichkeit über Komplexität:

Wer nicht weiß, was er in drei Monaten braucht, sollte nicht so tun als ob.

Drei Frameworks. Drei legitime Antworten auf drei verschiedene Fragen.

Der Fehler beginnt dort, wo man vergisst, welche Frage gestellt wurde.

Die Zertifizierungsindustrie und ihr schmutziges Geheimnis

Es gibt eine Zahl, die selten in denselben Gesprächen auftaucht wie Zertifizierungsquoten: Projektscheitererquoten.

Die Datenlage ist erdrückend – und sie wird nicht besser, egal welche Quelle man heranzieht.

Die Standish Group veröffentlicht seit 1994 den CHAOS Report – die bekannteste Langzeitstudie im Bereich IT-Projektmanagement, basierend auf über 50.000 untersuchten Projekten weltweit. Die Zahlen sind seit Jahrzehnten erschreckend stabil: Nur rund 31 % aller IT-Projekte gelten als erfolgreich – abgeschlossen in Zeit, in Budget, mit zufriedenstellendem Ergebnis. 50 % sind "challenged", 19 % scheitern vollständig. Für Großunternehmen liegt die Erfolgsquote unter 10 %. Kleine Projekte schneiden mit rund 90 % deutlich besser ab – ein Hinweis darauf, was wirklich zählt: Überschaubarkeit, kurze Feedbackschleifen, klare Verantwortung.

Wer glaubt, das sei eine veraltete Zahl aus einer anderen Zeit, irrt. Aktuellere Studien bestätigen das Bild – und verschärfen es:

Bain & Company (2024): 88 % aller Business Transformations erreichen ihre ursprünglichen Ziele nicht.

McKinsey hat 2020 das vielleicht erschreckendste Einzelergebnis geliefert: 17 % aller großen IT-Projekte laufen so schlecht, dass sie die Existenz des Unternehmens gefährden.

Nicht das Quartalsergebnis. Die Existenz!

Für den deutschsprachigen Mittelstand ist die BITKOM-Studie relevant: In ihrer Publikation „Heiter Scheitern im Projekt" (2021) hält der Branchenverband fest, dass über 70 % aller Fehlerursachen in IT-Projekten in der frühen Projektphase entstehen – also genau dort, wo Anforderungen erhoben, abgestimmt und priorisiert werden. Häufigste Ursachen: unklare Zieldefinition, fehlende Priorisierung, Stakeholder zu spät eingebunden. Nichts davon ist neu. Nichts davon hat sich durch dreißig Jahre Methodenflut grundlegend verändert.

Diese Zahlen haben sich trotz eines massiven Wachstums der Zertifizierungsindustrie nicht dramatisch verbessert.

Das ist kein Zufall. Es ist ein Symptom.

Zertifikate bescheinigen Methodenwissen. PSM I bescheinigt, dass jemand den Scrum Guide verstanden hat – die 85-%-Hürde bei 80 Fragen in 60 Minuten ist tatsächlich anspruchsvoll. PRINCE2 Foundation bescheinigt Verständnis der Methode, keine Anwendungskompetenz. SAFe Agilist bescheinigt zwei Tage Training und eine bestandene Multiple-Choice-Prüfung mit 77-%-Grenze.

Was kein Zertifikat bescheinigt: die Fähigkeit, in einer Organisation mit konfligierenden Interessen, unklaren Prioritäten und unzureichender Entscheidungsbereitschaft ein Projekt erfolgreich zu steuern.

Das ist keine Kritik an Zertifizierungen als Konzept. Eine gemeinsame Sprache hat Wert. Wenn ich als Interim Manager in ein Unternehmen komme und jemand sagt: „Wir arbeiten nach PRINCE2", dann weiß ich, dass es Phasenpläne gibt, dass der Lenkungsausschuss formal strukturiert ist und dass der Business Case ein zentrales Steuerungsdokument sein sollte. Das spart Zeit.

Aber Bekanntschaft mit einer Methode ist der Anfang, nicht das Ende eines Lernprozesses. Das Problem mit der Zertifizierungsindustrie ist nicht die Zertifizierung selbst. Es ist die Verwechslung von Signaling mit Substanz – auf allen Seiten. Unternehmen kaufen Zertifikate als Risikovermeidung ein. Berater tragen sie als Qualitätsbeweis vor. HR-Abteilungen nutzen sie als Filter. Und am Ende sitzt jemand im Kick-off-Meeting, der formal alle richtigen Häkchen gesetzt hat – und zum ersten Mal wirklich versteht, wie schwierig das wird.

Methodik als Religion – das gefährlichste Phänomen der Branche

Hier ist das Phänomen, das mich in meiner Praxis am meisten beschäftigt – und das in keiner Zertifizierungsdiskussion vorkommt, weil es die gesamte Debatte delegitimieren würde:

Projektmanagement-Methoden werden von ihren Anhängern wie Religionen betrieben.

Ich meine das nicht metaphorisch. Ich meine es strukturell.

Religionen haben heilige Texte. Scrum hat den Scrum Guide. SAFe hat das Big Picture. PRINCE2 hat das offizielle Handbuch. Diese Texte werden studiert, zitiert und ausgelegt – und wer von ihnen abweicht, hat sich zu rechtfertigen. Wer das Daily Scrum auf zwanzig Minuten verlängert, weil das Team gerade ein kritisches Problem debuggt, verletzt den Guide. Wer in einem PRINCE2-Projekt einen Phasenbericht weglässt, weil alle relevanten Informationen im nächsten Lenkungsausschuss ohnehin mündlich besprochen werden, bricht das Regelwerk. Die Konformität mit dem Text wird über die Konsequenz für das Projekt gestellt.

Religionen haben Priester. Certified SAFe Program Consultants. PRINCE2 Practitioner und Trainer. Professional Scrum Trainers. Menschen, die die Auslegungshoheit über den heiligen Text besitzen und von deren Zertifizierungsprogrammen andere abhängig sind. Ihre wirtschaftlichen Interessen liegen in der Komplexität des Systems: Wer das Framework einfach versteht, braucht keinen Coach mehr.

Religionen haben Ketzer. Wer in einer Scrum-Community sagt, dass Story Points kontraproduktiv sind, bekommt Gegenwind – obwohl der Scrum Guide selbst kein Schätzsystem vorschreibt. Wer in einem PRINCE2-Umfeld vorschlägt, den Projektbrief auf eine Seite zu reduzieren, gilt als methodisch unkorrekt. Wer SAFe für ein mittelgroßes Unternehmen als Overengineering bezeichnet, muss sich gegen die Framework-Jünger verteidigen, die jede Kritik als Verständnislücke interpretieren.

Und dann gibt es die unbequemen Studien, die die Gemeinschaft lieber ignoriert. Eine davon stammt aus 2024: Engprax, ein britisches Forschungsunternehmen, hat in einer Studie mit 600 Software-Ingenieuren in UK und USA erhoben, wie Methodik und Projekterfolg zusammenhängen. Das Ergebnis dürfte in vielen Agile-Communitys für Unruhe sorgen: 65 % der Projekte, die agile Anforderungspraktiken einsetzten, wurden nicht pünktlich, im Budget und in ausreichender Qualität geliefert. Noch brisanter: Projekte mit dokumentierten Anforderungen vor Projektstart waren 50 % häufiger erfolgreich – Projekte mit klar definierten Anforderungen sogar 97 % häufiger.

Das ist kein Plädoyer für Wasserfall. Es ist ein Befund über das, was in der Agile-Praxis häufig unter den Tisch fällt: Klare Anforderungen sind kein bürokratisches Relikt. Sie sind Voraussetzung für jeden Liefererfolg – unabhängig davon, welches Framework man verwendet. Wer das im Namen von Agilität aufgibt, hat eine Methode zur Ideologie erhoben.

Das Gefährlichste an Methodenreligionen ist nicht der Dogmatismus. Es ist die Art, wie sie Lernen unterbinden.

Wenn das Framework immer richtig ist und das Scheitern immer die Umsetzung schuld hat, gibt es nichts zu überprüfen. Der Business Case war gut – die Führung hat ihn nur nicht konsequent verfolgt. Der Agile Release Train war richtig – die Teams haben Scrum nicht wirklich gelebt. Die Retrospektive war korrekt durchgeführt – aber die Maßnahmen wurden nicht umgesetzt. Das ist die eleganteste Immunisierungsstrategie der Beratungsbranche:

Das Framework hat immer recht. Wenn das Projekt scheitert, hat jemand das Framework nicht richtig angewendet. Wenn das Projekt gelingt, war es das Framework. Widerlegen kann man das nicht – und das ist kein Zufall.

Das ist ein erkenntnistheoretisches Problem – und ein praktisches. Ich habe Projekte erlebt, in denen Teams das Framework methodisch korrekt durchgeführt haben und gleichzeitig in der falschen Richtung liefen. Wöchentliche Statusberichte, gepflegte Risikoregister, ordentliche Phasenübergänge – und ein Produkt, das am Markt vorbeiging. Die Methodik war tadellos. Das Denken dahinter war falsch.

Das andere Extrem ist genauso problematisch: die Methodenverächter, die bei jeder Struktur reflexartig von Bürokratie sprechen und "einfach loslegen" als Tugend propagieren. Auch das ist eine Form von Dogmatismus – nur im Gewand der Pragmatik. Wer glaubt, dass gute Teams keine Struktur brauchen, hat noch nie gesehen, wie ein hochtalentiertes Team an unklaren Verantwortlichkeiten, fehlenden Entscheidungsstrukturen und unkontrollierten Änderungen zerfällt.

Die Wahrheit liegt weder bei den Methodengläubigen noch bei den Methodenverächtern. Sie liegt dort, wo Frameworks als das behandelt werden, was sie sind:

Werkzeuge. Ein Hammer ist nützlich, wenn man einen Nagel einschlagen will. Er ist sinnlos, wenn man eine Schraube befestigen will. Und er wird gefährlich, wenn jemand ihn benutzt, ohne zu wissen, was er damit baut.

Was wäre die Alternative zum religiösen Umgang mit Methodik? Eine situative Kompetenz, die ich als methodische Urteilskraft bezeichnen würde:

die Fähigkeit, aus einem Portfolio von Frameworks und Praktiken das Passende auszuwählen, es auf die konkrete Situation anzupassen – und es loszulassen, wenn es nicht mehr passt. Das lässt sich nicht zertifizieren. Sie entsteht aus Erfahrung und aus der Disziplin, Methoden konsequent am Ergebnis zu messen – nicht am Regelwerk.

Der Standish Report gibt uns dabei einen unerbittlichen Spiegel: Dreißig Jahre Methodik-Proliferation, Millionen von Zertifikatsinhabern, und noch immer scheitert mehr als die Hälfte aller Projekte. Das sollte uns bescheidener machen – gegenüber den Frameworks und gegenüber uns selbst.

Warum Projekte wirklich scheitern

Aus meiner Erfahrung – und das deckt sich mit dem, was Standish und andere untersucht haben – scheitern Projekte aus einer überschaubaren Anzahl struktureller Gründe:

Anforderungen, die niemand wirklich kennt. Nicht weil sie nicht formuliert wurden, sondern weil die Formulierung eine Scheingenauigkeit erzeugt hat, die keiner hinterfragt hat.

Fehlende Entscheidungsbereitschaft in der Führung. Lenkungsausschüsse, die sich um operative Details streiten und strategische Entscheidungen vertagen. Auftraggeber, die Risiken weg-genehmigen statt sie zu adressieren.

Ressourcenkonkurrenz ohne Governance. Entwickler, die gleichzeitig in fünf Projekten laufen. Prioritätsentscheidungen, die informell, inkonsequent und unsichtbar getroffen werden.

Politische Dynamiken, die niemand benennt. Abteilungsleiter, die Projekte blockieren, weil sie Kompetenzverschiebungen fürchten. Entscheider, die Informationen zurückhalten, weil Transparenz ihre Position schwächt.

Kein Framework löst diese Probleme. Aber gute Methodik macht sie sichtbarer, früher, klarer. Und das ist ihr eigentlicher Wert: nicht die Prozessstruktur, sondern die Transparenz, die diese Struktur erzeugt.

Methodik verstärkt, was vorhanden ist. Gute Führung plus konsequente Methodik ergibt exzellente Projektsteuerung. Dysfunktionale Führung plus konsequente Methodik ergibt strukturiertes Chaos mit Berichtwesen.

Eine Organisation, die nicht bereit ist, auf das zu reagieren, was transparent wird, wird durch PRINCE2 besser dokumentiert scheitern. Durch SAFe mit mehr Meetings. Durch Scrum schneller und sichtbarer vor die Wand fahren.

KI verändert die Spielregeln – aber nicht die, die alle meinen

Jetzt zur eigentlich provokanten Frage:

Was macht der Einzug von KI in die Projektarbeit?

Die häufigste Antwort, die ich höre: KI übernimmt die Routinearbeit, und der Mensch konzentriert sich auf das Strategische. Das ist richtig – und gleichzeitig unvollständig auf eine Art, die gefährlich ist.

Bevor wir zu den Frameworks kommen, lohnt sich ein Blick auf eine Zahl, die in KI-Euphorie-Gesprächen regelmäßig fehlt: Gartner schätzt, dass 85 % aller KI-Projekte scheitern – und 87 % aller F&E-Projekte nie die Produktionsreife erreichen (2023). Das ist kein Argument gegen KI. Es ist ein Argument dafür, dass neue Technologien dieselben Governance-Fragen aufwerfen wie alte – und dass methodisches Denken in KI-Projekten genauso relevant ist wie in klassischen IT-Projekten. Nur schneller. Und teurer, wenn man es falsch macht.

KI-Systeme können heute Statusberichte aus Projektdaten generieren, Risikoregister aus Projekthistorien anreichern, Backlog-Items aus Anforderungsdokumenten ableiten, Testfälle schreiben, Code reviewen, Dokumentation erzeugen. Das komprimiert den operativen Aufwand eines Projekts – nicht auf null, aber spürbar.

Was bedeutet das für die Frameworks?

Für PRINCE2: Die dokumentenintensive Natur des Frameworks war immer sein größter Kritikpunkt. KI kann diesen Aufwand erheblich reduzieren – Templates werden zu aktiven, befüllten Dokumenten, Risikoregister werden automatisch angereichert, Fortschrittsberichte aus Projektdaten generiert. Das ändert die Gouvernanz-Logik nicht. Was PRINCE2 wertvoll macht, ist nicht die Dokumentation. Es ist die Entscheidungsstruktur dahinter. Die wird wichtiger, nicht unwichtiger.

Für SAFe: Die größte KI-Hebelwirkung liegt im PI Planning. KI kann Abhängigkeiten zwischen Features automatisch aus Codebasis und Architekturmodellen ableiten, Kapazitätsmodelle über Teams hinweg generieren, WSJF-Berechnungen auf Basis historischer Velocity unterstützen. Das erhöht die Informationsbasis, auf der die eigentlich wertvolle Arbeit stattfindet: die Diskussion über Prioritäten, Abhängigkeiten und strategische Ausrichtung.

Für Scrum: Wenn Developers mit KI-gestützten Entwicklungsumgebungen arbeiten, steigt die Velocity. Das klingt gut. Aber es verschiebt den Engpass. Der Engpass in Scrum war selten die Entwicklungskapazität – er war die Qualität der Anforderungen, die Klarheit des Sprint Goals, die Entscheidungsbereitschaft des Product Owners.

Wenn Developers schneller werden, ohne dass sich die Qualität des Product Backlogs verbessert, liefert man schneller das Falsche.

Der Product Owner wird nicht unwichtiger. Er wird kritischer.

Was KI definitiv nicht übernimmt

Hier ist die Liste der Dinge, die ich für nicht automatisierbar halte – zumindest nicht auf die Art, die in Projekten tatsächlich zählt:

Die Retrospektive, in der jemand ausspricht, was wirklich nicht funktioniert. KI kann Retrospektiven-Vorlagen generieren. Aber die Dynamik, die entsteht, wenn ein Team zum ersten Mal offen über ein strukturelles Problem spricht – die erfordert psychologische Sicherheit, die Menschen aufbauen und Menschen zerstören können.

Das PI Planning, in dem Business Owner und Entwickler merken, dass ihre Annahmen fundamental unterschiedlich sind. Diese Erkenntnis und ihre produktive Auflösung ist der eigentliche Wert von PI Planning. Nicht die Planung selbst. Die Begegnung.

Die Eskalation, die niemand will, aber die notwendig ist. Ein KI-System kann errechnen, dass die Fortführung eines Projekts wirtschaftlich nicht sinnvoll ist. Wer steht im Lenkungsausschuss auf und sagt es?

Die politische Navigation in Entscheidungssituationen mit konfligierenden Interessen. Das Projekt, das zwei Abteilungsleiter sich gegenseitig blockieren. Die Beschaffung, bei der jemand einen strategischen Vorteil aus dem Scheitern des Projekts hätte. Diese Situationen erfordern Urteilsvermögen, das aus Erfahrung, Kontextkenntnis und menschlichem Verständnis entsteht.

KI ist ein exzellentes Werkzeug, um die Informationsbasis für Entscheidungen zu verbessern. Sie ist kein Ersatz für die Kompetenz, diese Entscheidungen in komplexen menschlichen Systemen zu treffen und durchzusetzen.

Was das für die Praxis bedeutet

Vier konkrete Schlussfolgerungen – nicht als allgemeine Weisheiten, sondern als operative Einschätzungen aus der Beratungspraxis:

Erstens: Das Gewicht der Methodik verschiebt sich von operativ zu strategisch. Die operative Seite – Berichte, Dokumentation, Tracking – wird zunehmend von KI unterstützt. Die strategische Seite – Governance-Strukturen, Entscheidungsarchitektur, Eskalationsmechanismen, Business-Case-Qualität – wird wichtiger. Wer PRINCE2 als Dokumentationsrahmen versteht, verliert durch KI seinen wahrgenommenen Hauptnutzen. Wer es als Governance-Framework versteht, gewinnt Zeit.

Zweitens: Die Methodenwahl muss zur Situation passen – nicht zum Lebenslauf. Ein mittelständisches Unternehmen mit vier simultanen IT-Projekten braucht kein SAFe. Es braucht klare Prioritätsentscheidungen, belastbare Business Cases und eine Entscheidungsstruktur, die Eskalationen handhabbar macht. Das setzt voraus, dass man alle drei Methoden kennt und keine davon ideologisch verteidigt.

Drittens: KI verändert das Kompetenzprofil des Projektmanagers. Statusberichte schreiben, Risikoregister pflegen, Meeting-Protokolle führen – das schrumpft. Was wächst: die Fähigkeit, KI-generierte Informationen kritisch zu bewerten. Die Fähigkeit, in unsicheren Situationen Entscheidungen zu ermöglichen statt sie zu vertagen. Das ist keine neue Kompetenz. Es ist eine alte, die bisher im operativen Lärm oft unterging. KI entfernt einen Teil des Lärms. Was übrig bleibt, ist die eigentliche Arbeit.

Viertens: Zertifikate sind Marktsignale – keine Kompetenznachweise. Sie sagen: Ich spreche die Sprache, ich kenne die Konzepte. Das hat Wert. Aber es ist nicht dasselbe wie Können. PRINCE2 Foundation ist der Anfang einer Auseinandersetzung mit Governance, nicht ihr Abschluss. PSM I beweist, dass man Scrum verstanden hat – nicht, dass man ein Team durch einen schwierigen Sprint führen kann. Das Zertifikat öffnet die Tür. Was dahinter liegt, muss man selbst erkunden.

Eine unbequeme Abschlussthese

Die Zertifizierungsindustrie wird durch KI nicht kleiner werden. Sie wird wachsen.

KI-Unsicherheit erzeugt Weiterbildungsbedarf, und Weiterbildungsbedarf erzeugt Zertifikate.

Es wird Dutzende neue Zertifikate für KI-unterstütztes Projektmanagement, Agentic Delivery, AI-Governance in Projekten geben. Manche davon werden Substanz haben. Viele werden Signaling-Fahrzeuge sein.

Und die Projektscheiterzahlen werden sich in zehn Jahren vermutlich kaum bewegt haben. Nicht weil die Frameworks schlechter werden. Nicht weil KI nicht hilft. Sondern weil das Problem nie in den Frameworks lag – und KI allein kein Führungsproblem löst.

Die eigentliche Kompetenz – das Urteilsvermögen, in komplexen, politisch aufgeladenen, ressourcenbeschränkten Situationen Projekte erfolgreich zu steuern – lässt sich nicht zertifizieren.

Sie entsteht aus Erfahrung, aus dem ehrlichen Umgang mit dem eigenen Scheitern und aus der Bereitschaft, Methoden als Werkzeuge zu begreifen, nicht als Glaubensbekenntnisse.

PRINCE2, SAFe, Scrum sind gute Werkzeuge. KI ist ein weiteres. Wer weiß, wofür man sie einsetzt – und wofür nicht – hat einen Vorsprung, den kein Zertifikat ausstellt.

Alles andere ist zertifiziertes Wunschdenken!

Gerd Kopp ist Interim Manager und Berater für Mittelstandsunternehmen. Er schreibt über IT-Governance, KI-Strategie und die Realität des Projektgeschäfts auf gerds-blog.de. Beratungsanfragen über gerds-it.de.

Quellen:

• Standish Group. CHAOS Report 2020: Beyond Infinity. standishgroup.com
• Standish Group. The CHAOS Report – Langzeitstudie seit 1994, über 50.000 Projekte analysiert
• Varajão, J. et al. (2024). Assessing IT Project Success: Perception vs. Reality. ACM Queue, Vol. 22, No. 4
• Bain & Company (2024). 88% of Business Transformations Fail to Achieve Their Original Ambitions. bain.com
• McKinsey & Company (2020). Delivering large-scale IT projects on time, on budget, and on value. mckinsey.com
• Ali, J. (2024). Impact Engineering – 268% Higher Failure Rates for Agile Software Projects. Engprax / J.L. Partners
• Gartner (2023). Zitiert in: Sourcing Innovation, Two and a Half Decades of Project Failure (Oktober 2024)
• BITKOM e.V. (2021). Heiter Scheitern im Projekt. Arbeitskreis Projektmanagement, Oktober 2021. bitkom.org
• Schwaber, K. & Sutherland, J. The Scrum Guide 2020. scrumguides.org
• PeopleCert / AXELOS. Managing Successful Projects with PRINCE2, 7th Edition.
• Scaled Agile, Inc. SAFe 6.0 Framework. scaledagile.com

Excerpt (lang, für Social / Newsletter): PRINCE2, SAFe, Scrum – drei Frameworks, Millionen von Zertifikatsinhabern, und eine Projektscheitererquote, die seit Jahrzehnten kaum sinkt. Was stimmt da nicht? Und was passiert, wenn KI-Systeme beginnen, genau die Aufgaben zu übernehmen, für die diese Methoden ursprünglich entwickelt wurden? Ein Blick aus der Praxis – und einer, der unbequem ist.