Zum Inhalt springen

Durchführung 2 - Qualitätsmanagement und kontinuierliche Verbesserung

Google Project Management Certificate · Kurs 4: Projektdurchführung - Das Projekt steuern


In der Durchführung wird das Deliverable tatsächlich gebaut, und deshalb ist das auch die Phase, in der die Frage ist das eigentlich gut? laut beantwortet und nicht stillschweigend vorausgesetzt werden muss. Dieses Modul behandelt Qualitätsmanagement - die vier zusammenhängenden Konzepte, die aus der vagen Hoffnung auf ein gutes Produkt etwas Messbares machen - und Verbesserung, sowohl während das Projekt läuft als auch nach seinem Ende.

Der rote Faden lautet: Qualität ist nicht die Meinung des Teams. Das magische Dreieck aus Zeit, Scope und Budget prägt sie, denn wer eines der drei zusammendrückt, lässt die Qualität leiden - aber das Urteil gehört der Kundschaft. Deshalb dreht sich die halbe Modulzeit darum, sie zu fragen: Feedback-Umfragen, User Acceptance Testing und die Soft Skills, die solche Gespräche ehrlich machen.

Die andere Hälfte handelt davon, aus dem Geschehenen zu lernen. Kontinuierliche Verbesserung und Prozessverbesserung sorgen dafür, dass die Arbeit im Laufen besser wird, und Retrospektiven halten die Erkenntnisse an Milestones und am Ende fest, schuldfrei, damit sie ins nächste Projekt übergehen statt sich in Luft aufzulösen.


Es gibt einen echten Unterschied zwischen fertig und Qualität. Jede Aufgabe im Plan abzuhaken ist nicht die Leistung; das Deliverable muss den Maßstab der Kundschaft erfüllen und nicht bloß existieren.

Daraus folgen zwei Dinge. Qualität wird von außerhalb des Teams beurteilt, also brauchst du einen Weg, die Erwartungen der Kundschaft zu erfahren, und einen Weg zu prüfen, ob du sie triffst. Und Kommunikation ist der Hebel: Je besser ein Projektmanager mit dem Team kommuniziert, desto wahrscheinlicher liefert das Team hochwertige Deliverables. Um das einzulösen, braucht es die Kernkonzepte der Qualität plus einen Qualitätsplan, den du auch wirklich überwachst.


Qualitätsstandardsvereinbaren, was gut heißt
→
Qualitätsplanungfestlegen, wie man es trifft
→
Qualitätssicherunglaufend auditieren
→
QualitätskontrolleErgebnisse prüfen, korrigieren
Die Kette läuft von links nach rechts, aber Qualitätssicherung und Qualitätskontrolle sind keine einmaligen Phasen: Sie spannen sich über den gesamten Lebenszyklus und fließen immer wieder in den Plan zurück.

Lege sie gemeinsam mit deinem Team und deiner Kundschaft ganz zu Beginn fest, definiere sie klar genug, dass alle genau wissen, worum es geht, und prüfe dann regelmäßig nach, ob die Anforderungen noch erfüllt werden. Gut definierte Standards zahlen sich direkt aus: weniger Nacharbeit und weniger Terminverzug. Sie gelten für alle Produkte und Prozesse. Durchgehendes Beispiel ist Projekt Plant Pals bei Office Green, ein neuer Service, der Top-Kunden schreibtischtaugliche Pflanzen liefert:

StandardtypBeispiel Plant Pals
ZuverlässigkeitJeder Pflanztopf kommt zur vereinbarten Zeit und in gutem Zustand an, bereit für den Schreibtisch; Lieferanten halten genug Bestand, um die Nachfrage pünktlich zu bedienen
BenutzbarkeitPflanztöpfe lösen keine allergischen Reaktionen oder Erkrankungen aus und passen zu allen Menschen, und wo relevant auch zu Tieren
ProduktDer Lieferant trifft Look and Feel der Marke, verwendet die vorgegebenen Materialien und liefert den Artikel unbeschädigt
Benutzbarkeit, auf einen Prozess angewendetDie Bestell-Website muss auf Handy, Computer und Tablet leicht zu navigieren sein

