Wie man ein effektives Retro durchführt & Lernchancen für zukünftige Projekte nutzt

Das Transkript lesen:

 

Wir testen die Transkription unserer Podcasts mit einem Softwareprogramm aus. Bitte entschuldigt eventuelle Tippfehler, da der Bot nicht immer zu 100 % korrekt ist.

Galen Low: Hallo zusammen, danke fürs Einschalten. Ich bin Galen Low von The Digital Project Manager. Wir sind eine Community digitaler Fachleute mit der Mission, uns gegenseitig fit, sicher und verbunden zu machen, damit wir den Wert des Projektmanagements in einer digitalen Welt steigern können. Wenn du mehr darüber erfahren möchtest, besuche thedigitalprojectmanager.com.

Heute sprechen wir über Projektrückblicke: wie man sie effektiv durchführt und wie man sicherstellt, dass die Erkenntnisse aus Retrospektiven tatsächlich zu Verbesserungen bei zukünftigen Projekten führen.

Mit mir heute ist Payson Hall, Gründer und Hauptberater der Catalysis Group, der Organisationen seit über 30 Jahren dabei hilft, aus ihren Projektfehlern zu lernen.

Payson, schön, dass du in der Sendung bist.

Payson Hall: Hey, ich freue mich, dabei zu sein und das Publikum kennenzulernen.

Galen Low: Ja, tatsächlich, und ich bin froh, dass du es erwähnst, denn heute machen wir etwas anderes als sonst. Wir sind live mit unseren Mitgliedern als Studiopublikum und nehmen Fragen spontan über unsere Slack-Community auf. Und Michael ist auch mit mir im Studio, er übernimmt einige der Fragen. Wir arbeiten die Fragen in unser Gespräch ein – alles kann passieren! Also, lasst uns loslegen.

Gut, wir steigen direkt ein. Ich dachte, ich nehme gleich eine spannende Frage, weil wir schon darüber gesprochen haben und du als Berater schon seit Jahrzehnten Projektrückblicke für alle möglichen Projekte durchführst, inklusive Softwareprojekte und großangelegte Systemintegrationen. Und ich wollte dich fragen: Wenn du als externer Berater kommst, um die verborgenen Details eines Projektes zu entdecken – sehen die Projektteams dich eher als Freund oder Feind? Ist es wie Mentoring? Fühlt es sich wie ein Audit an?

Payson Hall: Normalerweise ist es ein freundlicher Austausch. Ich möchte klarstellen: Ein Teil meiner Beratung ist tatsächlich Projekt-Autopsien. Wenn ein Projekt völlig aus dem Ruder läuft und das Gefühl entsteht, dass Leute es kommen sahen, aber nichts sagten, dann ähnelt es eher einem Audit.

Tatsächlich arbeite ich mit einem staatlichen Rechnungsprüfer in Kalifornien zusammen und habe Milliardenschwere IT-Projekte geprüft. Da geht es meist darum, eine gerichtliche Argumentation vorzubereiten, damit Anwälte gegen einen Systemintegrator vorgehen können. Der gewöhnlichere und freundlichere Rückblick ist einfach, dass Leute sagen: „Hey, wir haben dieses Projekt abgeschlossen. Lass uns jemanden reinholen, um einen Rückblick zu moderieren.“ Genau das ist ein Retrospektive: Ein Rückblick, um zu sagen: Was haben wir gelernt? Was haben wir clever gemacht (vielleicht damals gar nicht wahrgenommen)? Was hätten wir rückblickend anders gemacht? Im Grunde ist es eine Risikomanagement-Session im Rückspiegel: Was kann ich nächstes Mal besser machen? Was lief raffiniert, das ich wiederholen sollte?

Galen Low: Diese Unterscheidung gefällt mir sehr, denn manche Zuhörer spüren den Unterschied nicht deutlich. Für sie fühlt sich jeder Rückblick wie eine Autopsie an, als würden sie vor Gericht als Beweismittel herhalten, als wäre es ein Schuldzuweisungsspiel, statt – wie du sagst – im Rückspiegel zu schauen und aus Fehlern zu lernen.

