Kein Lehrbuch-Team. Eine echte Firma.

KI im Unternehmen — Teams, die wirklich so sind, performanter machen.

Der Ausgangspunkt ist nicht das ideale Scrum-Team aus dem Seminar, sondern die reale Organisation: ein Rollen-Mix, der mal passt und mal nicht, politisches Gerangel, Krisenmodus als Normalzustand. KI ersetzt hier keine Führung — sie macht Reibung sichtbar, bevor sie ein Projekt kostet.

Die reale Ausgangslage

Der Rollen-Mix passt oft — und oft nicht.

Genialer Kopf, Completer, Kritiker: Das ist keine zufällige Beobachtung, sondern deckt sich mit Belbins neun Teamrollen (u. a. Plant — der Ideengeber, Completer Finisher — der Abschließer, Monitor Evaluator — der nüchterne Kritiker). Belbins Kernbefund war schon in den 1980ern: Nicht die einzelnen Talente entscheiden, sondern die Zusammensetzung — ein Team aus lauter Genies scheitert oft genauso wie eines ohne einen einzigen.

Was KI hier nicht kann

Politik wegzaubern, Krisenmodus abschalten, oder Belbin-Rollen wie ein Setzkasten optimal befüllen. Organisationen sind keine Optimierungsprobleme — das wäre wieder Goldplating am falschen Ende (Regel 1).

Was KI hier kann

Reibung früh sichtbar machen: Wer wird in Meetings systematisch überhört? Wo häufen sich Blocker um dieselbe Schnittstelle? Wo fehlt im Rollen-Mix der Completer, während drei Genies um dieselbe Idee kreisen? Muster aus Kommunikationsdaten, Ticket-Historie und Meeting-Kadenz, die einem einzelnen PM sonst erst nach Monaten auffallen.

Strategisches Verhalten je Phase

Forming – Storming – Norming – Performing – Adjourning, mit KI-Unterstützung je Phase.

Der Punkt ist nicht, das Modell zu kennen — sondern sich in jeder Phase bewusst anders zu verhalten, so wie du es als PM immer gemacht hast. KI verstärkt genau diese Phasen-Sensibilität, statt sie zu ersetzen.

Phase
Dein bewährtes PM-Verhalten
KI-Unterstützung
Forming
Vorsichtig, viel Zuhören, Erwartungen klären, noch keine harten Entscheidungen erzwingen.
Skill-/Rollen-Mapping aus vorhandenen Profilen und Historie vorschlagen; offene Erwartungslücken zwischen Stakeholdern früh markieren, bevor sie zu Konflikten werden.
Storming
Konflikte bewusst nicht glätten, sondern sichtbar machen und moderieren — Reibung hier ist Signal, nicht Störung (Regel 2: Feedback-Entzug wäre schlimmer).
Muster in Kommunikationsdaten aufdecken, die auf ungelöste Konflikte hindeuten (wiederkehrende Blocker an denselben Schnittstellen, sinkende Reaktionsgeschwindigkeit zwischen bestimmten Rollen) — als Frühwarnsystem, nicht als Ersatz fürs Gespräch.
Norming
Gemeinsame Arbeitsweisen festschreiben, die aus der Storming-Phase gelernt wurden — nicht von oben verordnet.
Vereinbarte Regeln (Working Agreements) als lebendiges Dokument pflegen und bei Abweichung erinnern — konsequent, aber ohne Bloßstellung.
Performing
Zurücktreten, Delegation, Freiraum für Fluss-Zustand — Mikromanagement wäre hier der Fehler.
Workload- und Flow-Muster überwachen, um Überlastung früh zu erkennen — bevor „Performing" in Burnout kippt.
Adjourning
Bewusst abschließen, würdigen, Wissen sichern — sonst geht es mit dem Team verloren.
Projektwissen, Entscheidungsbegründungen und stille Lessons Learned strukturiert festhalten, durchsuchbar für das nächste Projekt.
Team-Building neu gedacht