Vier Fragen steuern die Diskussion: Welches Ergebnis wünscht sich meine Kundschaft am Ende dieses Projekts, wie sieht Qualität aus ihrer Sicht aus, wie kann ich ihre Erwartungen erfüllen, und woran erkenne ich, ob die Qualitätsmaßnahmen zum Projekterfolg geführt haben? Hier werden die Verfahren entworfen. Ist Zuverlässigkeit ein Standard, dann besteht die Planungsmaßnahme darin, mit dem Pflanzenlieferanten zu vereinbaren, die Pflanztöpfe auf Haltbarkeit zu testen, bevor du dich festlegst, sie einzusetzen.

Der Qualitätsplan sollte regelmäßige Audits vorsehen, die bestätigen, dass der Plan eingehalten wird, dazu regelmäßige Check-ins und Berichte, die das Vertrauen der Stakeholder und dein eigenes stärken. Über QA stellst du sicher, dass du und die Kundschaft genau das Produkt bekommen, das vertraglich vereinbart wurde. Bei Plant Pals heißt das, die Pflanztopf-Optionen zu begutachten und bei den Haltbarkeitstests dabei zu sein; führt der Lieferant diese Tests selbst durch, verfolgst du seinen Fortschritt und fragst regelmäßig nach, statt es einfach anzunehmen.

Bei Plant Pals ist die Qualitätskontrolle der abschließende Rundgang durch die Kundenbüros nach der Lieferung, bei dem nach zerbrochenen Pflanztöpfen oder auf dem Transport beschädigten Pflanzen gesucht und Ersatz gestellt wird. Man würde das nicht für jede Kundin und jeden Kunden auf ewig tun, aber es früh zu tun deckt Probleme auf, die man zurück im Büro verbessern kann, was auch dem nächsten Projekt eine bessere Landung verschafft.

Qualitätssicherung und Qualitätskontrolle im Vergleich

Abschnitt betitelt „Qualitätssicherung und Qualitätskontrolle im Vergleich“
QualitätssicherungQualitätskontrolle
Beantwortete FrageSind wir auf Kurs, Qualität zu liefern?Hat das Ergebnis den Standard tatsächlich erfüllt?
ZeitpunktFortlaufend, über den gesamten LebenszyklusAn Ergebnissen und Deliverables, wenn ein Problem erkannt wird
HaltungPräventiv - Fehler verhindern, bevor sie entstehenAufdeckend und korrigierend - Fehler finden, nachdem sie passiert sind, und sie beheben
Typische AktivitätAudits, Check-ins, Stakeholder-Berichte, Tests begleitenInspektion, Rundgänge, beschädigte Artikel austauschen
VerhältnisDer breitere ÜberprüfungsprozessEine Teilmenge der QA-Aktivitäten

Halte dich an den Plan, prüfe durchgehend mit QA, korrigiere bei Bedarf mit QC - dann stehen die Chancen gut für ein hochwertiges Deliverable, das die Organisationsziele erfüllt und die Kundenerwartungen übertrifft.


Kommunikation beginnt vor dem Projekt und hört nie auf. Das Project Management Institute stellt fest, dass die meisten Projekte irgendeine Form von Kommunikationsabbruch erleiden, obwohl Projektmanager rund 90 Prozent ihrer Zeit allein mit Kommunikation verbringen. Gut gemacht, baut strategische Kommunikation mit der Kundschaft das Vertrauen auf, dass du ein verlässlicher Partner bist. Drei Soft Skills tragen sie - Verhandeln, empathisches Zuhören und Vertrauensaufbau - und alle drei ruhen auf einer Praxis: offene Fragen stellen und aktiv zuhören.

Diese Fragen legen den Ist-Zustand der Kundschaft im Vergleich zu ihrem Wunsch-Zustand offen und zeigen, was sie vom einen zum anderen bringen würde. So findest du heraus, wo du ihnen Sicherheit geben kannst, wo verhandelt werden muss, damit die Bedürfnisse beider Seiten erfüllt werden, und wie du das Vertrauen aufbaust, das eine Partnerschaft braucht.