Payson Hall: Eine der wenigen wichtigen Regeln bei Retrospektiven – es gibt viele Methoden, aber eine große Empfehlung von mir: Als Projektmanager sollte man niemals seine eigene Retrospektive leiten, denn manche Dinge, die schlecht liefen, hat man vielleicht selbst zu verantworten. Ein guter Moderator sorgt dafür, dass man nicht an die Wand genagelt wird, sondern über das „Was ist passiert, wann, und was nehmen wir daraus mit?“ spricht – und nicht, „Galen, du hast Mist gebaut.“

Das ist nicht konstruktiv. Die Leute werden defensiv und die Diskussion entgleist. Ob du also jemanden extern einlädst oder intern eine vertrauenswürdige, kompetente Person hast: Du brauchst eine externe Partei, die nicht Teil des Projektes war, damit es nicht in Schuldzuweisung ausartet.

Galen Low: Genau, das ist eine interessante Perspektive, weil viele Zuhörer sicher hier sind, um herauszufinden, wie sie selbst einen Rückblick durchführen können. In der Realität ist das für viele Projektteams so – und wir sprechen gleich noch über deine Tipps – aber dein Rat, dass es besser (wenn nicht sogar erforderlich) ist, dass es jemand anderes macht, um eine objektive Sicht beizutragen und nicht in ein Schuldspiel zu verfallen, ist sehr wertvoll.

Payson Hall: Genau, jemand kann mit anderen Annahmen kommen. Überleg dir Projekte, an denen du beteiligt warst: Man trifft Annahmen über Ursachen des Ärgers – und hat vielleicht Recht oder auch nicht. Jemand ohne diese Annahmen könnte offener für andere Sichtweisen oder Erklärungen sein.

Galen Low: Das gefällt mir. Jemand, der nicht 12-18 Monate tief im Projekt steckte und dadurch manche Zusammenhänge nicht mehr sieht. Vielleicht können wir erstmal das große Ganze nehmen. Kannst du erklären, was aus deiner Sicht ein Projektrückblick ist und warum er sich lohnt?

Payson Hall: Gute Frage. Das Wort Retrospektive bedeutet zurückschauen. Die Idee: An einem wichtigen Punkt im Projekt – oder am Ende – halten wir inne und fragen: Was haben wir im letzten Abschnitt gelernt? Welche Lektionen wollen wir für das nächste Segment oder Projekt anwenden – oder gerade NICHT mehr anwenden?

Was haben wir zufällig clever gemacht? Oder: Was würde ich, hätte ich eine Zeitmaschine, rückblickend anders machen? Die Idee ist, kurz innezuhalten und die Ereignisse im Zusammenhang zu betrachten.

Wie du sagst – herauszoomen für das große Bild, damit wir Wichtiges und Unwichtiges erkennen. Manche Dinge sind wie schwarze Schwäne – unerwartete Ereignisse, wie COVID. Dafür werden wir nicht immer planen können, aber wenn es das Projekt trifft, hinterlässt es Spuren.

Es könnten sich trotzdem Lektionen daraus ergeben. Oder du brauchst für ein Projekt 12 Laptops, bestellst vorsichtshalber 14, einer ist DOA – und du bist froh darüber, weil der Zeitplan eng ist.

Im Nachgang war das die richtige Entscheidung: Vielleicht kannst du das Extra-Gerät sogar zurückgeben – oder du schreibst in künftige Verträge das Recht auf Rückgabe, falls es ungeöffnet bleibt.

Vielleicht waren 1000 Dollar sehr gut investiert, weil das drei Wochen Verzögerung erspart hat. Wer in den letzten Jahre mit gestörten Lieferketten gearbeitet hat, weiß, was ich meine.

Galen Low: Ein gutes Beispiel. Und mir gefällt vor allem, dass ein Rückblick auch eine Reflexion auf Dinge sein kann, die richtig gut liefen – raffinierte Ideen oder glückliche Zufälle. Oft sagen Teams, wenn sie gefragt werden „Was lief gut?“ nur belangloses wie: Teamarbeit war toll, Kommunikation war gut… Aber die eigentlichen Lessons sind prägnanter, z.B. als jemand den alternativen Meetingraum buchte und unser Hauptkonferenzraum nicht zur Verfügung stand. Genau daraus kann man lernen und Prozessverbesserungen ableiten – oder eben den Vertrag für Rückgaben anpassen.

Außerdem: Du sagtest, Rückblicke findet am Projektende oder an Schlüsselstellen statt. Viele meinen, am Ende ist es zu spät, da kann man nur nachträglich feststellen, was hätte besser laufen können und muss aufs nächste Projekt warten. Aber es gibt auch während des Projekts Zeitpunkte für eine Retrospektive. Das ist wichtig.