Das Abendessen mit Alkohol geht heute selten — der Smalltalk davor bleibt.

Was früher informell über gemeinsames Essen und ein paar Gläser lief, ist heute aus mehreren Gründen selten geworden — nicht nur steuerlich (Bewirtungskosten sind strenger dokumentationspflichtig), auch kulturell: gemischte Teams, unterschiedliche Lebensmodelle, weniger Toleranz für Alkohol als Beziehungs-Katalysator im Berufskontext.

Die übernommene Technik: Smalltalk vor der Sache

Die aus dem amerikanischen Kontext übernommene Gewohnheit, ein Meeting nicht sofort mit der Agenda zu beginnen, sondern mit ein paar Sätzen über Persönliches — das ist kein Zeitverlust, sondern der komprimierte Ersatz für das Abendessen: eine kleine, wiederholte Dosis Beziehungsarbeit statt einer großen, seltenen. Genau diese kleinen, ehrlichen Kontaktmomente sind Regel 2 (Feedback-Takt) auf der Beziehungsebene — Blockaden lösen sich oft nicht durch das nächste Argument, sondern durch das nächste Quäntchen Vertrauen.

KI-Rolle: Nicht den Smalltalk ersetzen, sondern ihn vorbereiten helfen — z. B. relevante, nicht-private Gemeinsamkeiten oder aktuelle Kontextpunkte vor einem wichtigen Meeting zusammenfassen, damit der erste Satz trifft statt zu floskeln.

Arbeitszeitmodelle

Die 4-Tage-Woche (Mo–Do) bei vergleichbarem Gehalt — was die Studienlage sagt.

Der größte kontrollierte Feldversuch bisher: 61 Unternehmen, rund 2.900 Beschäftigte, UK, koordiniert von Autonomy/4 Day Week Global (2022) — Vollzeitgehalt bei 80% der Arbeitszeit, Bedingung: Output zählt, nicht Anwesenheit.

92%
der Unternehmen führten die 4-Tage-Woche nach dem Test fort
71%
der Beschäftigten berichteten weniger Burnout
39%
geringeres Stresslevel
54%
leichtere Vereinbarkeit von Job und Haushalt

Quelle: UK-Pilotprojekt 2022 (Autonomy/4 Day Week Global), zusammengefasst u. a. bei Multiplier und World Economic Forum. Konkrete Umsatz-/Produktivitätszahlen variieren je Unternehmen; der durchgängige Befund ist „mindestens gleich produktiv bei output-fokussierter statt zeitfokussierter Arbeitsweise" — nicht ein pauschaler Produktivitätsschub.

Die Verbindung zur These „gute, zufriedene Teams sind besser": Die 4-Tage-Woche wirkt nicht durch Magie, sondern weil sie erzwingt, was output-fokussiertes Arbeiten ohnehin verlangt — Meetings straffen, Prioritäten schärfen, echte Ergebnisse statt Anwesenheit messen. Das ist dieselbe Disziplin wie Regel 3 (Miss das Ziel, nicht den Stellvertreter), nur auf Arbeitszeit angewendet.
Motivation, ehrlich betrachtet

Angst motiviert kurzfristig — und untergräbt genau das, was Teams leistungsfähig macht.

Googles „Project Aristotle" untersuchte über Jahre, was Hunderte interne Teams tatsächlich effektiv macht — mit einem Ergebnis, das viele überraschte: Nicht die Zusammensetzung der Talente entschied, sondern wie das Team miteinander arbeitete.

Die fünf Faktoren effektiver Teams (nach Wichtigkeit)

1. Psychologische Sicherheit — Risiken ansprechen können, ohne Bloßstellung zu fürchten. 2. Verlässlichkeit — Zusagen werden eingehalten. 3. Struktur & Klarheit — klare Rollen, Prozesse, Ziele. 4. Bedeutung — Sinn in der eigenen Arbeit. 5. Wirkung — der eigene Beitrag zählt sichtbar.