Setze Kommunikationserwartungen aktiv, statt zu warten, bis du gefragt wirst. Wöchentliche Fortschritts-Updates zuzusagen ist besser, als zu hoffen, dass die Kundschaft mit ihren Fragen zu dir kommt. Was eskaliert wird, entscheidet dein Urteilsvermögen: Wenn eine Designerin kündigt und du sie ersetzt, ohne dass das Projekt ins Stocken gerät, gibt es keinen Grund, der Kundschaft eine zusätzliche Sorge aufzuladen. Aber wenn du ohne ihren Input wirklich nicht weiterkommst, sprich es ruhig und mit Empathie an.

Nehmen wir an, die Qualitätsstandards erlaubten einen Lieferantenfehler von zwei zerbrochenen Pflanztöpfen je 50, und eine Kundin erhält eine Lieferung mit fünf zerbrochenen. Das löst eine Verhandlung aus: Sind fünf von 50 doch akzeptabel, oder würde die Kundin in eine höhere Kategorie robusterer Pflanztöpfe investieren? Die robustere Variante belastet ihr Budget - ist sie damit einverstanden, und erzwingt das einen weiteren Trade-off? Durchgehend gilt: Ziel ist die Kundenzufriedenheit, also bleib rücksichtsvoll gegenüber ihren Gefühlen und Grenzen - verstehe den Ärger, greife ihn auf und finde eine Lösung, die für beide Seiten gut ist. Deine eigenen Erfahrungen mit gutem und schlechtem Kundenservice sind dabei ein nützlicher Kompass, denn du weißt bereits, wie sich Fürsorge auf der Empfängerseite anfühlt.

Feedback selbst kann während der Arbeit oder nach ihrem Abschluss eintreffen, je nachdem, wozu das Projekt da ist. Ein E-Commerce-Launch will frühes Feedback, damit das Einkaufserlebnis nachjustiert werden kann; ein Keks-Lieferdienst auf Abruf liefert naturgemäß erst und fragt dann, wie Kekse und Lieferung ankamen. So oder so schließt Nutzerfeedback die Lücke zwischen dem, was die Kundschaft erwartet hat, und dem, was das Projekt geliefert hat.


Der beste Weg herauszufinden, was die Kundschaft will, ist sie zu fragen - aber nicht, indem man jede Person einzeln anruft. Zwei schlanke Methoden erledigen das.

Feedback-Umfragen erfassen, welche Funktionen den Nutzenden gefallen oder missfallen, welche Teile sich intuitiv anfühlen und welche schwerer zu navigieren sind. Sie können während des Designs, vor dem Launch laufen, um zu prüfen, ob die Leute das Produkt mögen und verstehen, oder nach dem Launch, um das Erlebnis zufriedenstellender zu machen. Das Ergebnis ist eine Entscheidung: Du bist startklar, oder du gehst zurück und iterierst an einem Produkt, das bereits auf dem Markt ist.

Seine drei Ziele: zeigen, dass sich die Sache in realen Szenarien wie erwartet verhält, zeigen, dass sie wie beabsichtigt funktioniert, und Probleme sichtbar machen, die vor Projektabschluss angegangen werden können. Weil UAT reale Bedingungen simuliert, funktioniert eine Funktion, die im Test läuft, sehr viel wahrscheinlicher auch beim Launch. Er beantwortet außerdem Fragen, die sonst nichts beantwortet: Erkennen Nutzende Zweck und Einsatzmöglichkeiten, wie interagieren sie damit, wie lange dauert das, bemerken sie jede Funktion, ist sie für alle zugänglich? Und er hält fest, wie sich das Erlebnis anfühlt - welche Emotionen es hervorruft, welche Identität es vermittelt, welchen Reiz es hat.

  1. Begrüße die Nutzenden, danke ihnen für die Teilnahme und stelle dann das Produkt vor, samt Testleitlinien und einer Demonstration, wie es funktioniert.

  2. Führe die Testfälle durch und begleite das Publikum durch die kritischen User Journeys - die Abfolge von Schritten, die eine Person in deinem Produkt durchläuft, um eine Aufgabe zu erledigen.

  3. Zeige etwas Echtes. Gib den Nutzenden eine visuelle Darstellung, ein Mock-up oder eine Demo. Bei einem Bauprojekt, das alle Geräte in einem Haus ersetzt, heißt das 3D-Modelle, digitale Baupläne oder Materialproben.

  4. Konzentriere dich auf einen Call to Action. Gib ein Szenario aus dem echten Leben vor und dann eine Skalenfrage. Für eine Spülmaschine, die leise und mit wenig Kraftaufwand öffnen soll: Räume das Geschirr ein, starte den Spülgang und bewerte anschließend auf einer Skala von eins bis zehn, wie viel Kraft das Öffnen und Schließen gekostet hat.

  5. Sammle durchgehend Feedback zum Gesamterlebnis und halte Ausschau nach Edge Cases - seltenen Ausreißern an den extremen Maxima und Minima eines Parameters, die die ursprünglichen Anforderungen nie berücksichtigt haben. Eine App, die unbegrenzte Foto-Uploads erlaubt, ging davon aus, dass niemand mehr als tausend pro Sitzung hochlädt; was passiert, wenn jemand Millionen auf einmal hochlädt?

  6. Fasse die Erkenntnisse zusammen, identifiziere Bugs und Probleme, priorisiere, was zuerst angegangen wird, und schließe den Test ab, sobald die nächsten Schritte vereinbart sind.