Payson Hall: Ja, das ist ein Ansatz, den wir aus der agilen Welt übernommen haben: Da werden nach jedem Sprint kleine Rückblicke gemacht. Ich habe auf Meilensteinbasis retrospektiven bei Großprojekten erlebt, aber die Agilen haben das wirklich fokussiert: Warum nicht regelmäßig und episodisch Rückblicke machen?

Dann sind sie kleiner, das Team gewöhnt sich daran und es wird zur Routine. Eine Innovation, die die Agilisten wirklich etabliert haben.

Galen Low: Ein guter Wandel im Mindset: Wir können das regelmäßig machen, dann wird es kleiner und weniger aufwendig. Viele Organisationen behaupten, sie wollen aus Fehlern lernen, aber in Wirklichkeit investieren sie wenig in Rückblicke oder holen sich keine externe Moderation. Sie sagen: Wir haben doch eh alles gelernt – lass uns weitermachen. Wie kann man für einen Retrospektiven-Aufwand argumentieren? Lohnt sich das für das Unternehmen?

Payson Hall: Gute Frage. Die Kosten für Lessons Learned müssen natürlich im Verhältnis zum Nutzen stehen. Was braucht es für eine Retrospektive? Ein Beispiel: Ich habe kürzlich eine Retrospektive mit einem Team von 12 Personen gemacht, Projektlaufzeit 18 Monate. Internes Projekt, Anforderungen wurden erfüllt, wenig Verzögerung.

Jedes Teammitglied investierte etwa 4-6 Stunden für Vorbereitung, Meeting und Nachbearbeitung. Als Moderator habe ich rund 12 Stunden investiert, der Projektleiter 8-12 Stunden für Informationen & Durchsprache. Insgesamt lief das auf etwa 2 Personenwochen hinaus.

Bei 12 Personen x 18 Monate = ca. 1000 Personenwochen war das etwa 0,2% Projektzeit für einen Rückblick – Ziel: Lernen, was clever war & was besser geht. If man dadurch auch nur einen kleinen Anteil Zeit gewinnt, hat sich das schon gelohnt! Es kann sich strukturell und organisch auszahlen.

Jede Retrospektive hat Erkenntnisse, Vorschläge und Empfehlungen gebracht, die den Aufwand wert waren.

Galen Low: Und bei kleineren Projekten? Wenn ein Projekt nur vier Wochen dauert, lohnen sich 2 Personenwochen Retrospektive kaum. Streicht man sie dann oder bündelt mehrere kleine Projekte zu einer großen Retrospektive?

Payson Hall: Das habe ich anfangs auch mal falsch gemacht. Du solltest keine Retrospektive mit Leuten machen, die nicht am Projekt beteiligt waren. Damit die Diskussion offen ist, braucht es das vertraute Projektteam. Eine nachträgliche Aggregation kann das PMO machen, aber nicht im eigentlichen Retro. Bei kleinen Projekten reicht vielleicht ein einstündiges Treffen – nach etwas Vorbereitung und Orientierung kann man das informell erledigen.

Galen Low: Genau, wie im agilen Kontext: Kleine Retros am Ende jedes Sprints und am Projektende eine Zusammenfassung der Learnings für Empfehlungen. Zwei Personenwochen müssen also nicht am Stück am Ende investiert werden – man kann das auch zwischendurch kleiner machen.

Payson Hall: Klar – ein Team von acht Leuten, für eine Stunde im Raum, das sind acht Personenstunden. Mit etwas Vorbereitung und Nachbearbeitung vielleicht 12 Stunden Aufwand – inklusive einer einseitigen Auflistung der Lessons Learned.

Galen Low: Und die Opportunitätskosten? Wenn man in einer einzigen Stunde etwas lernt, das künftig eine halbe Million spart, hat es sich zigfach ausgezahlt. Man sollte also auch über die Kosten des „Nichts-Tuns“ nachdenken.

Du sprachst von internen Teams. Viele Zuhörer sind Dienstleister, bei denen Rückblicke nicht als abrechenbar gelten. Wenn weder Kunde noch Unternehmensleitung investieren wollen – wie kann man als Teamleiter die Bedeutung von Retrospektiven gegenüber der Führung vermitteln?

