Gkc25/Wissen bewahren in Projekten - Co-Creation unserer Best Practices

Diese Session befasst sich mit den Herausforderungen beim Bewahren und Weitergeben von Projektwissen in Organisationen. Anhand eines Praxisbeispiels wird deutlich, wie wichtig es ist, nicht nur Lessons Learned zu dokumentieren, sondern diese auch strukturiert zu reflektieren und aktiv zu transferieren. Die Präsentation zeigt auf, dass faktenbasierte Analysen allein nicht ausreichen – es braucht erfahrungsbasierte Reflexion, geeignete Formate wie Storytelling und vor allem eine Wissenskultur, die das Teilen von Erfahrungen fördert. Entscheidend sind dabei die drei Dimensionen Mensch, Technik und Organisation sowie ein nachhaltiger Transferprozess.

Hauptthemen der Präsentation:

1. Das Problem traditioneller Lessons-Learned-Prozesse
2. Der Unterschied zwischen explizitem und implizitem Wissen
3. Die drei Säulen erfolgreichen Wissensmanagements
4. Faktenbasierte Analyse versus erfahrungsbasierte Reflexion
5. Die Bedeutung von Storytelling und Wissenskultur
6. Konkrete Methoden und Formate für den Wissenstransfer
7. Herausforderungen in projektintensiven Organisationen

Das Problem traditioneller Lessons-Learned-Prozesse

Die Session beginnt mit einem anschaulichen Beispiel aus der Praxis: John, ein 59-jähriger IT-Projektleiter, schließt 2019 ein dreijähriges Migrationsprojekt mit Kunde Z ab. Vorbildlich führt er den vorgesehenen Meilenstein Lessons Learned durch. Sechs Jahre später startet Sonja, eine 42-jährige Projektleiterin aus dem Vertriebsbereich, ein Digitalisierungsprojekt mit demselben Kunden – und ihr Projekt wird sechs Monate Verzögerung haben.

Was ist schiefgelaufen? John hat seine Pflicht erfüllt: Er lud sein Team zu einem einstündigen Termin ein, erstellte PowerPoint-Folien über die Projekterfahrungen, ließ diese vom Team abnicken und legte das Dokument ordnungsgemäß auf SharePoint ab. Danach hat nie wieder jemand dieses Dokument angeschaut. Doch das ist nicht das eigentliche Problem.

Die wahre Problematik war eine andere: Während des hektischen Projektverlaufs gab es massive Schwierigkeiten an einer bestimmten Schnittstelle. Um das Projektziel termingerecht zu erreichen und den Kunden zufriedenzustellen, baute das Team mehrere Workarounds. Diese funktionierten auch – das Projekt wurde erfolgreich abgeschlossen. Allerdings wurden diese Workarounds nie dokumentiert, nie reflektiert, und niemand dachte darüber nach, was mit diesen temporären Lösungen langfristig passieren würde.

Sechs Jahre später explodierten genau diese ungelösten Schnittstellenprobleme in Sonjas Projekt. Sie musste die Konsequenzen ausbaden, ohne je von den Erfahrungen Johns profitiert zu haben. Das Kernproblem: Dokumentiert ist nicht gleich gelernt. Es handelt sich eher um ein “Project documented” als um ein echtes “Lesson learned”.

Was fehlte konkret? Erstens die Priorität für das Thema – mit nur 60 Minuten kann man nicht wirklich reflektieren, diskutieren oder lernen. Zweitens fehlte die Vernetzung zwischen Johns Entwicklungsbereich und Sonjas Vertriebsbereich. Es gab schlichtweg keine Kommunikation zwischen den Bereichen. Drittens fehlte eine durchdachte Struktur. Zwar existierte ein Meilenstein namens Lessons Learned, aber der Prozess endete viel zu früh – mit dem Ablegen auf SharePoint war Schluss. Das Potenzial, anderen Projekten zu helfen und Folgefehler zu vermeiden, wurde komplett verschenkt.

Eine erwähnte Studie belegt, dass jedes sechste Projekt scheitert – zwar nicht komplett, aber daran, die Versprechen an den Kunden bezüglich Qualität, Zeit und Budget einzuhalten. Diese Quote ließe sich deutlich verbessern.

Der Unterschied zwischen explizitem und implizitem Wissen