UAT-Best-Practices und das Feedback, das zurückkommt

Abschnitt betitelt „UAT-Best-Practices und das Feedback, das zurückkommt“
PraxisWas sie bedeutet
Akzeptanzkriterien aufschreibenVorab festgelegte Standards, die jedes Element erfüllen muss - für ein neues Mitarbeiterhandbuch etwa, dass es ein digitales PDF ist, das auf Mobilgerät und Desktop lesbar ist
Testfälle erstellenEine Abfolge von Schritten plus erwartete Ergebnisse, etwa dieses PDF auf dem Handy herunterzuladen und zu bestätigen, dass es sauber öffnet
Nutzende sorgfältig auswählenSie müssen die echten Endnutzenden des Produkts, der Dienstleistung oder des Prozesses sein
Skripte aus User Storys schreibenEine User Story beschreibt eine Funktion informell aus Sicht der Endnutzenden: als neue Mitarbeiterin möchte ich die Urlaubsregelung finden und sie meinem Team per E-Mail schicken
Nutzenden sagen, was sie erwartetWer vorab vorbereitet wird, sorgt am Testtag für weniger Fragen, Probleme und Verzögerungen
Die Umgebung vorbereitenZugangsdaten und Zugriffe vor der Sitzung prüfen, nicht währenddessen
Einen Schritt-für-Schritt-Plan gebenKlare Anweisungen in einem geteilten Dokument oder einer Tabelle lenken die Aufmerksamkeit auf die richtigen Stellen
Notizen an einem Ort bündelnEin Dokument, das jedes Problem festhält, einschließlich der von den Nutzenden eingeschätzten Schwere, was die Priorisierung steuert
Bugs und Probleme triagierenVerfolgen und priorisieren: Kritische Probleme (das Handbuch lässt sich nicht öffnen, herunterladen oder durchsuchen) gehen kosmetischen vor (Meinungen zum Titelbild)
Änderungsanträge managenMeist kleinere Vorschläge, trotzdem priorisiert. Je nach Art und Menge teilst du die Daten mit den zentralen Stakeholdern und rechnest damit, den Zeitplan anzupassen

Feedback zu sammeln ist nur dann fair, wenn alle teilnehmen können - baue Barrierefreiheit also in die Art ein, wie du Qualität misst.

  • Live-Interviews: biete Vorkehrungen bereits in der Einladung an. Es kann sein, dass Live-Untertitelung oder eine Dolmetscherin gewünscht wird; wer mit Angst lebt oder im Autismus-Spektrum ist, möchte die Fragen vielleicht vorab. Was der einen Person passt, passt einer anderen womöglich nicht, selbst bei derselben Behinderung.
  • Vor Ort: prüfe den Veranstaltungsort mit dem Blick auf Barrierefreiheit - ein barrierefreier Weg ins Gebäude und in den Raum sowie Flure ohne Gerümpel, das einen Rollstuhl, einen Rollator oder eine Person mit Sehbehinderung blockieren würde.
  • Umfragen und Tools: vergewissere dich, dass das System barrierefrei ist. Bist du unsicher, frage die verantwortliche Stelle, ob es den aktuellen Web Content Accessibility Guidelines (WCAG) entspricht, und sei bereit, Fragen auch auf anderem Weg zu verschicken und Antworten entgegenzunehmen.
  • Das Produkt und das Team: sprich Barrierefreiheit von Anfang an an, denn sie in die letzten Phasen zu schieben führt zu Launch-Verzögerungen oder zu einem Produkt, das ein Teil der Bevölkerung nicht nutzen kann. Sorge dafür, dass die Entwickelnden die Anforderungen von Beginn an kennen, bring sie sonst mit Fachleuten zusammen, und beziehe Testende mit unterschiedlichen Behinderungen in die Usability-Tests ein - teste mindestens gegen die Leitlinien.