Payson Hall: Ich sage es höflich: Wenn mein CEO zu mir käme und sagt, wir müssen nichts dazulernen, sähe ich mir meinen Lebenslauf an. Früher bei IBM Services: Der Kunde bezahlt dieses Learning meist nicht, sondern die Organisation selbst. Es geht um Kundenzufriedenheit und Effizienz. Man verdient schnell wieder herein, was man als Beratung investiert, sobald ein paar Stunden eingespart werden. Einen guten Rückblick erkennt man oft an einer kleinen Runde zum Frühstück – das bekommen die Partner morgens als Meetingzeit quasi geschenkt und das Team fühlt sich noch geehrt, weil es Frühstück gab.

Natürlich kann es Notfälle geben, etwa wenn eigentlich ein anderes Projekt brennt und das Team ran muss. Aber der Wert von Retrospektiven beweist sich schnell von alleine. Wichtig: Klein anfangen! Hol dir kleine Siege und Beweise für den Mehrwert.

Es hilft auch, die Ergebnisse zu teilen: „Wir haben das umgesetzt und 2 Wochen gespart.“ Dann werden die Chefs überzeugt.

Galen Low: Klein anfangen und Belege sammeln – Beweise, dass es wirklich Wert schafft. Oft fehlt Entscheidern der Beweis, dass ein Rückblick echten Mehrwert für das Geschäft bringt. Nutze also kleine Experimente und schnelle Erfolge zur Argumentation.

Payson Hall: Genau. Oft entsteht aus Retros ein Bericht oder eine Präsentation mit wichtigsten Erkenntnissen. Für Führungskräfte kann (und sollte) das eine Version ohne interne Details sein. Aber wenn sie gut gemacht ist, sensibilisiert sie die Leitung auch für ihren eigenen Anteil an Problemursachen – wie Ressourcenverlagerungen mit kurzem Vorlauf oder das Sparen am falschen Ende. Das lässt sich diplomatisch und konstruktiv ansprechen.

Galen Low: Gute Strategie, auch in der Kommunikation: Die Team- und die Executive-Version zu unterscheiden, ist diplomatisch wichtig.

Payson Hall: Genau. Ich mag das Bild mit der „schmutzigen Wäsche“ nicht so. Ein kluger Mensch sagte mir mal: Die meisten tun ihr Bestes mit den verfügbaren Infos. Man kann immer im Rückblick draufhauen und Fehler suchen, aber das ist nicht der Sinn. Die Frage ist: Welche Infos hattest du? Wie können wir das künftig verbessern? Nur so holt man aus Retrospektiven Wert raus – die sollen nicht zum Sündenbock-Suchen verkommen.

Galen Low: Richtig. Lass uns in den Prozess einsteigen: Angenommen, wir führen eine Projektretreko durch. Wie sieht dein Prozess aus?

Payson Hall: Angenommen, ein Projekt geht ein Jahr mit einem Team von 10-12 Leuten. Erster Schritt: Treffen mit dem Projektleiter – Vertrauensaufbau. Wurde ich eingeladen oder auferlegt? Ich erkläre meinen Prozess: Ich überrumpel niemanden, du siehst alle Erkenntnisse zuerst und kannst argumentieren. Das nimmt Stress. Niemand soll das Gefühl haben, etwas verstecken zu müssen.

Dann kläre ich, was ihr erreichen wolltet, Stichwort: Projektdefinition, Änderungsdokumente, Risikomanagement etc. Gab es ein Charter? Wie hat sich das Ziel verändert? Ich sammle Dokumente und baue mir einen eigenen Überblick – Timeline, Eckdaten, Milestones, Anomalien, Statusberichte.

Spannende Anekdote: Wer Statusberichte eines Jahres liest, entdeckt kleine Warnzeichen, die sich im Nachhinein zu großen Problemen entwickelten. Oft waren die Anfänge marginal (kein Anlass, Alarm auszulösen) und wuchsen schleichend.

Auf Basis der Timeline stimme ich mich mit dem Projektleiter ab, fülle Lücken und bitte das Team, 60-90 Minuten in die Vorbereitung zu investieren: Höhepunkte, Dinge, die gut liefen, clevere Dinge, Pannen, Probleme.

Im Workshop klebe ich eine Zeitleiste an die Wand, verteile Post-its: Was ist wann passiert? (Ereignisse, Personen, Erfolge, Rückschläge). So entsteht ein gemeinsames Bild des Projektverlaufs inklusive positiver sowie negativer Überraschungen.

