Über das Versprechen und die stillen Grenzen großer Sprachmodelle im Projektmanagement.
Bevor wir sinnvoll über KI im Projektmanagement sprechen, müssen wir verstehen, was Projektarbeit eigentlich ausmacht. Projektmanagement ist nicht einfach operative Arbeit mit Gantt-Diagramm. Es hat eine eigene Qualität: Projekte verbinden Ziele, Menschen, Budgets, Abhängigkeiten und technische Entscheidungen unter Bedingungen, die selten vollständig stabil sind. Wer eine Softwarearchitektur festlegt, einen Dienstleister auswählt, einen Rollout startet oder eine Organisation durch eine Migration führt, trifft Entscheidungen, die sich später nicht beliebig korrigieren lassen. Zumindest nicht ohne Kosten, Reibung und politische Nebenwirkungen.
Hinzu kommt eine Komplexität, die sich nicht durch mehr Statusberichte auflösen lässt. Regulatorik, Legacy-Systeme, Lieferanten, Schnittstellen, Betriebsräte, Fachbereiche, Budgets, Verfügbarkeiten: All das interagiert dynamisch. Ein Projektplan ist deshalb nie die Wirklichkeit, sondern eine Hypothese über die Wirklichkeit. Und wer meint, ein Sprachmodell könne diese Unsicherheit beseitigen, hat Sprachmodelle missverstanden. Zusätzliche Unsicherheit tut einem Projekt selten gut.
Trotzdem lohnt der nüchterne Blick darauf, wie KI in Projekten sinnvoll eingebunden werden kann.
Die Stufenleiter der Automatisierung
Aber von welcher KI sprechen wir überhaupt? Von welcher Art der Technisierung? Es existiert eine Bandbreite, die wir mal kurz aufdröseln.
Der einfachste Schritt ist der bekannte: der Chatbot als Gesprächspartner, der auf einen Prompt reagiert, Risiken formuliert, Stakeholder-Analysen skizziert, Statusberichte glättet oder Meeting-Protokolle verdichtet. Nützlich, ja. Aber begrenzt: Der Mensch muss die Ergebnisse manuell weiterverarbeiten, und das Modell kennt weder die Projektgeschichte noch die politischen Zwischentöne oder die Großwetterlage.
Ein Schritt weiter geht die Anbindung interner Quellen, die auch als Retrieval-Augmented Generation (RAG) bekannt ist. Projektpläne, Beschlüsse, Jira-Tickets, Confluence-Seiten, Architekturentscheidungen, Verträge, Protokolle: Greift das Modell darauf zu, ohne dass der Nutzer jede Sitzung neu befüllt, steigt die Qualität der Antworten spürbar. Das Modell arbeitet dann nicht mehr nur mit allgemeinem Projektmanagement-Wissen, sondern mit dem, was im konkreten Projekt tatsächlich gilt.
Die derzeit höchste Stufe sind Agenten: Systeme, die eigenständig Tickets analysieren, Abhängigkeiten erkennen, offene Punkte nachverfolgen, Risiken aus Protokollen extrahieren oder Statusinformationen aus verschiedenen Quellen zusammenführen. Klingt verlockend.
Aber Agenten sparen nicht automatisch Zeit, sie verschieben Aufgaben. Wo früher jemand Informationen zusammensuchte, muss nun jemand Datenqualität sichern, Workflows definieren, Berechtigungen pflegen und Outputs kontrollieren. Die kognitive Last verschwindet nicht. Sie wandert an eine andere Stelle. Das ist kein Fehler des Systems, sondern seine Natur. So funktioniert das.
Was KI wirklich gut kann: der Blick von außen
Sinnvolle Einsatzfelder gibt es dennoch, und wir sollten sie nüchtern benennen. Interessanter als die Frage nach Automatisierung ist eine andere: Was kann ein Sprachmodell, was ein Projektteam strukturell oft nicht kann?
Die Antwort liegt in der sozialen Architektur von Projekten. Projektteams entwickeln Dynamiken: Gruppendenken, Abhängigkeiten, Stakeholder-Diplomatie, die stille Übereinkunft, Probleme nicht zu früh zu groß erscheinen zu lassen. Ein Sprachmodell kennt diese sozialen Kosten nicht. Es hat kein Interesse an der nächsten Lenkungsausschuss-Sitzung, keine Angst vor dem Sponsor, keine Loyalität zu einem Lieblingslieferanten und keinen Reflex, schlechte Nachrichten weichzuspülen. Fordert man es auf, einen Projektplan zu zerlegen, findet es Schwächen und formuliert sie ohne Zögern. Darin ähneln Sprachmodelle Freelancern. Man holt sie genau deshalb rein, weil sie nicht Teil des Gefüges sind.
Das ist kein Nebenaspekt. Red-Teaming gehört zu den wirksamsten Methoden im Projektmanagement und zu den am häufigsten vernachlässigten. Setzt man ein Sprachmodell als Devil’s Advocate ein, produziert es Einwände, die im Team vielleicht gedacht, aber nicht ausgesprochen werden: zu optimistische Zeitpläne, unklare Verantwortlichkeiten, fehlende Entscheidungswege, riskante Annahmen, Scheinabhängigkeiten, unterschätzte Change-Aufwände.
Gleiches gilt für Perspektivwechsel. Was würde der Betrieb an diesem Rollout kritisieren? Wie sähe der Projektplan aus Sicht des Datenschutzes aus? Was würde ein externer Auditor bemängeln? Welche Punkte würde ein skeptischer Fachbereich sofort angreifen? Diese Fragen kann man in Workshops stellen. Die Antworten kommen dort aber selten in der Schärfe, die ein Modell liefert. Das Modell ist nicht notwendigerweise schlauer. Es hat nur nichts zu verlieren.
Der blinde Fleck: die Tendenz zur Lehrbuchlösung
Und hier beginnt die ernüchternde Seite. Sprachmodelle neigen bei der Bewertung von Projektoptionen zu dem, was man Mean Articulation nennen könnte: Sie tendieren zur Mitte, zur Lehrbuchlösung, zur gut formulierten Standardantwort. Zu dem, was in den Trainingsdaten mit hoher Gewichtung abgelegt wurde. Bittet man ein Modell, ein Projektvorgehen zu bewerten, bevorzugt es oft saubere Governance, klare Rollen, vollständige Dokumentation, regelmäßige Kommunikation und hübsch sortierte Risiken.
Das ist nicht falsch. Es ist nur häufig nicht die eigentliche Lösung.
Gutes Projektmanagement entsteht selten durch die perfekte Anwendung eines Frameworks. Es entsteht durch Urteilskraft: Wo lohnt sich Prozessdisziplin, wo bremst sie? Welche Eskalation ist notwendig, welche nur Theater? Welches Risiko muss man sauber dokumentieren, welches muss man politisch lösen? Wo braucht es einen Workshop, wo reicht ein zehnminütiges Gespräch mit der richtigen Person?
Ein Sprachmodell antwortet immer, gern und ausführlich. Aber es antwortet auf Grundlage dessen, was bereits gedacht, beschrieben und normiert wurde. Projekte scheitern jedoch oft nicht an fehlenden PM-Methoden. Sie scheitern an Kontext, Macht, Missverständnissen, Müdigkeit, falschen Annahmen und an dem kleinen Satz: „Das hatten wir so nicht gemeint.“
Die stillen Kosten: was mit dem Denken passiert
Menschen erinnern sich schlechter an Informationen einer KI als an solche, die sie selbst erarbeitet haben. Das klingt nach einer Randnotiz. Für Projektmanagement ist es zentral.
Ein Projektmanager muss Entscheidungen vertreten können. Gegenüber dem Team, dem Auftraggeber, dem Lenkungsausschuss, dem Fachbereich, manchmal auch gegenüber sich selbst an einem Freitagabend mit zu viel Kaffee und zu wenig Fortschritt. Wer ein Risiko nicht selbst durchdrungen hat, kann es nicht sauber eskalieren. Wer einen Plan nicht wirklich verstanden hat, merkt nicht, wann er zur Fiktion wird.
Psychologische Ownership, also das Gefühl, hinter einer Entscheidung zu stehen und für sie einzustehen, entsteht durch eigenes Denken, nicht durch Delegieren an ein Modell.
Das führt zu einem Risiko, das man als Cognitive Offboarding beschreiben könnte: Man verliert nicht nur Inhalte, sondern den Prozess. Die Fähigkeit, selbst in Abhängigkeiten, Risiken und Optionen zu denken, verkümmert, wenn man sie nicht übt. Ein Projektmanager, der jede kritische Einschätzung an ein Modell auslagert, bekommt vielleicht bessere Formulierungen. Aber er verliert langsam den Muskel, aus dem gute Projektführung besteht.
Das Geschwindigkeitsproblem: wenn die Maschine schneller ist als das Projekt
Künstliche Intelligenz ist schnell. Schneller als ein Jour fixe, schneller als ein Lenkungsausschuss, schneller als Change Management, schneller als die meisten Organisationen entscheiden können. Was passiert, wenn ein System an einem Nachmittag analysiert, wofür ein PMO früher zwei Wochen brauchte?
Die naheliegende Antwort lautet: mehr Output, mehr Steuerungsfähigkeit, weniger Blindflug. Aber das stimmt nur halb. Projekte sind keine Rechenmaschinen. Sie bestehen aus Menschen, die Informationen aufnehmen, Entscheidungen verstehen, Verantwortung übernehmen und Veränderung akzeptieren müssen. Ein Migrationsplan kann in einer Stunde entstehen. Die Akzeptanz dafür braucht mindestens Monate.
KI kann Projektarbeit beschleunigen, aber sie kann die Organisation nicht beliebig beschleunigen. Wer mehr Analysen produziert, als das Projekt verarbeiten kann, erzeugt keinen Fortschritt, sondern Rauschen. Dann entstehen noch mehr Tabellen, noch mehr Optionen, noch mehr Statusvarianten. Das sieht nach Kontrolle aus und fühlt sich doch verdächtig nach unkontrollierbarer Nebelmaschine an.
Wie man es richtig machen könnte
Was folgt daraus für die Praxis? Einige Grundsätze, die einfach klingen, aber im Projektalltag regelmäßig untergehen:
- Nicht jede PM-Aufgabe eignet sich für KI
Ein Modell kann Protokolle verdichten, Risiken sortieren, offene Punkte strukturieren oder eine Entscheidungsvorlage schärfen. Es sollte aber nicht allein bestimmen, ob ein Go-live tragfähig ist, ob ein Lieferant eskaliert werden muss oder welche politische Linie gegenüber einem Fachbereich sinnvoll ist. - Copilot, nicht Autopilot
Die Metapher ist abgenutzt, aber sie trifft. Wer KI delegiert statt mit ihr arbeitet, verliert Kontrolle über Inhalte, Qualität und das eigene Urteilsvermögen. KI sollte Fragen aufwerfen, Alternativen formulieren und blinde Flecken markieren. Entscheiden muss weiterhin der Mensch. - Kontext ist wichtiger als Menge
Vierhundert Seiten Projektdokumentation in ein Modell zu laden, erzeugt keinen Mehrwert, wenn niemand vorher klärt, welche Frage beantwortet werden soll. Gute KI-Nutzung im Projektmanagement ist selbst Projektmanagement: Auftrag definieren, Erwartung formulieren, Ergebnis prüfen. - Outputs müssen verifizierbar sein
Wer eine KI-generierte Risikoanalyse nicht beurteilen kann, sollte sie nicht verwenden. Erfahrung im Projektgeschäft wird durch KI nicht ersetzt. Sie ist die Voraussetzung dafür, KI sinnvoll einzusetzen. - Zeit mit Bedacht sparen
Die durch Automatisierung gewonnene Zeit sollte nicht in noch mehr Automatisierung fließen, sondern in das, was Maschinen nicht leisten: Gespräche führen, Konflikte klären, Erwartungen managen, Entscheidungen vorbereiten, Vertrauen aufbauen. Also in die Arbeit, die im Projektplan oft unscheinbar aussieht und in Wirklichkeit den Unterschied macht.
Am Ende: das Denken zurückholen
Die größte Gefahr großer Sprachmodelle liegt nicht darin, dass sie falsche Antworten geben. Sie liegt darin, dass sie richtig klingende Antworten geben und dass wir aufhören zu prüfen, ob sie überhaupt die richtigen Fragen beantworten.
Projektmanagement ist im Kern eine menschliche Aufgabe. Es erfordert Urteilsvermögen, das aus Erfahrung wächst. Es erfordert Verantwortung, die niemand wegdelegieren kann. Und es erfordert das Aushalten von Unsicherheit, Widerspruch und Unvollständigkeit. Genau dort findet Projektführung statt.
Wer das versteht, kann Sprachmodelle für das nutzen, was sie wirklich sind: außerordentlich leistungsfähige Werkzeuge für bestimmte Aufgaben. Werkzeuge, die schneller formulieren, strukturieren und simulieren als wir. Aber sie führen kein Projekt für uns.
Das Denken zurückzuholen ist keine Ablehnung der Technologie. Es ist ihre klügste Nutzung.
Für Recherche und Lektorat kam KI zum Einsatz. Ein echtes Foto illustriert den Text.
Schreibe einen Kommentar