Kundschaft und Sponsoren sind unterschiedliche Zielgruppen

Abschnitt betitelt „Kundschaft und Sponsoren sind unterschiedliche Zielgruppen“

Kundschaft ist eine Art von Stakeholdern, und es hilft, Stakeholder in Kategorien zu sortieren. Kundschaft sind meist die Endnutzenden oder die Käuferinnen und Käufer eines Produkts. Sponsoren finanzieren das Team, das es baut, und ihnen geht es um den Return on Investment, also beziffere den Ertrag, den du erzeugst, immer wieder. Zu verstehen, was eine Kundin braucht, ist wirklich schwer, und es ist eine Fähigkeit, die über die Zeit wächst - sie beruht auf Empathie, darauf, sich in ihre Lage zu versetzen und das Produkt mit ihren Augen zu sehen.


Kontinuierliche Verbesserung und Prozessverbesserung

Abschnitt betitelt „Kontinuierliche Verbesserung und Prozessverbesserung“

Kontinuierliche Verbesserung beginnt damit zu erkennen, wann Prozesse und Aufgaben geschaffen, abgeschafft oder verbessert werden müssen; der Projektmanager plant und setzt die Veränderung dann um, damit das Projekt auf Kurs bleibt. In der Praxis unterscheiden sich die beiden Ideen im Wesen: Prozessverbesserung ist die konkrete Handlung, Daten anzuschauen, um etwas wirksamer oder kosteneffizienter zu machen, und sei es etwas so Kleines wie die Art, wie Meeting-Notizen erstellt und verteilt werden - kontinuierliche Verbesserung dagegen ist eine Haltung, besser werden zu wollen, selbst wenn das Produkt bereits gut aussieht. Sobald etwas draußen in der Welt ist, nutzen Menschen es auf Arten, die niemand vorhergesehen hat, also legt man das Ego ab und löst weiter, was die echte Nutzung zutage fördert.

Ein Problem im Prozess beobachten
Eine Hypothese bilden - eine fundierte Vermutung zu Ursache und Lösung
Eine Variable ändern, die Kontrollgruppe gleich lassen
Ergebnisse erneut beobachten, bestätigen oder etwas anderes probieren
Ändere immer genau eine Sache auf einmal, sonst weißt du nicht, welche Änderung das Ergebnis erzeugt hat.

Durchgerechnetes Beispiel. Die Nachfrage bei Plant Pals boomt, und die Lieferanten haben das Verpacken auf eine einzige Kartongröße für alles vereinheitlicht. Kleine Pflanzen bekommen zusätzliche Polsterung und kommen unversehrt an; große Pflanzen werden hineingequetscht und kommen laut Kundenumfragen manchmal beschädigt an. Die Hypothese: Kämen mehr große Pflanzen unversehrt an, wenn sie in größeren Kartons mit der Polsterung der kleinen verschickt würden? Also wird die Hälfte der großen Pflanzen weiterhin in den ursprünglichen Kartons verschickt, die Kontrollgruppe, und die andere Hälfte in größeren Kartons, bei identischer Form, Dicke, identischem Kartonlieferanten und identischen Lieferadressen. Eine neue Umfrage nach der Lieferung bestätigt entweder die Hypothese oder schickt dich auf die Suche nach einer anderen Ursache.

Kontrollierte Experimente sind nicht der einzige Weg. Das Modul nennt zwei datengetriebene Verbesserungs-Frameworks, DMAIC und PDCA, und ausgearbeitet wird PDCA.

Plan
→
Do
→
Check
→
Act
PDCA bei Office Green: Der Absatz einer Pflanzensorte bricht ein, also platzierst du diese Art mit einem kleinen Rabatt ganz oben auf der Website, prüfst die Wirkung und handelst nach dem, was du findest.