Kollektiv diskutieren wir: Wie hätten wir Chancen/Risiken früher erkennen können? Wie hätten negative Ereignisse abgeschwächt oder positive verstärkt werden können? Welche Empfehlungen oder Anpassungen ergeben sich daraus für kommende Projekte?

Am Ende entsteht daraus der Rohentwurf für den Bericht: Projektziel, tatsächlicher Verlauf, Kosten, Zeitaufwand, gelungene Ansätze, Probleme, Empfehlungen für die Zukunft. Der Bericht sollte kurz und prägnant sein (ein bis zwei Seiten oder Kurzzusammenfassung).

Galen Low: Wie tief geht ihr bei der Diskussion? Kommen alle Punkte gleichberechtigt auf die Agenda oder werden Schwerpunkte gesetzt?

Payson Hall: Das ist eine Frage des Gefühls: Man gibt jedem Punkt genug Raum für „Aha“-Erlebnisse, aber verliert sich nicht im Detail. Wenn es sich lohnt, tieferzugehen, tun wir das kurz, ansonsten kann man Details auch im Nachgang klären.

Galen Low: Daher braucht es Moderationskompetenz. Man muss erkennen, wann man abbrechen und weitergehen sollte, auch wenn es spannend ist. Nicht alles wird im Retro gelöst – manches geschieht später am Rande, die Hauptsache ist, dass die wichtigsten Themen zur Sprache kommen.

Payson Hall: Exakt. Moderation kann intern oder extern erfolgen – entscheidend ist der Fokus aufs konstruktive Weiterkommen. Ein Moderator muss erkennen, wann eine Diskussion fruchtbar ist und wann sie das Ziel verfehlt.

Galen Low: Klasse Ansatz: Das Ganze als „Risiko-Management im Rückblick“ zu betrachten, nicht nur als Schuldanalyse.

Payson Hall: Genau. Wichtig: Es geht um WAS funktionierte – nicht WER! Der Moderator muss konsequent diesen Ton setzen und ggf. bei Schuldzuweisungen sofort intervenieren. Ziel ist nicht die Schuldfrage, sondern Lerneffekte.

Ich hatte einmal erlebt, wie in einer Retrospektive der Moderator sich auf „Wer war verantwortlich?“ fokussierte. Das ganze Team weigerte sich, jemanden unter den Bus zu werfen – bemerkenswerte Loyalität! So viel Empathie und Disziplin kann man nicht immer erwarten. Daher ist es wichtig, die richtigen Leute im Raum zu haben und den Fokus klar zu setzen.

Galen Low: Und wie kann man vermeiden, dass am Ende dennoch Personen verantwortlich gemacht werden, etwa durch das, was im Bericht steht oder zwischen den Zeilen gelesen wird?

Payson Hall: Personelle Themen gehören nicht in den Bericht, das sollte intern behandelt werden. Findings auf Projektebene sollte immer neutral formuliert werden, etwa: Ressourcen wurden abgezogen – Empfehlung: künftige Planung darauf vorbereiten.

Galen Low: Guter Punkt. Es gibt einen Unterschied zwischen strukturellen Projektproblemen und persönlichen Themen, die im Bericht nichts zu suchen haben.

Payson Hall: Der Bericht muss diplomatisch sein – konstruktiv, eher zukunftsorientiert als rückwärtsgewandt. Kritik sollte als Chance zur Verbesserung formuliert werden.

Galen Low: Viele schrecken zurück, weil sie meinen, die Learnings aus dem Bericht würden ohnehin verstauben. Wie kann man sicherstellen, dass sie auch wirklich zu positiven Veränderungen führen?

Payson Hall: Der Bericht darf nicht zu lang sein. Wichtig ist die Priorisierung – ein paar zentrale Erkenntnisse herausstellen und an die Führung kommunizieren. Alles Weitere wissen die Teammitglieder für sich und nehmen es ins nächste Projekt mit. Die Idee einer riesigen Lessons-Learned-Datenbank ist zwar präsent – in der Praxis jedoch selten erfolgreich. Besser sind gezielte Empfehlungen und die informellen, organischen Lerneffekte durch die Teilnehmenden.

Ein gutes Beispiel ist z. B. die Empfehlung, einen festen Projektraum („War Room“) für größere Projekte zu reservieren, da das ständige Suchen von Räumen enorme Zeit vergeuden kann.