Psychologische Sicherheit lag mit Abstand vorn. Angst ist strukturell ihr Gegenteil: Wer Fehler oder abweichende Meinungen fürchtet zu äußern, liefert genau das, was Regel 5 (Wahrheit vor Gefälligkeit) verhindern soll — beruhigende statt ehrliche Signale. Angst „funktioniert" kurzfristig als Gehorsam, zerstört aber genau den Kanal, über den ein Team eigene Fehler früh erkennt. Dieselbe Dynamik gibt es maschinell: Sykophanz-Schleifen in KI-Systemen entstehen aus genau demselben Mangel an psychologischer Sicherheit — nur bei den menschlichen Bewertern statt im Team.

Quelle: Google re:Work, „Understand team effectiveness" (Project Aristotle).

Exkurs — mit akademischem Rückgrat

Fehlerkultur und „Negatives Wissen" — die Regensburger Forschung dazu.

Ein persönlicher Bezug, kein Namedropping: Prof. em. Dr. Dr. h. c. Hans Gruber (heute Universität Regensburg, Fakultät für Humanwissenschaften) und ich kennen uns aus einer ganz anderen Welt — beide Spieler im Zitherorchester ZOMP, er zusätzlich als Dirigent — das Orchester mehrfach Erster Preisträger beim Deutschen Orchesterwettbewerb, einmal sogar auf USA-Tournee. Studiert haben wir nicht gemeinsam: Ich war an der TU München mitten im Modul B3 Kybernetik (Elektrotechnik und Informationstechnik), er stand damals schon mitten in seiner akademischen Laufbahn an der LMU München und beschäftigte sich gerade mit Schachstrategien. Was blieb, waren Gespräche auf Augenhöhe, ohne Vorurteile zwischen Fachgebieten, die auf den ersten Blick nichts miteinander zu tun hatten — Bögen spannen, Erkenntnisse übertragen, angewandtes GEB, lange bevor ich wusste, dass es dafür einen Namen gibt. Seine spätere Forschungsgruppe hat genau das empirisch untersucht, was Googles Project Aristotle Jahre später von der anderen Seite bestätigte: wie Teams mit Fehlern umgehen, entscheidet über ihre Lernfähigkeit — nicht, ob sie welche machen.

„Negatives Wissen" — was Experten von Anfängern wirklich unterscheidet

Gartmeier, Bauer, Gruber & Heid prägen in „Negative Knowledge: Understanding Professional Learning and Expertise" (Vocations and Learning, 1(2), 87–103, 2008) den Begriff des negativen Wissens: erfahrungsbasiertes Wissen darüber, was in einer Arbeitssituation nicht funktioniert und zu vermeiden ist. Ihre Kernthese: Experten unterscheiden sich von Anfängern nicht nur durch mehr Wissen, sondern durch ein explizites Wissen darüber, welche Ansätze suboptimal sind — Sicherheit, Effizienz und Reflexion entstehen gerade aus dieser negativen Seite der Erfahrung, nicht nur aus der positiven.

Gartmeiers Regensburger Dissertation (2009, Erstgutachter Hans Gruber) unterlegt das empirisch: In einer Bankenstudie mit 84 Beschäftigten sagten Fehlerkompetenz, Lernen aus Fehlern und Reflexion über Fehler die Eigeninitiative signifikant voraus — vermittelt über psychologische Sicherheit. Zwei völlig unabhängige Forschungslinien, deutsche Erziehungswissenschaft und Googles interne Teamforschung, landen beim selben Mechanismus.