Ein zentrales Element der Präsentation ist die Unterscheidung zwischen explizitem und implizitem Wissen. Explizites Wissen umfasst alles, was bereits in konsumierbarer Form vorliegt: Lastenhefte, Pflichtenhefte, Verträge, aber auch Videos oder Podcasts im Unternehmenskontext. Dieses Wissen ist dokumentiert, lesbar und relativ leicht zugänglich.

Das implizite oder Erfahrungswissen hingegen ist weitaus schwieriger zu fassen. Es befindet sich metaphorisch unter der Wasseroberfläche. Wo findet man dieses Wissen? Überall: beim Maschinenbauer, der ein Geräusch hört und sofort weiß, was die Maschine hat. Bei Tänzern, die nicht in einem Dokument nachlesen müssen, wann sie welche Bewegung ausführen – es ist einfach in ihnen drin. Genauso existiert dieses Wissen im Projektmanagement.

Beim Erfahrungswissen handelt es sich um das Know-how, das für Entscheidungen, das Finden von Lösungen und das Einschätzen von Risiken verwendet wird. Es basiert auf Erfahrung, Werten und Intuition. An dieses Wissen kommt man vor allem durch interviewartige Situationen heran – durch Reflexion und durch tiefergehende Fragen, die unter die Wasseroberfläche führen.

Die Referentin berichtet aus ihrer eigenen Erfahrung: Während ihres dualen Studiums der Wirtschaftsinformatik, zur Zeit als Web 2.0 und Wikis als große Innovation galten, fiel ihr in einem Bereich mit 100 Projektmitarbeitenden auf, dass alle ähnliche Probleme erzählten und ähnliche Fehler ausmerzten – eine offensichtliche Ressourcenverschwendung. Für ihre Bachelorarbeit entwickelte sie eine Wissensdatenbank mit entsprechenden Datenfeldern für Erfahrungswissen. Sie fragte gezielt nach den wichtigsten Learnings und Erfahrungen aus Projekten.

Technisch war die Lösung top und wurde mit einer Eins bewertet. Praktisch jedoch war sie ein Flop – niemand benutzte die Datenbank. Die Gründe dafür fand sie später im Studium der Wirtschaftspsychologie: Es fehlte die Führungskultur. Der Chef hatte zwar gesagt “Top, mach das”, aber es gab keinen weiteren Rückenwind, kein Vorangehen, keine Integration in Meetings. Change Management existierte damals in diesem Unternehmen überhaupt nicht – von einem Tag auf den anderen sollten alle ein neues Tool nutzen.

Ein weiterer kritischer Punkt war das Thema Storytelling. Erfahrungen lassen sich am besten in Geschichten verpackt weitergeben. Lehrer müssen jahrelang studieren, um zu lernen, wie sie Wissen vermitteln. Journalisten studieren ebenso lange, um Informationen in Geschichten zu verpacken. Wenn man jedoch einen IT-Mitarbeiter vor eine Datenbank setzt und erwartet, dass er sich selbst reflektiert und etwas aufschreibt, das andere auch noch interessant finden – dann ist das eine gewaltige Herausforderung.

Die drei Säulen erfolgreichen Wissensmanagements

Ein häufiger Trugschluss beim Thema Wissensmanagement ist die Fokussierung auf Tools. Viele denken sofort an Wikis, Confluence oder Jira. Doch diese enden beim Thema Lessons Learned oft als Datenfriedhöfe. Was wirklich gebraucht wird, ist eine Wissenskultur.

Beispiele aus der Wirtschaftsgeschichte verdeutlichen dies: Kodak und Nokia hatten Tools, verschliefen aber den technischen Wandel. VW hatte beim Emissionsskandal ebenfalls alle technischen Mittel. Boeing und NASA hatten ihre verheerenden Fehler, die teilweise Menschenleben kosteten. Alle diese Unternehmen verfügten über Tools – was fehlte, war die entsprechende Kultur.

Erfolgreiches Wissensmanagement muss immer drei Dimensionen betrachten: Mensch, Technik und Organisation. Auch auf Projektebene gilt: Man kann nicht einfach nur ein Tool einführen. Man muss auch den Menschen berücksichtigen, der das Tool nutzen oder in einem Prozess mitwirken soll. Und man braucht die organisatorischen Rahmenbedingungen – die Führungskultur, die Prozesse, die Rollenbeschreibungen und vor allem die Zeit, um mitzuarbeiten.