Galen Low: Es gibt also strategische Empfehlungen nach oben und informelle Lerneffekte an der Basis. Beides ist wertvoll und setzt Veränderungen in Gang.

Payson Hall: Absolut. Und das wirkt sich auch auf künftige Risikomanagementsessions aus: Wer gerade eine Retrospektive gemacht hat, hat bestimmte Risiken präsenter und kann so bei der Planung gezielter vorsorgen. Das trägt sich dann weiter, weil andere Teammitglieder davon erfahren.

Galen Low: Es ist wie ein Erfahrungsschatz, eine Story-Kultur, die Wissen transportiert – auch dann, wenn es nicht explizit als Learning-Datenbank erfasst wird.

Ich nehme eine Publikumsfrage auf: Wie steht es um „Prä-retrospektiven“ („Pre-Mortem“)? Sind sie sinnvoll, und wie lassen sie sich im agilen Kontext mit klassischen Retrospektiven kombinieren?

Payson Hall: Im agilen Kontext verschmelzen die Ansätze meist: Die Lessons aus einer Retros fließen direkt ins Risikomanagement des nächsten Sprints ein. Das ist gesund und effizient, weil bestehende Erkenntnisse sofort in die nächste Planungsphase umgesetzt werden.

Galen Low: Guter Punkt. Man spricht in beiden Fällen über Hindernisse und Verbesserungsmöglichkeiten – egal, ob als Rückblick oder Preview für den nächsten Arbeitsschritt.

Was passiert, wenn die Ursache für ein Problem extern vorgegeben ist – z. B. Abzug wichtiger Teammitglieder durch die Führung? Wie kann man das in Erkenntnissen und Empfehlungen darstellen, ohne zu beschuldigen?

Payson Hall: Die Erkenntnis sollte neutral formuliert werden: „Im Projekt gab es Herausforderungen aufgrund von Umverteilung wichtiger Ressourcen auf andere priorisierte Projekte.“ Die Empfehlung wäre: „Künftige Projekte so planen, dass diese Ressourcenengpässe abgefedert werden oder frühzeitig reagiert werden kann.“

Galen Low: Ein sinnvoller, neutraler Ansatz.

Abschließend: Was sind die wichtigsten Themen, auf die man sich in einem Rückblick mit begrenzter Zeit konzentrieren sollte?

Payson Hall: Kommt auf den Kontext an. Zwei Kernfragen: Gab es eine klare Definition, die von allen Stakeholdern akzeptiert und freigegeben wurde? Gab es ein effektives Änderungsmanagement? Viele Probleme entstehen, weil Zusatzaufgaben (Scope Creep) nicht sauber mit Ressourcen und Zeit hinterlegt werden. Das sind die größten Stellhebel für Verbesserungen.

Galen Low: Genau. Es kommt auf die gemeinsame Basis und die wertvollsten Ansatzpunkte für das Team an.

Vielen herzlichen Dank, Payson! Es war eine Ehre, dich in der Sendung zu haben. Wie kann man mehr über deine Arbeit bei der Catalysis Group erfahren?

Payson Hall: Unter catalysisgroup.com gibt es Infos zu Training und Beratung. Und unter „Ressourcen“ einige Artikel, u. a. zu Risikomanagement – sehr hilfreiche Lektüre für Retrospektiven.

Galen Low: Ich kann bezeugen: Payson schreibt unterhaltsam und praxisnah – seine Artikel bleiben im Kopf. Wer bisher noch meinte, dass Retrospektiven trocken sind, sollte seine Artikel lesen. Den Link findet ihr in den Shownotes.

Für alle Zuhörer: Ich hoffe, ihr konntet viel mitnehmen! Falls Fragen offen blieben, werden wir sie in der Community weiter diskutieren.

Payson Hall: Und bei Fragen gerne eine E-Mail schreiben – ich antworte gerne nach der Sendung.

Galen Low: Danke fürs Zuhören! Wenn du mit über tausend gleichgesinnten Projektmanagement-Profis ins Gespräch kommen willst, komm in unsere Community! Mehr dazu auf thedigitalprojectmanager.com/membership . Und wenn dir gefallen hat, was du heute gehört hast: Abonniere uns und bleibe auf thedigitalprojectmanager.com auf dem Laufenden.

Bis zum nächsten Mal – danke fürs Zuhören.