Die Änderung funktionierte gut genug, um zur Best Practice zu werden: Von da an werden schwach laufende und überbevorratete Sorten oben auf der Website platziert. Aus einer einmaligen Lösung ist ein wiederholbarer Prozess geworden, und ihn immer wieder auszuführen ist genau das, was kontinuierliche Verbesserung antreibt.


Verbesserungen bleiben nicht in einem einzigen Projekt, denn ein Projektmanager sitzt in einem größeren Ökosystem.

Projektein einzelnes, fokussiertes Vorhaben, kurzfristig und temporär
Programmeine Sammlung von Projekten
PortfolioProjekte und Programme über die gesamte Organisation hinweg
Projekte können in Programmen stecken, die wiederum in Portfolios stecken können - aber Projekte können auch für sich stehen, als separate, unabhängige Initiativen.
RolleVerantwortetHorizont
ProjektmanagerEinzelne ProjekteKurzfristige, konkrete Deliverables
ProgrammmanagerGruppen von Projekten, und oft weitere ProjektmanagerLangfristige Geschäftsziele
PortfoliomanagerEine Gruppierung von Projekten und Programmen, zentral gesteuertOrganisationsweit

Jede Rolle hat den Auftrag, kontinuierlich zu verbessern, was sie verantwortet, und Verbesserungen wandern nach oben. Ein Projektmanager startet monatliche abteilungsübergreifende Schulungen, damit ein kleines Team immer eine Vertretung hat, wenn jemand ausfällt; nach ein paar Monaten stellt sich heraus, dass sie die Kommunikation verbessert und nebenbei als Teambuilding gewirkt haben. Zur Programmmanagerin getragen, lässt sich das über jedes Projekt im Programm ausrollen.

Office Green zeigt dieselbe Eskalation. Plant Pals zu launchen ist ein Projekt und endet mit dem Launch; den Service unbefristet weiterzubetreiben macht daraus ein Programm, eines der langfristigen Ziele des Unternehmens; Plant Pals plus die übrigen Projekte und Programme bilden das Portfolio. Eine in einem Projekt bewährte Verbesserung kann also unternehmensweit über andere Standorte und Produkte ausgerollt werden, was Verschwendung senkt und den Umsatz hebt, und wenn sie sich über Programme hinweg verbreitet, gewinnt das Portfolio stärkere Rentabilitätskennzahlen.


Retros sollten über den gesamten Lebenszyklus stattfinden, auch wenn sie am häufigsten nach großen Milestones und, am allerhäufigsten, nach Projektabschluss abgehalten werden. Selbst wenn jedes Risiko eingeplant ist, wird sich etwas anschleichen, und genau das ist der Moment, mit dem Team zu reflektieren und Erkenntnisse festzuhalten, die andere Menschen in ihren eigenen Projekten nutzen können.

Verpasste Fristen oder ErwartungenMissverständnisse zwischen StakeholdernEnde eines Sprints (eine Reihe geordneter Aufgaben, die auf ein Ziel zuläuft)Nach Produkt-Launches und LandungenImmer wenn etwas durchgerutscht ist
  • Teambuilding - die Mitglieder lernen die Perspektiven der anderen zu verstehen, und genau das macht bessere Zusammenarbeit möglich.
  • Bessere Zusammenarbeit in künftigen Projekten - mehr gegenseitiges Verständnis hebt beim nächsten Mal die Produktivität.
  • Positive Veränderung künftiger Verfahren und Prozesse - der Fokus liegt auf Verbesserung statt auf dem Recyceln alter, womöglich schlechter Gewohnheiten.

Es gibt keine exakte Formel und kein festes Template; wie du eine Retro strukturierst, hängt von deinem Team und deinem Arbeitsumfeld ab. Eine formelle Sitzung vor Ort passt zu Teams, die gern gemeinsam debriefen, mit Haftnotizen, Dokumenten oder anderen greifbaren Hilfsmitteln. Wenn Präsenzmeetings dazu neigen abzuschweifen, funktioniert eine virtuelle oder Online-Retro besser, mit Umfragen, um die Gedanken vorab zu ordnen.