Übersetzung in ein KI-Produkt: „Lessons Learned"-Dokumente verstauben, weil sie am Projektende geschrieben und nie wieder gelesen werden — genau das negative Wissen, das laut Gruber/Gartmeier die eigentliche Experten-Ressource ist, geht damit verloren, statt strukturell verfügbar zu bleiben. Eine KI-gestützte „Negatives-Wissen-Basis" würde nicht nur sammeln, was schiefging, sondern es im richtigen Moment wieder einspielen — z. B. beim Anlegen eines neuen Projekts mit ähnlicher Governance-Struktur automatisch auf vergleichbare frühere Fehlerquellen hinweisen (Matrix-Doppelpfade, CR-Fluten — siehe Fallbeispiel unten). Das macht aus Regel 4 (Invertiere vor dem Start) keine einmalige Übung, sondern eine wachsende, durchsuchbare Wissensbasis.
Aus eigener Erfahrung — kein Einzelfall, sondern Systemversagen: Bei jedem Lessons-Learned-Termin habe ich die unbequeme Anschlussfrage gestellt: Wo liegt das eigentlich — durchsuchbar, referenzierbar, für das nächste Projekt auffindbar? Eine akzeptable Antwort habe ich nie bekommen. Am Ende musste auf Excel in SharePoint ausgewichen werden, allein damit Tools wie Splunk oder sonstige Auswertungen aus dem Datalake überhaupt darauf zugreifen konnten — nicht, weil das die geplante Lösung gewesen wäre, sondern weil sonst gar kein Werkzeug an die Inhalte herangekommen wäre. Die PowerPoints selbst: einmal gelesen, nie wieder geöffnet. Rausgeschmissene Zeit, rausgeschmissenes Geld — und genau die Lücke, die eine „Negatives-Wissen-Basis" schließen soll, keine hypothetische.

Quelle: Gartmeier, Bauer, Gruber & Heid, „Negative Knowledge: Understanding Professional Learning and Expertise", Vocations and Learning 1(2), 87–103 (2008) · Prof. em. Dr. Dr. h. c. Hans Gruber, Universität Regensburg

Naming als PM-Werkzeug — zwei Beispiele aus erster Hand

Der Name ZOMP (Zitherorchester München-Pasing e.V.) stammt selbst aus dieser Feder — ein Vereinsname, der Wiedererkennung und Stolz trägt (mehrfach Erster Preis beim Deutschen Orchesterwettbewerb, USA-Tournee), obwohl er inhaltlich nur beschreibt, was er ist.

Bei Siemens gab es das Gegenstück im Geschäftskontext: ADMOSS LAN war schlicht eine Standard-Wurfverkabelung mit Hub für das Auskunfts-/Vermittlungssystem ADMOSS an der EWSD — technisch nichts, was es nicht auch bei jedem Elektronikhändler um die Ecke gegeben hätte. Weil sie fest an ADMOSS/EWSD gekoppelt war und einen eigenen Produktnamen trug, wollten sogar Siemens-Einheiten aus Singapur sie exklusiv beziehen. Der Name allein hatte aus einer Commodity ein scheinbares Alleinstellungsmerkmal gemacht.

Die Lehre für PM und Produkt: Ein guter Name beschreibt nicht nur, er schafft einen Fixpunkt, an dem sich Wahrnehmung von Wert festmacht — unabhängig vom technischen Gehalt darunter. Das gilt für ein Orchester genauso wie für ein Kabelsystem wie für ein KI-Produkt.

Ein wiederkehrendes, unbeachtetes Zeitloch

Veraltete Org-Pläne — die stille Zeitverschwendung am Projektanfang.

In fast allen Projekten dasselbe Bild: Der offizielle Org-Plan ist nicht aktuell, und der eigentliche Aufwand, die richtigen Stakeholder überhaupt erst zu identifizieren, zieht sich regelmäßig über die ersten zwei Monate — bevor das eigentliche Projekt inhaltlich beginnt.

Warum das niemand als Problem verbucht

Diese zwei Monate verschwinden meist unsichtbar in „Projekt-Ramp-up" — sie werden nirgends als eigene Kennzahl geführt, obwohl sie sich Projekt für Projekt identisch wiederholen. Bei mehreren Projekten pro Jahr summiert sich das zu einem erheblichen, aber nie budgetierten Zeitblock — genau das extreme Optimierungspotenzial, das im Tagesgeschäft untergeht, weil es nie als Ganzes sichtbar wird.