Wissensmanagement ist dabei kein Selbstzweck, sondern eine Querschnittsfunktion zur Verbesserung aller wertschöpfenden Prozesse. Wenn man beim Projektmanagement ansetzt und einen Prozess effizienter gestaltet, berührt man automatisch viele weitere Themen: die Lern- und Fehlerkultur, On- und Offboarding (das auch in Projekten stattfindet), Change Management und Organisationsentwicklung.

Die Draufsicht auf ein Unternehmen, das sich noch nicht intensiv damit beschäftigt hat, wie es Wissen aus Projekten bewahrt und weitergibt, zeigt verschiedene Jahre mit einzelnen Projekten, die parallel nebeneinander laufen. Jeder macht sein eigenes Ding, braut sein eigenes Süppchen. Besonders problematisch: geschlossene Projektlaufwerke. Für ein Jahr wird alles gespeichert und gesammelt, dann wird das Laufwerk aus Gründen der Regulatorik und des Datenschutzes geschlossen. Wenn später ein neues Projekt mit demselben Kunden startet, kann man nicht mehr darauf zugreifen.

Die Empfehlung lautet: Es sollte zumindest ein Minimum an Informationen geben, die weiter zugänglich bleiben – zum Beispiel in Form eines Projektsteckbriefs mit den wichtigsten KPIs, Ansprechpartnern, Kundennamen und einer Beschreibung der durchgeführten Arbeiten. Wenn Regulatorik und Datenschutz es erlauben, könnten sogar Projektberichte verfügbar bleiben. Wenn diese Schlösser geöffnet und die Trennlinien zwischen Projekten aufgehoben werden, braucht es Kontaktpunkte zwischen den Projekten. Der Weg dorthin erfordert Veränderungen an vielen Stellen – wieder müssen Mensch, Organisation und Technik gemeinsam betrachtet werden.

Faktenbasierte Analyse versus erfahrungsbasierte Reflexion

Die Begrifflichkeiten rund um das Thema sind in jedem Unternehmen unterschiedlich. Die gängigsten sind Projekt-Debriefing, Lessons Learned und Projekt-Retrospektive. Ursprünglich war Debriefing eher für Zahlen, Daten und Fakten gedacht, Lessons Learned als Teil davon. Oft wird es in Unternehmen aber anders gehandhabt: Man macht einen Lessons-Learned-Termin von 60 Minuten und handelt alles ab. Die Retrospektive hingegen fokussiert sich vordergründig auf die Erfahrungen, auch auf Team-Ebene.

Was bei allen drei Varianten häufig fehlt: Was kommt danach? Wie geht es weiter? Wie können andere daraus lernen?

Ein umfassender Ansatz besteht aus drei Schritten:

Faktenbasierte Analyse: Dies ist die Zahlen-Daten-Fakten-Ebene, auf der explizites Wissen erfasst wird. Die meisten Unternehmen bekommen diesen Teil noch hin. Man vergleicht Soll und Ist – relativ einfach zu beantworten anhand der Zahlen. Als Output entstehen beispielsweise ein Projektsteckbrief (das Minimum) und der Projektbericht. In manchen Unternehmen, besonders im Consulting-Bereich, werden die Informationen in eine Projektdatenbank eingepflegt. Für große Unternehmensberatungen ist dies eine absolute Goldgrube, da man nach formalen Kriterien nach ähnlichen Projekten suchen kann.

Erfahrungsbasierte Reflexion: Dieser Teil braucht deutlich mehr Zeit und Raum – idealerweise einen ganzen Tag in einem Workshop, um das Projekt wirklich zu reflektieren, den Ablauf zu durchleuchten und auf Team-, Prozess-, Struktur- und Organisationsebene zu schauen. Hier bewegt man sich auf der Ebene des Erfahrungswissens, unter der Wasseroberfläche. Hier kommen vor allem Geschichten als Output heraus, denn Geschichten sind das, was sich verbreitet. Möglicherweise entsteht auch ein Antrag auf Veränderung – wenn man in der Reflexion feststellt, dass es in einem Prozess, an einer Schnittstelle oder bei Informationen zu einer Neuerung geruckelt hat.