Die mit Abstand wichtigste Praxis ist, dass Retros schuldfrei sind. Die Leute müssen das Gefühl haben, so offen wie möglich Feedback geben zu können, sonst bringt die Übung nichts, und anonyme oder private Kanäle helfen bei unangenehmen oder heiklen Themen. Zwei Taktiken halten den Ton richtig:

TaktikWie das aussieht
Perspektive wechselnBevor du das Lieferunternehmen für verspätete Pflanzen verantwortlich machst, betrachte es von seiner Seite. War die Route optimiert und gegen den Verkehr getestet? Wenn nicht, hätte das vermutlich eine Aufgabe in deinem Projekt sein sollen
Statt du-Sprache wir-Sprache verwendenNicht du hast nie klargemacht, dass wir kein Notfallbudget hatten, was dem Sponsor das Gefühl gibt, beurteilt zu werden, und ihn fragen lässt, warum der Projektmanager früher nicht besser nachgefragt hat. Stattdessen: dass ein Notfallbudget fehlt, wurde von Anfang an nicht deutlich gemacht, und das können wir beim nächsten Mal besser machen

Oft lautet die ehrliche Antwort, dass beide Seiten ein bisschen mehr hätten tun können, und das ist völlig in Ordnung.


Kläre zwei Dinge, bevor du beginnst. Halte durchgehend einen positiven Ton, denn selbst die harten Gespräche existieren, um dich auf künftige Projekte vorzubereiten. Und denke an Teams außerhalb des eigenen: Partnerteams sollten einbezogen werden, denn teamübergreifende Kommunikation und die Übergabe von Deliverables gehören zu den häufigsten Retro-Themen. Sagen sie ab, teile die Erkenntnisse trotzdem mit ihnen.

Ein Standard-Template für Retrospektiven gibt dem Projektmanager ein Dokument an die Hand, das er ausfüllt und mit dem er das Gespräch führt. Arbeite es in dieser Reihenfolge durch und gehe die Ereigniskette genau so ab, wie sie in Echtzeit passiert ist.

Ereigniskette
  • Was passiert ist, in Echtzeit-Reihenfolge
  • Planungsphase, dann Durchführung
  • Was hätte besser laufen können, und wo hatten wir Glück?
Erkenntnisse
  • Was beim nächsten Mal anders zu machen ist
  • Welche Risiken eingetreten sind
  • Lücke zwischen Plan und Durchführung, und wie sich das Team gefühlt hat
Action Items
  • Was sollten wir daraufhin tun?
  • Typ: Tool, Prozess, Team, Sonstiges. Owner: wer es verantwortet
  • Links: wo das Item verfolgt wird
Künftige Überlegungen
  • Risiken, die im nächsten Quartal zu Problemen werden könnten
  • Zu übergebende Verantwortung, plus Typ
  • Kontaktperson, die als Ressource dienen kann, und relevante Links

Rechne im Abschnitt zu den Erkenntnissen mit schwierigem Feedback und halte es aus. Wenn der Website-Launch seine Frist verpasst hat, hat das Vertriebsteam in dem Monat seine Zahlen verfehlt, das Marketing musste Inhalte und Anzeigen umdatieren, und der Sponsor musste sich vor Investoren verantworten, die auf die Seite warteten. Aus Sicht des Teams ist die Zeit zuerst in weniger wichtige Aufgaben geflossen. Die Erkenntnis ist konkret: Beim nächsten Mal die Aufgabe priorisieren, an der so viele Abhängigkeiten hängen.

Retros werden meist als Ritual zum Projektende gerahmt, funktionieren aber besser als fortlaufende Übung, immer wieder zu prüfen, wie es dem Projekt geht. Ein Beispiel: Mitten im Launch von etwas auf Google Search merkte ein Team, dass es einen besseren Ansatz mit weit größerem Nutzen für die Nutzenden gab, holte deshalb das gesamte Projektteam zusammen, arbeitete durch, was bisher getan worden war, den aktuellen Stand, die Optionen nach vorn und die Schwächen, die niemand bemerkt hatte, und plante dann gemeinsam den Rest des Projekts um eine angepasste Definition von Erfolg herum neu.



Weiter: Datengestützte Entscheidungen → - mit Daten das Projekt steuern und seine Geschichte erzählen.