Der KI-Ansatz: gelebte statt dokumentierte Organisation

Statt sich auf den veralteten Org-Plan zu verlassen, aus tatsächlich gelebten Spuren rekonstruieren, wer wirklich entscheidet: Kommunikationsmuster (wer wird in welchen Threads tatsächlich einbezogen), Freigabe-Historien, Ticket-Zuweisungen. Das Ergebnis ist eine belastbare Stakeholder-Landkarte in Tagen statt Monaten — und die notwendige Vorstufe für den PIS-Vektor (Power/Interest/State) aus dem Rollout-Plan: Man kann niemanden sauber nach Macht und Interesse einordnen, den man vorher nicht einmal korrekt identifiziert hat.

Fallbeispiel aus der Praxis

Ein Telko-Merger, die Matrix-Organisation und zwei Approval-Pfade.

Anonymisiert: Unternehmen, Endkunde, Softwarezulieferer und Ort sind aus Vertraulichkeitsgründen nicht genannt. Die strukturelle Lektion bleibt unverändert.

Was passiert war

Ausgangslage: Nach einer Fusion zweier Telekommunikationsausrüster übernahm das neue, gemeinsame Unternehmen die Matrix-Struktur eines der beiden Fusionspartner — mit der Folge, dass es für bestimmte Entscheidungen zwei parallele Genehmigungspfade gab. Das war nicht offensichtlich dokumentiert; verstanden wurde es erst im Zuge der PMP-Prüfungsvorbereitung, als die Matrix-Organisationstheorie den blinden Fleck sichtbar machte.
Die Ausgangslage im Projekt davor: Ohne dieses Wissen kamen frühere Projektbeteiligte regelmäßig mit einem „Blumenstrauß" an Change Requests aus Kunden-Terminen zurück — ungebündelt, unkoordiniert zwischen dem institutionellen Endkunden und dem beauftragten Softwarezulieferer. Ergebnis: rund 1,5 bis 2 Jahre Projektverzug.
Der gezielte Schritt: Statt den offiziellen Weg über den Sponsor abzuwarten, wurden er und der eigene Software-Architekt (ein Freelancer, den er selbst freigegeben hatte) kurzerhand selbst zum Vor-Ort-Termin zwischen Endkunde und Softwarezulieferer eingeladen — genehmigt nicht über den Sponsor, sondern bewusst über den zweiten, vom Line-Manager getragenen Approval-Pfad der Matrix-Organisation. Ein direkter Verstoß gegen den erwarteten Dienstweg, aber genau der Pfad, den die Matrix-Struktur eben zusätzlich hergab.
Die Reibung: Der Sponsor war davon zunächst alles andere als begeistert — übergangen zu werden, auch wenn es strukturell korrekt war, kam nicht gut an. Er sprach fortan abfällig vom „Ausflug nach Las Vegas", als wäre es ein Vergnügungstrip gewesen statt der gezielte Schritt, der er tatsächlich war.
Ergebnis: Der direkt gemanagte, gebündelte CR-Prozess verhinderte genau die Verzögerung, die frühere Projektbeteiligte ohne dieses Wissen erlitten hatten. Der Erfolg sprach für sich — so eindeutig, dass derselbe Sponsor den „Ausflug" im Nachhinein selbst als Wendepunkt des Projekts bezeichnete, bekräftigt durch ein Certificate of Appreciation.
Was das für ein KI-Produkt bedeutet: Dieses Wissen kam durch Zufall (PMP-Lernstoff, zur richtigen Zeit gelesen) — nicht durch System. Genau das ist eine Lücke, die KI systematisch schließen kann: Organigramme, Verträge und Governance-Dokumente eines Projekts einlesen und explizit auf Doppel-Pfade, widersprüchliche Genehmigungsketten oder unklare Eskalationswege prüfen, bevor das erste CR-Chaos entsteht — nicht als Ersatz für die eigene Erfahrung, sondern als Frühwarnung für den nächsten PM, der die PMP-Prüfung noch nicht hinter sich hat.