Transfer und Umsetzung: Dies ist der Schritt, der bei vielen Unternehmen komplett fehlt. Man macht Lessons Learned – und das war’s. Wie die Erkenntnisse zu anderen Projekten kommen, ist nicht geregelt. Für echte Nachhaltigkeit bräuchte es eine Koordinationsstelle – vielleicht im PMO oder einer anderen geeigneten Stelle, die solche Veränderungsanträge entgegennimmt, eine Relevanzprüfung durchführt (wofür man Fachleute und Techniker braucht) und dann einen Veränderungsprozess anstößt.

Die Bedeutung von Storytelling und Wissenskultur

Ein Best-Case-Szenario würde so aussehen: Ein Projektmitarbeitender sammelt wertvolle Erfahrungen in einem ruckeligen Projekt mit vielen Auf und Abs. Er denkt sich: “Ich sollte das reflektieren.” Er setzt sich hin, reflektiert und erkennt, dass die Lehren daraus sehr relevant für andere Projekte sind. Daraufhin beruft er selbstständig ein Meeting mit allen Betroffenen ein und teilt die Erkenntnisse. Die Teilnehmenden sehen Anknüpfungspunkte für ihre eigenen Projekte oder wissen, an wen sie die Informationen weitergeben können. Sie setzen die Erkenntnisse in ihrem Arbeitsalltag um und integrieren sie. Mit diesen neuen Erkenntnissen werden wieder neue Erfahrungen gesammelt – der Kreis beginnt von vorne.

Die Realität: Oft endet es beim Sammeln wertvoller Erfahrungen. Dann war’s das. Man kann jedoch an zwei Stellen ansetzen: bei der Reflexion und beim Teilen.

Hier kommt das Thema Storytelling ins Spiel. Als Beispiel dient die Geschichte der drei Schweinchen: Sie wohnen bei ihrer Mama, die ihnen irgendwann sagt, sie seien alt genug und sollten ausziehen und eigene Häuser bauen. Das erste Schweinchen baut schnell ein Haus aus Stroh. Das zweite denkt etwas nach und verwendet Holz. Das dritte investiert richtig viel Mühe, Kraft, Schweiß und Blut und baut aus Backstein.

Dann kommt der hungrige Wolf. Beim ersten Schweinchen angekommen, pustet er das Strohhaus mit einem Luftzug weg. Das Schweinchen flüchtet zum zweiten. Der Wolf folgt und pustet auch das Holzhaus relativ schnell um. Beide Schweinchen retten sich zum dritten. Dort kann der Wolf gegen das Backsteinhaus nicht anpusten, versucht es auf andere Weise, aber die Schweinchen überlisten ihn und überleben.

Würde man nur die Lehre dokumentieren, stünde in der Datenbank: “Backstein ist das beste Baumaterial.” Was geht dabei verloren? Das gesamte Thema Team, Kommunikation und Kollaboration. Und das Thema Qualität – das dritte Schweinchen hat lange Zeit investiert, in der es ohne fertiges Haus der Gefahr ausgesetzt war, gefressen zu werden. Aber die Investition in Qualität hat sich bewährt.

Dieses Beispiel verdeutlicht, warum Storytelling so wichtig ist. Die Geschichte transportiert so viel mehr als die bloße Kernaussage. Menschen verbinden sich mit Social-Media-Accounts wie Instagram, weil sie etwas lernen wollen, aber auch unterhalten werden möchten. Es muss ansprechend verpackt sein. Im Unternehmenskontext ist es nicht anders. Natürlich gibt es Richtlinien, und man muss sich informieren, wenn es Neuheiten gibt. Aber mehr Freude macht es, wenn Inhalte ansprechend verpackt sind.

Konkrete Methoden und Formate für den Wissenstransfer

Es gibt verschiedene Wege, um Geschichten und Erfahrungswissen weiterzutragen – sowohl digital als auch in Präsenz.

Digitale Formate:

• Blog-Beiträge im Unternehmenskontext
• Interne Podcasts
• Video-Dokumentationen (besonders wertvoll, wenn Interviews als Stories aufgezeichnet werden)
• Unternehmensinterne Social-Media-Plattformen

Präsenzformate:

• Communities of Practice: regelmäßige Treffen von Menschen mit ähnlichen Themen oder Herausforderungen
• Projektmarktplätze: Veranstaltungen, bei denen Projekte ihre Erfahrungen präsentieren
• World Cafés: strukturierte Gesprächsrunden zu bestimmten Themen
• Fuck-Up-Nights: Veranstaltungen, bei denen offen über Fehler und Misserfolge gesprochen wird
• Die Kaffeeküche: informeller Austausch, der nach wie vor sehr wichtig ist

Die Kombination aus beidem ist ideal. Wichtig ist dabei, dass nicht nur reflektiert wird, sondern dass es auch klare Prozesse gibt, wie die Erkenntnisse weitergegeben werden. Eine Möglichkeit ist die thematische Kanalisierung: Man fragt über das Intranet als Umfrage ab, zu welchen Themen Teams intensiv ihre Erfahrungen in Lessons-Learned-Sessions einbringen sollen. So wird der Bedarf ermittelt. Zusätzlich können dauerhafte thematische Wissensteams existieren, in denen kontinuierlicher Erfahrungsaustausch stattfindet – nicht für alle Teams zu allen Themen, sondern anhand der Themen, die sie verbinden.

Ein erfolgreiches Beispiel aus der Automobilzulieferbranche: Bei Projektanträgen musste ein Feld ausgefüllt werden, in dem angegeben wurde, auf welche vorherigen Forschungen oder Projekte man aufbauen möchte. Am Projektende gab es eine verpflichtende Abschlusspräsentation, die verschriftlicht wurde. Dadurch entstand die Möglichkeit, entweder das Dokument zu bekommen oder die Projektleitung und Teilnehmenden direkt anzusprechen. Dies funktionierte in dieser hierarchischen Unternehmenskultur und mit den passenden Werkzeugen.

Herausforderungen in projektintensiven Organisationen

Eine zentrale Frage aus der Diskussion lautete: Was macht man in Organisationen mit mehreren hundert parallel laufenden Projekten? Ist ein aufwendiger Reflexions- und Storytelling-Prozess dann überhaupt praktikabel, oder würde man von Informationen geflutet?

Hierzu gibt es verschiedene Perspektiven:

Fokussierung auf relevante Projekte: Eine Möglichkeit ist, aufwendigere Reflexionsprozesse nur bei größeren, längerfristigen Projekten (zum Beispiel zwei- oder dreijährige Projekte) durchzuführen. Kleinere Projekte könnten mit einem Minimum an Dokumentation auskommen.

Thematische statt projektbasierte Organisation: Eine wichtige Anmerkung aus der Online-Teilnahme war, dass es vielleicht ein strategischer Fehler ist, sich ausschließlich auf Projekte zu fokussieren. Stattdessen sollte man Wissen mit Fokus auf Unternehmensfunktionen, Unternehmensnetzwerke, Prozesse und verschiedene Perspektiven des Unternehmens bewahren. Aus allen Perspektiven des Unternehmens gibt es die Notwendigkeit, Wissen zu bewahren – nicht nur aus Projekten.

Bedarfsgesteuerte Reflexion: Durch Umfragen im Intranet kann abgefragt werden, zu welchen Themen intensive Reflexion gewünscht ist. So wird der tatsächliche Bedarf ermittelt und Ressourcen werden gezielt eingesetzt.

Die Rolle des Interviews: Ein kritischer Punkt ist, dass kaum jemand freiwillig ausführliche Reflexionen aufschreibt. Was funktioniert, ist, wenn jemand Interviews führt nach dem Motto “Du hast gerade das Projekt gemacht, setz dich mal hin, ich schreibe das alles für dich auf.” Ohne diese Unterstützung passiert es nicht. Besonders die unerfreulichen Dinge werden unter den Tisch fallen gelassen, weil niemand gerne zugibt, dass etwas schiefgelaufen ist.

Kontextproblem: Dave Snowden hat darauf hingewiesen, dass Lessons Learned auch deshalb oft nicht funktionieren, weil man nie denselben Kontext in einem nächsten Projekt hat – und den Kontext kann man in eine Datenbank kaum einfügen. Zudem: Im Dialog kann man jemandem in 15 Minuten helfen. Soll dasselbe verschriftlicht werden, wird daraus ein Buch, weil alle Varianten aufgeschrieben werden müssen, die man im Dialog schnell klärt. Keine Firma hat die Ressourcen, Knowledge so aufzuschreiben.

