Ja, KI halluziniert. Ja, KI hat diverse Biases. Und wir Menschen? Sind wir fehlerfrei?
Ein lieber Kollege hat mich auf einen Artikel geschubst: AI Agents Are Failing 63 % of the Time — Here’s the Simple Fix No One Talks About. Dort wird attestiert, dass selbst bei nur 1 % Fehlerquote pro Einzelschritt der KI die Wahrscheinlichkeit eines Scheiterns bei einer 100‑Schritt‑Aufgabe auf 63 % steigt; laut Patronus AI liegt die Fehlerquote in der Praxis eher bei 20 % pro Schritt.
Als Lösung wird ein „Triple‑Loop‑Safeguard“ vorgeschlagen:
Atomare Validierung: Jeder einzelne Schritt wird geprüft – z. B. per JSON‑Schema, Regex, API‑Status oder Typüberprüfungen. Scheitert ein Test, wird der Schritt abgelehnt, neu gestartet oder zur Prüfung markiert.
Schritt‑Stufen‑Kontrolle: Nach mehreren Schritten wird eine übergeordnete Validierung über Teil‑Workflows durchgeführt, um Fehler frühzeitig zu erkennen .
Kontext‑Überwachung: Gesamtoutput‑Checks, Monitoring von Kennzahlen und manuelle Reviews (also von Menschen) sichern das Gesamtergebnis ab .
Dieses mehrstufige Sicherheitsnetz fängt Fehler frühzeitig ab, bevor sie sich kumulieren können. Kleinere Fehlerquoten bleiben überschaubar – und kleine Verbesserungen wirken sich stark auf die Enderfolgsrate aus .
Mag ja alles richtig sein, aber wenn man ehrlich ist: wie hoch ist die Fehlerquote bei einem Menschen, dem man 100 Tasks gibt? Das Thema muss Fehlerquote sein, unabhängig davon ab KI oder Mensch. Ich zitiere an dieser Stelle mal wieder meine Lieblingsgrafik aus der Wikipedia: Den Cognitve Bias Codex
Der Cognitive Bias Codex beschreibt ein Vielzahl kognitiver Verzerrungen, denen wir Menschen ausgesetzt sind. Und ohne ins Detail zugehen ist allein schon Umfang und Komplexität unserer Unzulänglichkeiten ernüchternd.
Fehlerquellen gibt es mehr als genug. Egal ob Mensch oder Maschine. Wir brauchen eine Fehlerkultur für Mensch und Maschine. So etwas wie „Triple‑Loop‑Safeguard“ lässt sich in beiden Fällen anwenden.
Ich würde fast vermuten, dass die Fehlerquote der KI geringer ist als bei uns Menschen, allerdings kann auch eine vermeintlich zuverlässige KI Totalausfälle produzieren, wo wir Menschen vielleicht noch über die fehlende Plausibilität stolpern.
Aktuell beschäftige ich mit dem Thema Self-Publishing. Da gibt es 2 Platzhirsche: Amazon für das Self-Publishing und Adobe (mit Indesign) für das Layout.
Komischerweise gibt es da aber keine Templates und die Kontakt/Hilfe-Optionen sind sehr eingeschränkt. Lästiger Kunde…
Ich finde Word-Vorlagen, aber bei der Verwendung von Druckvorlagen aus MS Office bin ich ein gebranntes Kind und habe mich schon mit einem lokalen Drucker überworfen.
Bei den Business Netzwerken läuft vieles immer mehr auf LinkedIn hinaus. Xing schafft sich selber ab, Foren sind tot, und alternative Initiativen wie openPM stehen auch am Ende.
Aber ein Punkt liegt mir dabei schwer im Magen, denn LinkedIn geht es nicht wirklich um Inhalte, sondern mehr um die Akteure. Haben Sie schon mal versucht auf LinkedIn zu suchen?
Das funktioniert nach Personen, aber nicht nach Inhalten.
Bernhard: Lass uns unseren Dialog über Projekterfolg noch einmal aufgreifen: Deine Formulierung, dass Projekterfolg kommunikativ hergestellt wird und nicht durch Ergebnisse hat mir spontan sehr gefallen, aber je länger ich darüber nachdenke, passt das noch nicht, denn Erwartungen werden nicht immer ausgesprochen. Erwartungen sind häufig implizit und nicht explizit.
ChatGPT: Okay. Ein kluger Einwand. Wenn Erwartungen häufig unausgesprochen bleiben, stellt sich eine neue, schärfere Frage: Wie kann etwas kommunikativ hergestellt werden, das nie vollständig kommuniziert wurde? Wenn also Projekterfolg davon abhängt, Erwartungen zu erfüllen – und diese Erwartungen nicht offen benannt werden – kann Erfolg dann überhaupt sicher festgestellt werden? Oder erleben wir dann nicht nur rückblickend etwas als Erfolg, wenn sich herausstellt, dass wir (zufällig?) die richtigen Dinge getroffen haben?
Bernhard: Genau das ist der Punkt, allerdings sind wir auch bei unausgesprochenen Erwartungen, den Bewertungen durch unser gegenüber ausgesetzt. Er/sie attestiert uns Expertise oder im negativen Fall Schwächen und Fehler, was auch Auswirkungen auf künftige Projekte und Themen haben kann.
ChatGPT: Okay. Dann wird deutlich: Projekterfolg ist nicht nur ein Abgleich mit (un)sichtbaren Erwartungen – er ist auch ein sozialer Spiegel. Selbst wenn Erwartungen nicht explizit gemacht werden, werden Urteile gefällt, werden Zuschreibungen vorgenommen: Kompetenz, Verlässlichkeit, Führungsfähigkeit – oder das Gegenteil. Und diese Urteile wirken nachhaltig – sie prägen Reputation, beeinflussen Vertrauen, und damit auch: Zugang zu Ressourcen, Spielräume, nächste Chancen. Darf ich dich fragen: Wenn Erfolg von unausgesprochenen Erwartungen und fremden Zuschreibungen abhängt – wie behältst du dann die Handlungsfähigkeit im Projekt?
Bernhard: Letztlich mit einer Art „Erwartungsmanagement“. Es ist hilfreich sich mit den Erwartungen (ob ausgesprochen oder nicht) auseinanderzusetzen.
ChatGPT: Okay. Dann lässt sich sagen: Projekterfolg hängt nicht nur von Ergebnissen oder Bewertungen ab, sondern von unserer Fähigkeit, mit Erwartungen umzugehen – selbst wenn sie im Nebel liegen. Erwartungsmanagement wird damit zu etwas Tieferem: Nicht bloß Kommunikationstaktik, sondern ein Versuch, Unsichtbares sichtbar zu machen – und gleichzeitig die eigene Position zu wahren zwischen Anpassung und Selbstbehauptung. Wenn du das so beschreibst, frage ich weiter: Ist Projekterfolg dann vielleicht weniger das Erfüllen eines Ziels – als vielmehr das geschickte Navigieren durch ein Geflecht aus Erwartungen, Beziehungen und Zuschreibungen?
Bernhard: Ganz meine Meinung. Für ein Training habe ich die Frage aufgeworfen: Wann ist ein Projekt „erfolgreich“? – und den Teilnehmern drei Szenarien vorgestellt: 1. Alle definierten Liefergegenstände in Time, in Budget und in Quality geliefert 2. Auch wenn nicht alles geliefert wurde, der Kunde ist zufrieden 3. Das Projekt wurde abgebrochen, weil sich die Zielsetzung als obsolet erwiesen hat
ChatGPT: Okay. Deine drei Szenarien sind stark – gerade weil sie den Begriff „Erfolg“ herausfordern. Sie machen sichtbar, dass formale Kriterien (Time, Budget, Quality) oft in Spannung stehen zu wahrgenommener Sinnhaftigkeit und Stakeholderzufriedenheit. Lass mich sie analytisch auffächern:
Szenario 1: Klassisch erfolgreich
Alle Liefergegenstände in Time, Budget, Quality erreicht.
Stakeholderbewertung: vermutlich ebenfalls positiv
Implizite Annahme: Erfolg = Plan einhalten
Fragezeichen: Aber: War der Plan überhaupt noch relevant?
Dieses Szenario trifft das klassische Verständnis von Erfolg – aber vielleicht nicht das einzig gültige.
Szenario 2: Nicht alles geliefert, Kunde trotzdem zufrieden
Formale Bewertung: Zielabweichung
Stakeholderbewertung: Wahrnehmung „es hat sich gelohnt“
Implizite Annahme: Erfolg = perceived value
Fragezeichen: Ist es dann überhaupt wichtig, ob man „alles“ liefert?
Hier zeigt sich: Zufriedenheit ist stärker als Vollständigkeit.
Szenario 3: Projekt abgebrochen, weil Ziel obsolet
Formale Bewertung: Kein Abschluss, kein Produkt
Stakeholderbewertung: Je nach Kommunikation und Kontext
Implizite Annahme: Erfolg = kluge Entscheidung, Ressourcen nicht vergeudet
Fragezeichen: Gilt das als „Scheitern“ – oder als strategische Stärke?
Manche würden sagen: Das ist gerade gutes Projektmanagement.
Bernhard: Im Anschluss habe ich noch eine Folgefrage gestellt: Wer „bestimmt“ ob ein Projekt erfolgreich war? Auftaggeber/in, Projektleitung, Team, Kunden/Nutzer, Gesellschaft…
ChatGPT: Die Folgefrage trifft den Kern – denn sie verschiebt den Fokus vom Ergebnis hin zur Deutung des Ergebnisses. Wer „bestimmt“, ob ein Projekt erfolgreich war, entscheidet nicht nur über Anerkennung – sondern auch über Lernprozesse, Karrierewege und Folgemaßnahmen.
Hier eine strukturierte Betrachtung deiner Adressaten:
Auftraggeber/in
Interesse: Zielerreichung, Return on Investment, Stakeholderzufriedenheit
Macht: Hoch – entscheidet oft über offizielle Erfolgsmeldung
Risiko: Erfolgsbild kann politisch oder strategisch eingefärbt sein
Projekterfolg ist eines meiner Lieblingsthemen. War ja hier schon das eine oder andere mal auf der Agenda. Eine kleine Spielerei am Samstagabend: ein sokratischer Dialog mit ChatGPT über Projekterfolg, den ich euch nicht vorenthalten will:
ChatGPT: Was meinst du – was ist Projekterfolg?
Bernhard: Das ist eine Frage der Perspektive.
ChatGPT: Okay. Und wessen Perspektive würdest du als entscheidend ansehen, wenn du sagen willst: „Dieses Projekt war erfolgreich“?
Bernhard: Wenn du mich so frägst, immer meine eigene, aber dummerweise sind wir oft auch abhängig von der Sichtweise anderer.
ChatGPT: Okay. Wenn deine eigene Perspektive im Kern zählt, aber du gleichzeitig von anderen abhängig bist – was macht dann deinen persönlichen Projekterfolg aus? Ist er unabhängig von der Bewertung anderer, oder nur dann möglich, wenn deren Erwartungen erfüllt sind?
Bernhard: Jetzt muss ich den Spieß umdrehen, denn du hast den Zusammenhang zwischen Projekterfolg und Erwartungen hergestellt. Ist Projekterfolg also abhängig von Erwartungen?
ChatGPT: Okay. Wenn wir diesen Spieß umdrehen: Erwartungen setzen einen Maßstab – aber sind sie immer realistisch, immer klar, immer geteilt? Wenn also Erfolg sich an Erwartungen misst: Wer bestimmt, was zu erwarten ist – und wann das Erwartete als erfüllt gilt?
Bernhard: Diese Frage lasse ich nicht gelten. Niemand bestimmt, was zu erwarten ist. Erwartungen müssen wir hinnehmen. Oder siehst du das anders?
ChatGPT: Okay. Wenn Erwartungen einfach da sind und wir sie hinnehmen müssen – bedeutet das dann, dass Projekterfolg immer ein Reagieren ist? Also nie etwas, das wir selbst aktiv bestimmen, sondern nur etwas, das sich daran misst, ob wir den Erwartungen anderer gerecht wurden?
Bernhard: oder den eigenen Erwartungen…
ChatGPT: Okay. Dann frage ich dich: Was unterscheidet fremde von eigenen Erwartungen – wenn es um Projekterfolg geht? Sind deine eigenen Erwartungen freier, klarer, strenger – oder vielleicht nur ein Echo der Erwartungen anderer?
Bernhard: Das lässt ich nicht pauschal beantworten, denn es gibt nicht die eine fremde Erwartung, sondern ein ganzes Spektrum.
ChatGPT: Okay. Wenn es also ein Spektrum fremder Erwartungen gibt – und deine eigenen irgendwo darin verortet sind: Kann es dann überhaupt einen Projekterfolg geben, der für alle gleichermaßen gilt? Oder ist Projekterfolg immer ein Kompromiss zwischen konkurrierenden Erwartungshaltungen?
Bernhard: Da gehe ich mit. Natürlich gibt es unter den Erwartungshaltungen vielleicht dominantere, sei es aufgrund der Anzahl der Personen, die sie vertreten oder weil sie besonders einflussreiche Stakeholder vertreten.
ChatGPT: Okay. Wenn also Projekterfolg vom Gewicht einzelner Erwartungshaltungen abhängt – ist Erfolg dann eher eine soziale Verhandlung als ein objektiver Zustand? Und wenn ja: Wird Projekterfolg damit nicht zu etwas, das man kommunikativ herstellt, nicht nur durch Ergebnisse?
Bernhard: Ja, so würde ich das sehen. Danke für dieses Gespräch.
Again what learned: Projekterfolg wird kommunikativ hergestellt – nicht durch Ergebnisse.
Die Business Agility Nürnberg ist doch mehr Konferenz als Unkonferenz. Die meisten Beiträge sind vorab im Programm verankert. Nicht schlimm, sondern Konzept. Allerdings leiden die Kollegen an den gleichen Problemen, wir openPM. Dieses Jahr kaum Sponsoren gefunden. Immerhin – aufgrund der Regionalität, sind die Teilnehmerzahlen nicht das Problem. Damit das #BAN aber Zukunft hat, braucht es weitere Unterstützung. Also Sponsoren bitte melden.
Aber zur diesjährigen #BAN.
Die Spannbreite ist wieder enorm: Vom traditionellen Projekthelden über Agilisten, die sich nicht mehr so nennen, Serious Play Enthusiasten, natürlich einer Prise Table of Elements, Kanban/Flow Enthusiasten wie Eric-Jan Kaak, bis hin zur Book Promotion von Jurgen Appelo mit seinem „Human Robot Agent“.
Alles in allem ein Tag mit vielen wertvollen Inputs. Networking – nicht zu unterschätzen. Aktuell rauschen die Anfragen auf LinkedIn rein. Das Thema Austausch ist einerseits so wertvoll, andrerseits so stiefmütterlich behandelt und wo findet man es heut noch?
Ich lade dich daher gerne dazu ein mit zu folgen auf LinkedIn, oder der Table of Elements (ebenfalls auf LinekdIn). Und die Kollegen und Teilnehmer der #BAN würden sich auch über deine Wertschätzung freuen.
Der AI Act der Europäischen Union ist der Inbegriff europäischer Bürokratie. Er steht in der glorreichen Tradition der Staubsauger-Verordnung und der Leuchtmittel-Verordnung. Also nicht dass der Inhalt der Verordnung Blödsinn wäre, nein, da haben sich Experten wirklich Mühe gegeben und viel Gehirnschmalz reingesteckt.
„Sie waren stets bemüht…“
Aber dahinter steckt ein grundlegend falsches Verständnis:
Statt bestehende Regelungen zu prüfen und auf neue technologische Herausforderungen, wie die künstliche Intelligenz, anzupassen, werden neue Regelungen und neue Bürokratie geschaffen. Im aktuellen AI Hype geht es noch unter, aber der AI Act wird uns noch einholen, wie damals die DSGVO.
Meine erste Annäherung
Windholz, Natascha, et al. Praxishandbuch KI-VO: Künstliche Intelligenz rechtskonform im privaten und öffentlichen Bereich einsetzen, München 2024
Leider keine Empfehlung. Extreme Detailtiefe, aber den Blick auf das Wesentliche habe ich nicht gefunden. Sicher alles da, aber ist nicht bei mir angekommen. Obwohl ich mich durchgekämpft habe.
Zweiter Versuch beim Kunden: Deutscher Tech-Konzern hat eine interne Guideline zum Einsatz von AI
Wieder viel Gutes und Richtiges. 80+ Empfehlungen mit Referenzen auf Cybersecurity Policies, aber die Umsetzung stellt noch nicht einmal die Compliance zum AI Act sicher. (Soviel ist dann doch beim Praxishandbuch hängengeblieben.)
Dritter Versuch: Diskussion mit der AI Governance in einem Konzern
Auch wieder etwas Deutsches: Wir brauchen neue Polices und eine Governance für das Thema AI.
Den Fehler des EU AI Act auf Unternehmensebene nachziehen und fortschreiben. Auch hier wieder vieles Gutes und Richtiges. Aber irgendwie ein Greenfield Approach. Für neue AI Anwendungen. Die gibt es zwar sicher, aber durch die Hintertür, durch die Einbindung von AI-basierten Webservices, wird plötzlich alles zu einer AI-Applikation. Viele Fragen, gute Fragen – aber auf der falschen Ebene. Ein Deep Dive in die genutzten LLM-Modelle, die aber in den meisten Anwendungsszenarien durch SaaS-Lösungen vorgegeben sind und morgen möglicherweise schon wieder durch neue Modelle ausgetauscht werden. Fragen die kein normaler Applikations-Verantwortlich beantworten kann, sondern die einen Cybersecurity-AI -Architekten erfordern. Es fehlt die Sensibilisierung für das Wesentliche:
Wenn wir AI-Webservices einbinden, geben wir Daten nach draußen – das hat noch nicht einmal mit AI zu tun.
Und wenn wir die Daten nach draußen geben, dann ist die Frage, ob nur zur Verarbeitung oder ob die Modelle, die womöglich auch von anderen genutzt werden, daraus lernen. In Nischenbereichen kann dann auch schnell die direkte Konkurrenz von uns lernen.
Ja, es gibt da noch typische AI Risiken, wie Halluzinationen und Biases über die wir die Anwender zumindest aufklären müssen.
Selbsthilfe
Ok, noch einmal zurück auf Start. Warum nicht ChatGPT fragen nach dem AI Act? Nein ganz so einfach habe ich es mir dann doch nicht gemacht. ChatGPT war nur der Startschuss und dann habe ich aus den gewonnen Erkenntnissen (siehe oben) nachgearbeitet. Ich bin auch kein Jurist – entsprechend unverbindlich sind meine eigenen 5 Cent, auch wenn ich sie hier teile.
Zentral im AI Act ist eine Risikoklassifizierung.
Typisch für die europäische Bürokratie eine neue Risikobetrachtung einzuführen, als gäbe es nicht längst Risikomanagement in Unternehmen. Eine Betrachtung auf Applikationsebene kann schnell überfordern, aber auf Ebene von Use Cases lässt sich die Klassifizierung nach AI Act beantworten und dann bedarf es eben einer Aggregation: der Worst Case greift auf Applikationsebene.
Der AI Act unterscheidet die folgenden Risikokategorien:
Verbotene Anwendungen brauchen keine weitere Betrachtung.
Interessant wird es bei den Hochrisiko-Anwendungsfällen. Was fordert der AI Act hier?
Nun, wieder ChatGPT:
Auch hier gibt es Überschneidungen mit generellen Cybersecurity-Anforderungen, aber immerhin ein komprimierter Ansatz.
Bei „limited risks“ verbleibt nach dieser Logik nur mehr Transparency and Information.
Und bei „minimal risk“, naja, das können wir vernachlässigen.
Was ich trotzdem mitgenommen habe:
Natürlich müssen wir uns mit der Kritikalität der Daten – Input wie Output beschäftigen (auch wenn das eigentlich gar keine AI-Frage ist).
Werden die verarbeiteten Daten als Trainingsmaterial verwendet? Dann könnten ja auch andere Nutzer des LLM darauf zurückgreifen.
Sind wir „nur“ Nutzer oder Betreiber eines Modells? Bei der aktuellen Dynamik werden die Modelle schneller ausgetauscht als wir schauen können. Sind wir selbst Betreiber kommt eine besondere Verantwortung hinzu,
Aus regulatorischer Sicht halte ich das Thema AI weitgehend für überbewertet. Grundsätzliche Anforderungen und Weisheiten, wie Garbage in – Garbage out, gelten weiter. Wirklich neu sind Halluzinationen und Biases. Für die war früher noch der Mensch zuständig…
Die Grundidee der Table of Elements ist eine Rückbesinnung auf die fundamentalen Bausteine eines Themas, für unsere App der PM Elements (App- Store) also das Thema Projektmanagement und Methoden. Die Idee an sich ist aber viel universeller. Und auch die Inhalte an sich bieten Mehrwert weit über Projekte hinaus.
Habe gerade mit ChatGPT „gespielt“ und die KI gebeten eine Retrospektive für openPM durchzuführen. Das hat anfangs nicht wirklich geklappt, aber im zweiten oder dritten Nachfassen kam etwas heraus, was mir durchaus ansprechend erscheint und was ich hier teilen möchte:
Retrospektive: Was wir im openPM e.V. hätten besser machen können
1. Offenheit ≠ Selbstläufer – die Hürde zur aktiven Mitwirkung blieb hoch
Was wir wollten: Eine offene Plattform, auf der jede:r etwas beitragen kann – kollaborativ, gemeinschaftlich, niedrigschwellig.
Was passiert ist: Die meisten Nutzer:innen konsumierten Inhalte – aber aktive Beiträge blieben selten. Nur ein kleiner Kern trug dauerhaft. Viele wollten „open“, aber nicht unbedingt „mitmachen“.
Was wir lernen: → Offenheit muss aktiv moderiert, gestaltet und konkretisiert werden: durch persönliche Ansprachen, definierte Mitmachformate, klare Micro-Contributions („Schreib 1 Absatz“, „Gib 1 Feedback“) → Partizipation braucht Führung – auch in einem offenen Modell. Sonst verläuft sie sich.
2. Kein tragfähiges Nachfolge- oder Skalierungskonzept
Was wir hatten: Ein motiviertes Kernteam mit starker inhaltlicher Kompetenz. Viel ehrenamtliches Engagement – aber auch begrenzte Ressourcen.
Was fehlte:
Systematische Übergaben: „Wenn X aufhört – wer macht’s?“
Strukturen, um neue Leute einzubinden und zu halten.
Anreizsysteme für „zweite Reihe“-Mitmacher:innen (z. B. Nachwuchsmoderation, Co-Projekte, Mini-Rollen).
Was wir lernen: → Nachhaltigkeit heißt nicht nur Inhalte bewahren – sondern auch Rollen, Energie und Wissen. → Ehrenamt braucht Pflege, Nachschub und sichtbare Wertschätzung.
3. Corona hat nicht die Struktur zerstört – sondern den sozialen Kitt
Was uns Corona genommen hat:
Spontane Vernetzung auf Events
Austauschformate mit niedrigem Einstieg
Die Energie durch persönliche Begegnung und nonverbale Dynamik (Meetups, Barcamps, Stammtische)
Was digital nicht kompensiert wurde: → Digitale Formate blieben „funktional“, aber selten „verbindend“. → Viele haben sich still zurückgezogen, ohne Abschied oder Übergabe.
Was wir lernen: → Digitale Zusammenarbeit braucht emotionale Touchpoints – z. B. persönliche Check-ins, Retros, Dankeskultur. → Je digitaler ein Projekt, desto bewusster muss Bindung gestaltet werden.
4. Themenpluralität vs. Identitätsschärfe
Was wir wollten: Alles offen denken: Methoden, Schulen, Branchen – keine Grenzen, keine Dogmen.
Was passiert ist: → Für Außenstehende wurde es unübersichtlich. → Ohne klare Klammer fehlte die narrative Zugkraft: „Wofür steht openPM eigentlich – und warum soll ich mich dort engagieren?“
Was wir lernen: → Offenheit braucht einen klaren Rahmen oder wiedererkennbare Stoßrichtung (z. B. „Projektmanagement jenseits der Zertifikate“, „radikal praxisorientiert“, „PM für alle“) → Ohne Profil wird man schwer anschlussfähig für neue Gruppen.
5. Vernetzung ohne institutionelle Andockpunkte
Was gefehlt hat: → Kooperationen mit Verbänden, Hochschulen, Medien oder Firmen, die Reichweite, Nachwuchs oder Infrastruktur hätten bringen können.
Was wir lernen: → Ein Verein, der offen ist, muss auch offen für Anschluss sein. → Netzwerkpflege nach außen braucht genauso viel Energie wie interne Arbeit.
Fazit:
openPM war ein mutiges, konsequent digital gedachtes Experiment – mit einer beeindruckenden Anfangsdynamik. Was uns das Genick gebrochen hat, war nicht die Technik oder die Idee – sondern das schleichende Wegbrechen der tragenden Menschen, das Fehlen gezielter Bindungs- und Nachwuchsarbeit und eine gewisse Überforderung durch zu viel Offenheit ohne Rahmen.
Wenn du willst, kann ich daraus eine ehrliche Lessons-Learned-Seite, ein Abschlussstatement oder eine Zukunftsempfehlung für ähnliche Initiativen formulieren. Sag nur, wofür du es brauchst.