Ressourcen und Kultur: Die pauschale Aussage “Das macht niemand” oder “Man hat keine Zeit dafür” stimmt nicht überall. Es gibt Beispiele, auch aus anderen Ländern, wo dies funktioniert – weil es entsprechend mit Ressourcen ausgestattet und unterstützt wird. Es gibt durchaus offene Kulturen, die das praktizieren. Die Unterschiede zwischen Organisationen sind erheblich.

Codification versus Personalization: Ein alter wissenschaftlicher Ansatz unterscheidet zwischen Codification (Wissen wird kodifiziert und in Datenbanken gespeichert) und Personalization (Wissen wird über Menschen weitergegeben). Firmen mit Standardgeschäft, die Dinge wiederverwenden können, profitieren von Codification – allerdings nur mit erheblichen Ressourcen. Eine große Unternehmensberatung beschäftigt beispielsweise allein 200 Mitarbeiter in Indien, die Dokumente mit entsprechenden Schlagworten erschließen.

Fazit und Ausblick

Wissensmanagement in Projekten ist eine komplexe Herausforderung, die weit über das bloße Dokumentieren von Lessons Learned hinausgeht. Der Schlüssel liegt in der Kombination von faktenbasierter Analyse, erfahrungsbasierter Reflexion und einem aktiven Transfer der gewonnenen Erkenntnisse.

Die drei Dimensionen Mensch, Technik und Organisation müssen gleichermaßen berücksichtigt werden. Tools allein reichen nicht aus – es braucht eine Wissenskultur, die das Teilen von Erfahrungen fördert und wertschätzt. Storytelling hat sich als wirksame Methode erwiesen, um Erfahrungswissen zu transportieren, da Geschichten emotional berühren und dadurch besser im Gedächtnis bleiben.

Kritische Erfolgsfaktoren sind:

• Ausreichend Zeit und Raum für echte Reflexion (nicht nur 60 Minuten)
• Vernetzung zwischen verschiedenen Bereichen und Projekten
• Strukturierte Prozesse, die nicht beim Ablegen eines Dokuments enden
• Rollen wie Interviewer oder Kuratoren, die beim Explizieren von Wissen helfen
• Führungskultur, die Wissensmanagement vorlebt und unterstützt
• Bedarfsgesteuerte Ansätze, die sich an relevanten Themen orientieren

Offene Fragen:

• Wie schafft man den Spagat zwischen Aufwand und Nutzen in projektintensiven Organisationen mit hunderten parallel laufenden Projekten?
• Wie löst man das Kontextproblem – dass dokumentiertes Wissen ohne Kontext schwer übertragbar ist?
• Wie kann man eine Kultur schaffen, in der auch über Fehler und Misserfolge offen gesprochen wird?
• Welche Rolle sollte KI künftig beim Erschließen und Aufbereiten von Projektwissen spielen?

Handlungsempfehlungen:

• Schaue kritisch auf deine aktuellen Lessons-Learned-Prozesse: Enden sie beim Dokumentieren oder gibt es echten Transfer?
• Investiere in Formate, die Dialog ermöglichen – Interviews, Workshops, Communities of Practice
• Etabliere eine Koordinationsstelle, die Veränderungsanträge aus Projekten entgegennimmt und weiterverarbeitet
• Nutze Storytelling-Formate, um Erfahrungswissen weiterzugeben – ob als Blog, Video oder Präsenzveranstaltung
• Vernetze dich mit anderen, die vor ähnlichen Herausforderungen stehen – zum Beispiel in der neu gegründeten GFÖM-Fachgruppe “Wissen sichern und bewahren in Projekten”, die als Austauschplattform dienen soll
• Denke über den Projektrahmen hinaus: Wissensmanagement sollte sich an Unternehmensfunktionen, Prozessen und Netzwerken orientieren, nicht nur an Projekten
• Stelle sicher, dass zumindest ein Minimum an Informationen (Projektsteckbrief mit KPIs und Ansprechpartnern) auch über Projektgrenzen hinweg zugänglich bleibt

Die Herausforderung besteht nicht darin, die perfekte Lösung zu finden, sondern einen für die jeweilige Organisation passenden Weg zwischen Aufwand und Nutzen, zwischen Standardisierung und Flexibilität, zwischen explizitem und implizitem Wissen. Der Austausch mit anderen Organisationen und das gegenseitige Inspirieren können dabei helfen, praktikable Lösungen zu entwickeln.