Capstone 3 - Qualität und Evaluation
Google Project Management Certificate · Kurs 6: Projektmanagement in der Praxis anwenden
Die Wochen 1 und 2 haben die beiden Dokumente hervorgebracht, die das Tablet-Pilotprojekt von Sauce and Spoon definieren: eine Charter mit SMART-Zielen und einen Projektplan mit Aufgaben, Meilensteinen und Zeitschätzungen. Woche 3 setzt sie in die Tat um. Die Tablets sind an den Standorten Downtown und North an das Point-of-Sale-System angeschlossen, das Personal ist geschult, und 50 Gäste aus dem Freundes- und Familienkreis haben eine Mahlzeit gegessen und dabei über ein Tablet bestellt und bezahlt. Die Frage dieser Woche lautet nicht mehr, was wir bauen werden, sondern ob das, was wir gebaut haben, tatsächlich funktioniert hat.
Kurs 4 hat Quality Management und Retrospektiven bereits als Konzepte vermittelt. Diese Woche ist bewusst dünn an neuer Theorie und dicht an Anwendung: Sie wiederholt das Vokabular in ein paar Minuten und begleitet dann im Rest des Moduls einen einzigen echten Test Launch durch die gesamte Evaluationskette. Quality Standards werden zu Evaluation Questions, Evaluation Questions werden zu Indicators, Indicators werden zu Survey-Fragen, Survey-Antworten werden zu Erkenntnissen, und Erkenntnisse werden zu Empfehlungen, auf die ein Stakeholder reagieren kann. Die Kette zählt mehr als jedes einzelne Glied, denn eine Survey-Frage, die ohne dahinterliegende Evaluation Question geschrieben wurde, erzeugt Daten, mit denen niemand etwas anfangen kann.
Das Modul endet mit einer Retrospektive, und genau dort steuert der Capstone am meisten bei. Kurs 4 sagte, Retrospektiven sollten ohne Schuldzuweisung und beteiligend sein. Diese Woche zeigt, was konkret zu tun ist, wenn der Raum still bleibt, wenn das Team dem Lieferanten die Schuld gibt oder wenn eine Person das Meeting vergiftet.
Der Übergang in die Umsetzung
Abschnitt betitelt „Der Übergang in die Umsetzung“In der Umsetzung wird der Plan in die Tat umgesetzt, und die Lektüre zu dieser Phase, zusammengetragen aus Dutzenden Google-Projektmanagerinnen und -Projektmanagern, gibt dafür vier Hinweise.
Frag die Menschen, wie sie kommunizieren möchten
Abschnitt betitelt „Frag die Menschen, wie sie kommunizieren möchten“Fortschritt muss beständig und stimmig kommuniziert werden, damit alle den aktuellen Stand kennen, wissen, worauf sie sich konzentrieren sollen, und was als Nächstes passiert. Statt zu raten, frag jeden Stakeholder und jedes Teammitglied nach der eigenen Vorliebe:
Woher Quality Standards kommen
Abschnitt betitelt „Woher Quality Standards kommen“Die Lektüre nennt drei Quellen, dieselben drei, die auch die Videos nutzen:
- Projektdokumente wie der Business Case und die Project Charter, die Ziele, Scope, Budget und die Details bereits benennen, die das Projekt für die Stakeholder akzeptabel machen.
- Gespräche mit Fachleuten und Stakeholdern, besonders mit denen, die das Projekt finanzieren, um deren eigene Sicht auf Qualität zu verstehen.
- Online-Recherche zu Branchenstandards.
Quality Assurance in dieser Phase
Abschnitt betitelt „Quality Assurance in dieser Phase“Plane regelmäßige Quality-Assurance-Audits ein, um zu bestätigen, dass die Arbeit planmäßig läuft und die richtigen Verfahren eingehalten werden. Regelmäßige Check-ins und Berichte an die Stakeholder stärken deren Vertrauen und deines.
Phased Launches
Abschnitt betitelt „Phased Launches“Ein Phased Launch bringt einen Teil des Projekts vor echte Nutzende, bevor das Endziel erreicht ist, um Daten und Feedback zu sammeln, die das Endergebnis verbessern. Die Lektüre stellt zwei Arten gegenüber, vor dem Launch zu launchen:
| Minimum viable product (MVP) | Beta | |
|---|---|---|
| Was es ist | Die absolute Mindestversion, die ein Kundenproblem trotzdem löst | Ein echtes Produkt, kein Experiment, mit weniger Funktionen als der vollständige Launch |
| Zweck | Die Idee validieren, indem mit dem geringsten Aufwand die meisten Kundendaten gesammelt werden | Herausfinden, welche Funktionen ergänzt werden sollen |
| Frage, die es beantwortet | Wollen die Menschen das? | Wie können wir es besser bauen? |
Der Test Launch von Sauce and Spoon ist ein Phased Launch dieser Art: die Barbereiche zweier Standorte, 50 eingeladene Gäste, ein Service.
Waterfall oder Agile wählen
Abschnitt betitelt „Waterfall oder Agile wählen“Die Lektüre schließt mit einer Wiederholung der Ansatzwahl, denn der Umsetzungsstil folgt aus ihr.
- Phasen sind klar definiert und laufen nacheinander ab, eine nach der anderen
- Manche Aufgaben müssen abgeschlossen sein, bevor andere beginnen können
- Änderungen sind sehr teuer, sobald das Projekt begonnen hat
- Kundenfeedback kommt schneller als bei einem traditionellen Ansatz
- Arbeitsprozesse werden verschlankt, ohne Qualität oder Wert zu beschneiden
- Verschwendung wird vorausschauend verringert und Ressourcen werden geschont
- Das Team kann schnell auf veränderte geschäftliche oder technische Faktoren reagieren
- Vertrauen, Unterstützung und Motivation wachsen, und Entscheidungen werden ins Team hinein verlagert
Es folgt ein kurzes Scrum-Glossar zum Nachschlagen: Product Backlog, Sprint, Daily Scrum, Development Team, Product Owner und Scrum Master, alle so definiert wie in Kurs 5.
Warum Qualität zählt
Abschnitt betitelt „Warum Qualität zählt“Qualität wird in dieser Woche zweimal definiert, einmal in den Videos und einmal in der Lektüre, und die beiden Definitionen stimmen überein. Qualität bedeutet, zu liefern, was du zugesagt hast, es so effizient wie möglich zu tun und die Bedürfnisse und Erwartungen der Kundschaft zu erfüllen oder zu übertreffen. Pünktlich und unter Budget fertig zu werden ist nicht dasselbe: Ein Projekt kann termingerecht landen und trotzdem an seinen Stakeholdern scheitern.
Deshalb wird Qualität über den gesamten Lebenszyklus verfolgt, statt am Ende geprüft zu werden. Ein Projekt lässt sich nicht einfach in der Annahme launchen, dass schon alles gut gehen wird.
Die drei Vorteile
Abschnitt betitelt „Die drei Vorteile“Das Vokabular in einem Durchgang
Abschnitt betitelt „Das Vokabular in einem Durchgang“| Begriff | Was er bedeutet |
|---|---|
| Quality Planning | Der Prozess, den die Projektleitung oder das Team aufsetzt und befolgt, um genau zu bestimmen, welche Quality Standards für das Projekt als Ganzes relevant sind und wie sie erfüllt werden |
| Quality Standards (Qualitätsstandards) | Die Anforderungen, Spezifikationen oder Leitlinien, mit denen sichergestellt wird, dass Materialien, Produkte, Prozesse und Services geeignet sind, das gewünschte Ergebnis zu erreichen |
| Quality Assurance (QA) | Ein Prüfprozess, der bewertet, ob sich das Projekt in Richtung eines hochwertigen Service oder Produkts bewegt |
| Quality Control (QC) | Die Techniken, mit denen Quality Standards gehalten werden, sobald ein Problem erkannt wurde |
| Quality Management Plan | Das übergreifende Dokument, das alles enthält, was zum Managen von Qualität über den Lebenszyklus nötig ist: die Richtlinien, Prozesse und Kriterien für Projektqualität sowie die Rollen und Verantwortlichkeiten für deren Umsetzung |
Zwei Einordnungen lohnen sich zu merken, weil die Woche sie als Scharniere nutzt. Surveys sind eine Form von Quality Assurance, neben Beta-Tests und internen Checklisten. Retrospektiven sind eine Form von Quality Control, weil sie Prozesse anpassen und verbessern, sobald etwas als fehlerhaft erkannt wurde.
Für Sauce and Spoon wird der Quality Management Plan aus drei Dingen gebaut: Quality Standards, Evaluation Questions und Feedback-Surveys.
Messbare Quality Standards definieren
Abschnitt betitelt „Messbare Quality Standards definieren“Qualität wird gemessen, indem für die einzelnen Teile eines Projekts Standards gesetzt werden: große Aufgaben, Meilensteine und Deliverables. Wenn ein Teil seinen vereinbarten Standard verfehlt, ist das das Signal, den Projektplan anzupassen.
Das Video arbeitet die Idee am Deliverable Personalschulung durch. Woran würdest du erkennen, dass die Schulung erfolgreich erfüllt wurde? Die Fragen, die zu dieser Antwort führen, sind der Anfang der Standardliste:
- Was muss das Personal am Ende der Schulung können oder zeigen können?
- Braucht jede Personalgruppe eine Schulung zu denselben Themen?
- Wird das Management andere Anforderungen haben als Front of House und Back of House?
- Muss die Schulung in einen bestimmten Zeitrahmen, ein Budget oder einen geografischen Rahmen passen, um als erfolgreich zu gelten?
In den meisten Branchen gibt es etablierte Kategorien, und sie sind ein nützlicher Anstoß: Funktionalität, Design und Sicherheit (die Beispiele, die für Software und Bauwesen genannt werden), dazu Benutzerfreundlichkeit, Produktivität, Wirksamkeit und Kundenzufriedenheit.
Objektiv und messbar, sonst ist es kein Standard
Abschnitt betitelt „Objektiv und messbar, sonst ist es kein Standard“Das ist der Punkt, auf dem die Woche herumreitet. Stakeholder neigen dazu, eine Kategorie zu nennen statt einer Zahl. Wenn jemand sagt, die Tablets sollten leicht zu bedienen sein, ist es die Aufgabe der Projektleitung zu fragen, was ein Anzeichen dafür wäre. Die Antworten werden zu Standards: Eine Bestellung soll nicht länger als 20 Sekunden dauern, oder wiederkehrende Gäste berichten, dass das Tablet schneller ist als die Bestellung bei der Bedienung.
Die Anstoßfragen, die das Video vorschlägt:
| Wenn der Standard sich dreht um | Frag |
|---|---|
| Produktivität und Wirksamkeit | Sollen die Tablets verändern, wie das Front-of-House-Personal arbeitet? Werden sie dadurch schneller, oder können sie mehr Tische gleichzeitig bedienen? |
| Kundenzufriedenheit | Wie sollten die Tablets im Idealfall das Erlebnis der Gäste verändern? Was sollten Gäste als Folge der Nutzung tun oder sagen? |
Selbst mit Dokumenten, Fachleuten und Recherche als Grundlage braucht es weiterhin kritisches Denken, um die richtigen Standards auszuwählen und sie an das Projekt anzupassen.
Das wöchentliche Check-in: aus einem Wunsch werden Kriterien
Abschnitt betitelt „Das wöchentliche Check-in: aus einem Wunsch werden Kriterien“Das durchgearbeitete Beispiel ist ein Check-in zwischen Peta, der Projektleiterin, und Deanna, der Director of Operations, die Omar erklären möchte, wie das Projekt das Bekenntnis des Unternehmens zur Kundenzufriedenheit einlösen wird. Deanna beginnt mit einer Annahme statt mit einem Standard: Da Verzögerungen im Service negative Bewertungen erzeugt haben, wären Gäste mit einem schnelleren, effizienteren Erlebnis und mit korrekt aufgenommenen Bestellungen zufrieden. Peta nimmt die Richtung an und fragt sofort, wie jede der beiden Hälften gemessen würde. Das Gespräch besteht im Kern aus fünf Runden derselben Frage.
-
Wie messen wir ein schnelleres Erlebnis? Deanna schlägt die durchschnittliche Ticket Time vor, den Abstand zwischen der Aufgabe einer Bestellung und ihrer Ankunft am Tisch. Aus ihrer Erfahrung ist ein guter Durchschnitt 8 Minuten für Vorspeisen und 12 bis 15 Minuten für Hauptgerichte. Das knüpft an das bestehende Ziel an, die durchschnittliche Tischumschlagzeit um 30 Minuten zu senken.
-
Was gilt noch als schneller? Peta merkt an, dass Gäste ihre Karte nun am Tisch nutzen können, also kommt der Checkout infrage. Deanna möchte, dass er den Checkout beim Online-Lieferdienst abbildet, den die Gäste bereits mögen. Das Kriterium wird eine Checkout-Zeit von einer Minute oder weniger, wobei der Ablauf nahtlos und leicht zu bedienen sein soll.
-
Was würde all das zunichtemachen? Tablets, die nicht funktionieren. Peta holt einen Standard direkt aus der Charter: unter 5 Prozent der Tablet-Nutzenden melden pro Woche technische Probleme.
-
Und falsche Bestellungen? Peta schlägt 98 Prozent Bestellgenauigkeit vor, mit der Begründung, dass Gäste, die selbst bestellen, das Ticket bestätigen können, bevor es in die Küche geht, sodass die Genauigkeit steigen sollte, sobald die Hardware mitspielt.
-
Noch etwas, bevor Omar es sieht? Deanna ergänzt eine durchschnittliche Wartezeit in der Lobby von zehn Minuten oder weniger, bevor Gäste platziert werden, was Peta annimmt, weil die Wartezeiten mit der Tischumschlagzeit sinken sollten und die konkrete Wirkung damit messenswert ist.
Die Standards für Kundenzufriedenheit
Abschnitt betitelt „Die Standards für Kundenzufriedenheit“| Standard | Messgröße |
|---|---|
| Schnellerer Service | Durchschnittliche Ticket Time von 8 Minuten für Vorspeisen, 12 bis 15 Minuten für Hauptgerichte |
| Schneller Checkout | Eine Minute oder weniger, und leicht zu bedienen |
| Zuverlässige Tablets | Unter 5 Prozent der Tablet-Nutzenden melden pro Woche ein technisches Problem |
| Bestellgenauigkeit | 98 Prozent der Bestellungen werden korrekt geliefert |
| Kürzere Wartezeit in der Lobby | Durchschnittlich zehn Minuten oder weniger von der Tür bis zum Platz |
Deanna schließt mit der Bitte, die übrigen Standards des Projekts bis zum nächsten Check-in vorzulegen, was das Signal ist, dass Kundenzufriedenheit nur ein Deliverable aus einer sehr viel längeren Liste ist.
Aktivität: Quality Standards
Abschnitt betitelt „Aktivität: Quality Standards“In der ersten Aktivität sollte ich die Projektdokumentation und dieses Check-in-Transkript lesen und die Standards zur Kundenzufriedenheit im Quality Management Plan zusammenführen. Die Struktur ist schlicht ein benannter Aspekt des Projekts mit seiner Liste objektiver, messbarer Kriterien darunter, also die fünfzeilige Tabelle oben. Der bewertete Prüfpunkt ist, ob jedes Kriterium eine Zahl oder einen Schwellenwert trägt statt eines Adjektivs.
Evaluation Questions
Abschnitt betitelt „Evaluation Questions“Mit installierten Tablets, der Integration ins Point-of-Sale-System und geschultem Personal erreicht das Projekt seinen Testmeilenstein, und die Standards müssen gemessen werden. Diese Messung ist die Evaluation.
Evaluation ist eine Form von Forschung, die Lernen fördern und Entscheidungen stützen soll. Sie sorgt außerdem für Rechenschaft und zeigt, wie weit das Projekt seine Ziele erreicht hat. Die drei Dinge, die sie ermöglicht:
Sie fängt auch unbeabsichtigte Probleme ab, die das Projekt selbst für die Organisation, das Team oder andere erzeugt. Das genannte Beispiel: Werden Tablets installiert, während das Restaurant geöffnet ist, ruiniert die Installation selbst das Gasterlebnis, weshalb auch der Zeitpunkt der Installation eine Frage der Evaluation ist.
Beginn mit dem Warum
Abschnitt betitelt „Beginn mit dem Warum“Bevor du Fragen schreibst, formuliere, warum du evaluierst, denn das Warum prägt die Fragen. Grenze es ein, indem du die Projektziele und die Unternehmensziele durchgehst und fragst, wie der zu evaluierende Aspekt mit ihnen zusammenhängt. Petas Warum an diesem Meilenstein ist es, Qualität und Leistung der Tablets zu beurteilen und Wege zur Verbesserung des Schulungsprozesses zu finden, weil ihre Evaluation die späteren Phasen mitbestimmt, einschließlich des Rollouts an zwei weiteren Standorten.
Zwei Kategorien von Fragen
Abschnitt betitelt „Zwei Kategorien von Fragen“| Fragen, die beim Verbessern helfen | Fragen, die messen und vergleichen |
|---|---|
| Wie können wir uns verbessern? | Was waren die Ergebnisse? |
| Was funktioniert und was funktioniert nicht? | Gab es unbeabsichtigte Folgen? |
| Welche Ziele werden erreicht? | Was waren Kosten und Nutzen? |
| Wer profitiert? | Gibt es Lehren daraus zu ziehen? |
| Was sind die häufigsten Reaktionen der Teilnehmenden? | Sollten wir weitermachen? |
Die zweite Kategorie nutzt du, um zu beurteilen, ob mit dem Prozess oder mit dem Projekt selbst weitergemacht wird. Die Beispielfrage, die durch den Rest des Moduls getragen wird, lautet: In welchem Maß verbessern Tablets die Arbeitsleistung des Personals?
Was eine Evaluation Question wirksam macht
Abschnitt betitelt „Was eine Evaluation Question wirksam macht“- Sie greift Werte, Interessen und Anliegen von Stakeholdern oder Nutzenden auf.
- Sie hängt mit dem Zweck des Projekts und dem Zweck der Evaluation zusammen.
- Sie ist es wert, beantwortet zu werden, und ist wichtig für das Projekt und darüber hinaus.
- Sie ist mit den vorhandenen Ressourcen praktisch und machbar zu beantworten.
Aktivität: Evaluation Questions
Abschnitt betitelt „Aktivität: Evaluation Questions“Die zweite Aktivität hat dem Quality Management Plan Evaluation Questions hinzugefügt, eine oder mehrere je Quality Standard. Die Struktur des Plans gewinnt eine Spalte: der evaluierte Aspekt, der Standard und die Evaluation Question, die ihn prüft. Die fertige Fassung ordnet jedem der fünf Kriterien zur Kundenzufriedenheit eine Frage vom Typ Verbessern oder vom Typ Messen und Vergleichen zu und behält die vier Wirksamkeitskriterien von oben als Selbstprüfung.
Evaluation Indicators
Abschnitt betitelt „Evaluation Indicators“Eine Evaluation Question allein sagt dir nicht, was du erheben sollst. Der Indicator tut das.
Das Verhältnis spiegelt das zwischen Standards und Deliverables. Ein Quality Standard macht ein Deliverable konkreter; ein Indicator macht eine Evaluation Question konkreter, indem er die Art der angestrebten Antwort festlegt. Das Wort indizieren heißt anzeigen oder hinweisen, und genau das ist die Aufgabe: Indicators weisen den Weg zur Antwort.
Indicators können auch sichtbare Anzeichen statt Zahlen sein: Testergebnisse, Anwesenheitsquoten, beobachtetes Verhalten. Die Beispiele des Videos für das Tablet-Pilotprojekt sind pointiert. Weniger Personal, das sich an der Getränkestation versammelt oder zu spät kommt, zeigt gestiegene Produktivität an. Über 90 Prozent Einhaltung des Tablet-Bestellprozesses durch das Personal zeigt Genauigkeit bei der Bestellaufnahme an.
Aktivität: Evaluation Indicators
Abschnitt betitelt „Aktivität: Evaluation Indicators“Die dritte Aktivität hat jeder Evaluation Question im Quality Management Plan einen Indicator hinzugefügt. Die Spalte der Vorlage fragt schlicht, welche Daten die Antwort zeigen würden, sodass die fertigen Zeilen sich als Frage lesen und dann als das zählbare oder beobachtbare Ding, das sie beantwortet. Der Test ist, ob der Indicator etwas benennt, das ein Survey oder ein Betriebsbericht tatsächlich hervorbringen könnte.
Surveys
Abschnitt betitelt „Surveys“Surveys sind eine von mehreren Methoden der Datenerhebung und im Projektmanagement eine beliebte. Jede befragte Person beantwortet eine Reihe klar definierter Fragen, und die gesammelten Daten werden ausgewertet, um konkrete Beispiele für die Indicators zu liefern. Peta hat Surveys bei der Kundschaft als Weg gewählt, die Evaluation Questions dieses Projekts zu beantworten.
Survey-Frage oder Evaluation Question
Abschnitt betitelt „Survey-Frage oder Evaluation Question“Die Unterscheidung verschwimmt leicht, und die Woche ist da streng.
| Evaluation Question | Survey-Frage | |
|---|---|---|
| Fragt nach | Den Ergebnissen, der Wirkung oder der Wirksamkeit des Projekts | Einem einzelnen konkreten Datenpunkt |
| Publikum | Die Projektleitung und die Stakeholder, intern | Die befragte Person |
| Verhältnis | Das, was du wissen willst | Eine direktere Übersetzung davon, gebaut, um Daten zu erhalten |
Durchgearbeitet: Die Evaluation Question fragt, in welchem Maß Tablets die Arbeitsleistung steigern. Ein Indicator ist, wie viel Nebenarbeit das Personal während einer Schicht erledigt. Die zugehörigen Survey-Fragen werden dann: Sind die Tablets leicht zu bedienen; gab es in der Schulung genug Zeit zum Üben und Nachfragen; wie viele Nebenarbeiten kannst du im Durchschnitt während einer Schicht erledigen; wie oft hast du seit der Nutzung der Tablets eine falsche Bestellung zurückgehen lassen.
Fragetypen
Abschnitt betitelt „Fragetypen“Eine Scaled-Frage unterscheidet sich von Multiple Choice, weil die Optionen eine Skala bilden statt einer Liste von Alternativen.
Fragen schreiben, die funktionieren
Abschnitt betitelt „Fragen schreiben, die funktionieren“- Frag, was du fragen willst. Jede Frage sollte konkret sein und nur einen messbaren Aspekt betreffen.
- Nimm nichts über die Befragten an. Nicht alle wissen oder mögen dasselbe oder haben ähnliche Lebenserfahrungen gemacht, deshalb müssen die Antwortoptionen es den Menschen erlauben, zutreffend über ihr eigenes Erleben zu antworten.
- Erkläre nicht zu viel. Zu viele Details in der Frage lenken die befragte Person in Richtung einer bestimmten Antwort und erzeugen still und leise Verzerrung.
Der Entwicklungsprozess in der richtigen Reihenfolge: die Evaluation Questions entwickeln, die Indicators definieren, dann entscheiden, welche Art von Survey gestaltet wird und welche Fragen gestellt werden.
Aktivität: Survey-Fragen
Abschnitt betitelt „Aktivität: Survey-Fragen“Die vierte Aktivität nahm eine Evaluation Question von Sauce and Spoon und schrieb die Survey-Fragen, die sie beantworten würden, und ergänzte sie im Quality Management Plan. Die Vorlage gibt die Evaluation Question und ihren Indicator vor und lässt die Survey-Fragen leer; die fertige Fassung hat eine Mischung von Fragetypen, mit mindestens einer Scaled-Frage, damit sich das Ergebnis als Prozentsatz verfolgen lässt, und einer offenen Anschlussfrage, damit der Grund hinter einer schlechten Bewertung erfasst wird.
Die Ergebnisse lesen
Abschnitt betitelt „Die Ergebnisse lesen“Die Surveys wurden durchgeführt und die Daten kamen zurück. 50 Gäste des Test Launch haben gegessen wie sonst auch, dabei über das Tablet bestellt und bezahlt, und jede Person bekam am Ende des Besuchs einen digitalen Survey. Die Ergebnisse sind als Anzahlen und Prozentsätze angegeben, mit wörtlichen Kommentaren zu mehreren Fragen.
Die wichtigsten Zahlen
Abschnitt betitelt „Die wichtigsten Zahlen“| Frage | Ergebnis |
|---|---|
| Gesamtbewertung des Tablets (Skala von 1 bis 5) | 72 Prozent gaben 4 Gut oder 5 Großartig: 40 Prozent Gut, 32 Prozent Großartig. 4 Prozent Mangelhaft, 10 Prozent Mittelmäßig, 14 Prozent Neutral |
| Einweisung durch die Bedienung in die Nutzung des Tablets | 76 Prozent sagten Sehr gut, 14 Prozent In Ordnung, 10 Prozent Nicht gut |
| Leichtigkeit der Navigation im Tablet | Nur 48 Prozent bewerteten sie als Ziemlich oder Sehr leicht. 30 Prozent Neutral, 18 Prozent Etwas schwierig, 4 Prozent Schwierig |
| Leichtigkeit des Bestellens aus der Karte | Nur 46 Prozent bewerteten sie als Ziemlich oder Sehr leicht |
| Checkout war schnell, einfach und sicher | 82 Prozent Trifft zu, 18 Prozent Trifft nicht zu |
| Vertrauen beim Bezahlen über ein Tablet | 66 Prozent gaben 4 oder 5 |
| Newsletter-Anmeldung über das Tablet | 78 Prozent Ja |
| Anmeldung beim Birthday Club | 16 Prozent Ja |
| Tablet gegenüber dem klassischen Erlebnis mit Bedienung | 40 Prozent bevorzugten ausschließlich das Tablet, 30 Prozent wollten eine Mischung, 20 Prozent hatten keine Präferenz, 10 Prozent mochten die Tablets nicht |
| Mehrfache Bestellungen während der Mahlzeit | 36 Prozent Ja |
Alle Gäste bestellten ein Abendessen, 82 Prozent bestellten Vorspeisen, 70 Prozent Dessert und 56 Prozent Getränke, was vor allem bestätigt, dass die Stichprobe eine vollständige Mahlzeit gegessen hat und keinen Snack.
Wo das Pilotprojekt seine Ziele verfehlt hat
Abschnitt betitelt „Wo das Pilotprojekt seine Ziele verfehlt hat“Darauf müssen die Erkenntnisse aufgebaut werden, denn drei der fünf Standards zur Kundenzufriedenheit wurden nicht erreicht.
| Standard | Was der Survey gezeigt hat | Urteil |
|---|---|---|
| 98 Prozent Bestellgenauigkeit | Nur 72 Prozent sagten, die Küche habe die Bestellung korrekt zubereitet. 28 Prozent sagten nein | Deutlich verfehlt |
| Unter 5 Prozent melden technische Probleme | 12 Prozent meldeten ein Problem: eingefrorene Bildschirme, Störungen, eines durch einen Neustart der Bedienung behoben | Verfehlt |
| Wartezeit in der Lobby von zehn Minuten oder weniger | 54 Prozent warteten mehr als 15 Minuten. Nur 26 Prozent wurden innerhalb von 10 Minuten platziert | Verfehlt |
| Checkout von einer Minute oder weniger | 82 Prozent fanden den Checkout schnell, einfach und sicher | Nach dem eigenen Urteil der Gäste erreicht |
| Ticket Time von 8 Minuten für Vorspeisen, 12 bis 15 für Hauptgerichte | Der Survey fragt nur in Blöcken nach der Zeit für die gesamte Essensbestellung: 56 Prozent innerhalb von 20 Minuten, 30 Prozent 21 bis 30 Minuten, 12 Prozent 31 bis 40 Minuten, ein Gast 41 bis 50 | Mit diesem Instrument nicht direkt messbar |
Die wörtlichen Kommentare machen die Zahlen erst handlungsfähig, und sie sind auffallend konkret. Die Fehler bei der Bestellgenauigkeit häufen sich bei Modifiern und Substitutionen: Petersilie oder Käse nicht weggelassen, eine gewünschte Substitution nicht umgesetzt, Kartoffelpüree statt Pommes, ein übergartes Hauptgericht, ein komplett falsches Hauptgericht. Die Fehler beim Checkout häufen sich beim Thema Bargeld: Gäste, die nur Bargeld hatten, merkten nicht, dass sie es nicht nutzen konnten, und brauchten trotzdem die Bedienung, dazu ein eingefrorenes Tablet und der Wunsch, per Handy zu zahlen. Die Freitextkommentare am Ende sind überwiegend wohlwollend (die Tablets machten Spaß, das Abendessen fühlte sich schneller an, das Sauce-and-Spoon-Video auf dem Tablet war gut) mit zwei nützlichen Bitten: die Möglichkeit erhalten, eine Bedienung zu wählen, und den Gästen Zeit geben, sich an die Geräte zu gewöhnen.
Die Erkenntnisse zusammenführen und präsentieren
Abschnitt betitelt „Die Erkenntnisse zusammenführen und präsentieren“Daten auszuwerten und sie zu berichten sind zwei verschiedene Aufgaben, und die Woche ist deutlich in Bezug auf diese Lücke.
Beginn beim Publikum
Abschnitt betitelt „Beginn beim Publikum“Denk darüber nach, was für dieses Publikum am bedeutsamsten ist und wie viel Zeit es hat. Wenn das Publikum aus verschiedenen Rollen besteht, müssen dieselben Daten womöglich auf mehr als eine Weise aufbereitet werden, weil verschiedene Zielgruppen die Informationen aus verschiedenen Gründen wollen.
- Profitiert von einem detaillierten Bericht
- Es braucht ihn, um sich um die Projektteile zu kümmern, die es verantwortet
- Brauchen und wollen eine detaillierte Analyse in der Regel nicht und haben keine Zeit dafür
- Sie wollen eine Zusammenfassung der wichtigsten Informationen und deren Wirkung auf ihre Investition
Die empfohlene Reihenfolge ist, zuerst den ausführlichen Evaluationsbericht zu schreiben, der die Evaluation Questions beantwortet, und ihn dann in das Format zusammenzufassen, das zum Publikum passt. Neben dem vollständigen Bericht gibt es zwei verbreitete Formen:
| Form | Was sie ist |
|---|---|
| Summary Sheet | Eine ein- bis zweiseitige Ausarbeitung mit nur den relevantesten Informationen, wie ein Flyer oder eine Momentaufnahme der Erkenntnisse |
| Foliengestützte Präsentation | Digitale Folien, die die Informationen visuell darstellen |
Daten zu berichten ist keine Präsentation einer Evaluation
Abschnitt betitelt „Daten zu berichten ist keine Präsentation einer Evaluation“Das Beispiel, das das Video nutzt: Angenommen, 36 Prozent der Befragten berichteten von einem negativen Restauranterlebnis mit den Tablets. Diese Zahl allein sagt nichts, denn sie könnte vier verschiedene Dinge bedeuten.
Die Daten zu filtern und auszuwerten ist der wichtigste Teil, denn dort machst du sie dir selbst verständlich und wirst mit den Ergebnissen, den Befragten und ihrer Bedeutung für die Projektqualität vertraut. Zwei praktische Tipps: Achte auf Trends, Muster und Ausreißer, und teile den Prozess mit Teammitgliedern, indem ihr abwechselnd sagt, was die Daten aus eurer Sicht bedeuten, was sowohl deine eigene Lesart prüft als auch Dinge sichtbar macht, die eine einzelne Perspektive übersieht. Wenn du die Bedeutung in einfacher Sprache erklären kannst, hast du die Grundlage der Präsentation.
Erzähl die Geschichte
Abschnitt betitelt „Erzähl die Geschichte“Bevor du Folien baust, überlege, was du erreichen willst, welche Punkte du machen willst und welche Fragen und Bedenken du beantworten musst. Die Struktur, die das Video für diese Präsentation empfiehlt:
-
Erinnere an das Ziel. Beginne mit dem übergreifenden Ziel und Zweck des Projekts, denn es geht darum zu zeigen, ob die Quality Standards erreicht werden.
-
Benenne den evaluierten Meilenstein und wie er zu den Projektzielen beitragen sollte.
-
Erkläre, was die Daten ergeben haben, ohne jeden Datenpunkt oder jede Survey-Frage durchzugehen.
-
Benenne die großen Probleme, die die Daten gezeigt haben, und fasse den Rest zusammen. Wo es gut lief, greif ein paar Highlights heraus und mach weiter.
-
Schlag zu den großen Schwachstellen Lösungen vor oder formuliere die konkreten Fragen, die du beantwortet brauchst.
Aktivität: die Präsentation der Test-Launch-Erkenntnisse
Abschnitt betitelt „Aktivität: die Präsentation der Test-Launch-Erkenntnisse“Die fünfte Aktivität bestand darin, die Survey-Ergebnisse auszuwerten und die Folien für die Stakeholder zu bauen. Die Vorlage ist ein Gerüst aus fünf Abschnitten ohne Inhalt: Title, Summary, Overview, Findings, Next Steps. Die Musterlösung zeigt die beabsichtigte Form in fünf Folien: ein Titel, der den Meilenstein benennt und wie er erreicht wurde; eine Evaluationsfolie, die die beiden Fragen nennt (haben wir unsere Ziele erreicht, waren die Gäste zufrieden) und die Methode; eine Ergebnisfolie mit einer einzigen großen Zahl, den 72 Prozent, die das Erlebnis mit 4 oder 5 bewerteten; und dann eine Folie je Empfehlung, die jeweils eine Survey-Erkenntnis mit einer Empfehlung koppelt. Die beiden der Musterlösung sind die nicht gesunkene Tischumschlagzeit, beantwortet mit der Zusammenarbeit mit den General Managern zur Beschleunigung der Gastbesuche, und Fehlfunktionen der Tablets, beantwortet mit einem Prozess zur Prüfung der Tablets vor dem Service und zum Austausch zwischen Gästen.
Mein eingereichtes Deck folgt dieser Form über sechs Folien:
| Folie | Was sie enthält |
|---|---|
| Title | Der Name des Pilotprojekts, dass es sich um Erkenntnisse und nächste Schritte aus dem Test Launch handelt, und die Autorenschaft |
| Meilenstein erreicht | Was getan wurde, in fünf Stichpunkten, plus eine einzeilige Kette, wie wir hierhergekommen sind: Lieferant ausgewählt, Tablets installiert und integriert, Personal geschult, Test Launch mit 50 Gästen durchgeführt |
| Was wir messen wollten | Die fünf Standards zur Kundenzufriedenheit als Zielwerte, mit dem Exit Survey als benannter Datenquelle |
| Was den Gästen gefallen hat | Die vier positiven Punkte: 72 Prozent bewerteten es mit Gut oder Großartig, 88 Prozent hatten kein technisches Problem, 82 Prozent fanden den Checkout schnell, 70 Prozent wollen künftig Tablets, entweder ausschließlich oder gemischt |
| Empfehlung 1 | Die Lücke bei der Bestellgenauigkeit schließen. Auf der einen Seite die Daten (72 Prozent gegenüber dem Ziel von 98 Prozent, wörtliche Kommentare zu Modifiern und Substitutionen), auf der anderen die nächsten Schritte: ein verpflichtender Bestätigungsbildschirm vor dem Absenden, der jeden Modifier auflistet, Modifier fett auf dem Küchenticket gedruckt, eine Küchenbesprechung zum neuen Ticketformat und eine wöchentliche Genauigkeitskennzahl mit einer Go- oder No-go-Entscheidung zum Ziel vor der Skalierung |
| Empfehlung 2 | Die Navigation verbessern und einen Weg zur Barzahlung ergänzen. Daten: 48 Prozent fanden die Navigation leicht, 46 Prozent das Bestellen aus der Karte, 18 Prozent konnten am Tablet nicht auschecken, 54 Prozent warteten mehr als 15 Minuten. Nächste Schritte: den Navigationsfluss gemeinsam mit dem Lieferanten vereinfachen, eine Option zum Zahlen bei der Bedienung plus Beschilderung ergänzen, die Front-of-House-Schulung zum Begleiten von Erstnutzenden auffrischen und die Überwachung der Wartezeit in der Lobby ergänzen, mit einem Blick auf die Personalbesetzung zu Stoßzeiten |
Das Muster, das aus beiden Fassungen mitzunehmen ist: eine Empfehlung je Folie, Erkenntnis und Reaktion nebeneinander und die positiven Punkte auf eine einzige Folie verdichtet, damit die Meetingzeit auf die Probleme entfällt.
Eine eigene Musterlösung zeigt dieselbe Evaluation als Executive Summary, ein einzelnes Absatzpaar, das abdeckt, was installiert wurde und wann es live ging, wie Feedback gesammelt wurde, was daraufhin geändert wurde, und dann die Ergebniszahlen nach dem offiziellen Launch: durchschnittliche tägliche Gästezahl um 10 Prozent gestiegen, Wartezeit um 30 Minuten gesunken, Checkout auf eine Minute verkürzt, Lebensmittelabfall um 50 Prozent gesunken, Umsatz um mehr als 20 Prozent gestiegen und Kundenzufriedenheit von 72 Prozent nach dem Pilotprojekt auf 86 Prozent gestiegen. Sie schließt mit dem Hinweis, dass es weiterhin Verbesserungsspielraum gibt. Das ist dieselbe Geschichte in einem Zehntel der Länge, und genau darum schreibt man zuerst die ausführliche Fassung.
Die Retrospektive
Abschnitt betitelt „Die Retrospektive“Retrospektiven finden oft am Ende eines Projekts statt, aber sie sind ein Werkzeug zur Prozessverbesserung über den gesamten Lebenszyklus und besonders nützlich nach einem Meilenstein. Direkt nach der Einführung der Tablets und deren Test mit den Pilotgästen ist genau so ein Moment: feiern, was gut gelaufen ist, und die Verbesserungen finden, bevor der nächste Meilenstein kommt.
Drei Zwecke
Abschnitt betitelt „Drei Zwecke“Weil es eine bestimmte Art von Meeting ist, braucht es eine Agenda, um die Diskussion zu führen, das Meeting zu organisieren und das Gelernte zu dokumentieren. Die Aufgabe der Projektleitung ist es, den Ton zu steuern, dafür zu sorgen, dass sich jedes Teammitglied einbezogen fühlt, und die Details festzuhalten, die in das Retrospektivendokument einfließen.
Eine Sicht von Google: Psychological Safety
Abschnitt betitelt „Eine Sicht von Google: Psychological Safety“Dana, Site Reliability Managerin bei Google, ergänzt die Praxisperspektive. Ihr Team hält am Ende jedes Projekts Retrospektiven ab, um zu betrachten, was gut lief, was schlecht lief und wo sie Glück hatten, damit die Lehren ins nächste Projekt getragen werden. Wird mitten im Projekt eine Entscheidung gebraucht, erheben sie dieselben Daten und führen eine frühzeitig durch.
Ihr benannter Fehlermodus ist, dass Menschen nichts sagen, was sie oft bei Sprint-Retrospektiven sieht, wo alle still dasitzen und sagen, es sei alles in Ordnung. Sie nennt zwei Ursachen und sorgt sich weit mehr um die zweite:
- Ihnen liegt an Verbesserung schlicht nicht viel. Es ist in Ordnung, sie ertragen es, so ist es eben.
- Fehlende Psychological Safety (psychologische Sicherheit): Sie haben nicht das Gefühl, sagen zu können, was sie denken, und dabei von den Menschen im Raum gut aufgenommen zu werden.
Ihre Begründung, warum der Rahmen zählt: Ein Team mit einem sicheren Raum, um solche Themen anzusprechen, weiß, dass es Anteil daran hat, was als Nächstes passiert, denn es kann sich wirklich viel daran ändern, wie Projekte gemanagt werden, wie kommuniziert wird und welche Projekte in der Planung ausgewählt werden. Retrospektiven müssen positiv und ohne Schuldzuweisung sein, und das Ziel ist die kontinuierliche Verbesserung von uns selbst, dem Team und den Prozessen.
Drei schwierige Retrospektiven
Abschnitt betitelt „Drei schwierige Retrospektiven“Der eigentliche Beitrag des Capstone sind die nächsten drei Videos, jedes zu einer Art, wie eine Retrospektive schiefgeht, und was dagegen zu tun ist. Die Gewohnheit dahinter ist in allen drei Fällen dieselbe: Stell dir die diagnostische Frage vor dem Meeting, nicht währenddessen.
Fehlende Beteiligung
Abschnitt betitelt „Fehlende Beteiligung“Die Frage, die zuerst zu stellen ist: Wird dein Team voraussichtlich zur Diskussion beitragen? Falls die Antwort nein lauten könnte, wird geringe Beteiligung das Team daran hindern, bedeutsame Prozessverbesserungen zu erreichen, denn eine Retrospektive lenkt die Aufmerksamkeit ebenso auf Herausforderungen wie auf Erfolge, und ein Team, dem es unangenehm ist, Herausforderungen auszusprechen, wird schlicht schweigen.
| Technik | Wie sie in der Praxis funktioniert |
|---|---|
| Einen sicheren Rahmen schaffen | Eröffne mit der Regel, dass hier Gesagtes hier bleibt und hier Gelerntes hinausgeht. Erinnere das Team daran, dass das Meeting frei von Stakeholdern und Kundschaft ist, sodass Probleme direkt benannt werden können |
| Die gewünschte Beteiligung vorleben | Bereite ein paar Aufgaben oder Prozesse vor, von denen du weißt, dass du sie schlecht gehandhabt hast, und sprich sie laut aus. Das genannte Beispiel ist ein Fehler im Papierkram, der die Tablet-Lieferung um zwei Werktage verzögert hat: zugeben und dann sagen, wie du es künftig vermeidest. Eigene Fehler zuzugeben macht es für alle anderen akzeptabel |
| Eine Gruppenfrage stellen, einzelne Antworten einholen | Bitte alle, sich einen Erfolg und eine Herausforderung zu überlegen, und geh dann reihum und bitte jede Person, zu teilen |
| Eine Frage umformulieren, die nicht ankommt | Wenn was lief gut und was lief schief nichts hervorbringen, probier es mit was sollten wir anfangen, aufhören und beibehalten |
| Den Projektzeitplan durchgehen | Wenn Menschen nur ganz aktuelle Punkte ansprechen, geh den Zeitplan durch, um Erinnerungen aufzufrischen und die Diskussion über das gesamte Projekt zurückzuholen |
Verantwortung fördern ohne Schuldzuweisung
Abschnitt betitelt „Verantwortung fördern ohne Schuldzuweisung“Verantwortlichkeit heißt, das Team dazu zu bringen, ganzheitlich über Fehler und Herausforderungen nachzudenken und künftige Lösungen zu finden, statt Einzelpersonen Schuld zuzuweisen. Sie fördert außerdem Ownership, und ein Teammitglied, das Ownership für einen Projektteil empfindet, ist tendenziell motivierter, diesen Teil weiter auf seinen Quality Standards zu halten.
| Technik | Wie sie in der Praxis funktioniert |
|---|---|
| Mit konkreten Herausforderungen vorbereitet kommen | Besonders nützlich, wenn das Team nur über Erfolge sprechen will. Das Beispiel: Die Kitchen Manager haben zurückgemeldet, dass sie sich von Entscheidungen der General Manager ausgeschlossen fühlten. Teile das mit der Gruppe und bitte sie zu helfen, die Ursache zu finden |
| Beschwerden in SMART-Maßnahmen verwandeln | Maßnahmen können spezifisch, messbar, erreichbar, relevant und terminiert sein, genau wie Ziele. Dasselbe Beispiel: die Kitchen Manager zum wöchentlichen Personal-Check-in einladen, einen fünfminütigen Agendapunkt ergänzen, in dem sie Themen ansprechen und Feedback bekommen, und in zwei Monaten prüfen, ob sie sich stärker einbezogen fühlen |
| Das Team drängen, die eigene Rolle zu erkennen | Teams neigen zu Herausforderungen, über die sie keine Kontrolle hatten, etwa eine verspätete Lieferung. Geh die Abfolge der Ereignisse durch und finde den Moment, in dem das Team die Gelegenheit verpasst hat, das Problem zu erkennen und anzugehen. Hätte jemand die Beziehung zum Tablet-Lieferanten früh verantwortet und wöchentliche Check-in-Calls aufgesetzt, hätten die Restaurants die Weitsicht gehabt, die verpasste Lieferung einzuplanen |
| Kritik konstruktiv halten | Konstruktive Kritik ist respektvolles Feedback mit der Absicht, der empfangenden Person zu helfen, die Arbeit zu verbessern. Wenn sie in Härte oder Nutzlosigkeit abgleitet, lenke um: Löse die Herausforderung von jeder bestimmten Person im Raum und steuere auf Prozessverbesserungen zu, aus denen das ganze Team lernen kann |
Uneinigkeit, Negativität und Spannung
Abschnitt betitelt „Uneinigkeit, Negativität und Spannung“Die Frage, die zuerst zu stellen ist: Wird sich dieses Gespräch für das Team voraussichtlich belastend anfühlen? Manchmal lautet die Antwort ja. Retrospektiven bauen Vertrauen, Ehrlichkeit und direkte Kommunikation auf, aber wenn sich der Rahmen nicht psychologisch sicher anfühlt, kippt eine sehr leicht ins Negative, und Negativität macht es schwerer, eine Diskussion zu führen, die tatsächlich Lösungen findet.
- Eröffne, indem du Projekterfolge hervorhebst
- Erwähne positives Stakeholder-Feedback oder danke dem Team für das Erreichen eines großen Meilensteins
- Meeting-Requisiten helfen: Teile gleich viele grüne und rote Karteikarten aus
- Erfolge auf Grün, Herausforderungen auf Rot. Grüne Karten auszuteilen bringt Menschen dazu, auch an Erfolge zu denken
- Triff dich vorab mit allen, die voraussichtlich eine negative Haltung mitbringen
- Frag nach dem Warum: Fühlen sie sich unsicher über ihren Beitrag, oder bekommen sie negatives Feedback zu ihrer Arbeit?
- Die Ursache zu verstehen legt die Lösung nahe, etwa jemandem seinen Wert zu bestätigen
- Eine einzelne negative Stimme kann eine ansonsten produktive Diskussion zum Entgleisen bringen
- Frag Mitglieder einzeln statt die Gruppe: Das gibt allen Raum, macht lösungsorientiertes Denken vor und verhindert, dass eine Person jede Frage beantwortet
- Ruf eine Pause aus. Eine Auszeit deeskaliert
Keine einzelne Technik passt auf jedes Szenario, und wie du Negativität begegnest, hängt von der Situation ab.
Die Retrospektive bei Sauce and Spoon
Abschnitt betitelt „Die Retrospektive bei Sauce and Spoon“Das durchgearbeitete Beispiel bringt sieben Personen in den Raum: Peta als Projektleiterin, Carter als Executive Chef, Gilly und Zane als General Manager und Kitchen Manager in North, Alex und Larissa in denselben beiden Rollen in Downtown und Seydou als Restaurantberater. Peta nutzt mehrere der obigen Techniken, ohne sie anzukündigen.
-
Zuerst den sicheren Rahmen setzen. Peta beginnt mit einem Dank an alle, weist darauf hin, dass der offizielle Launch einen Schritt näher gerückt ist, und sagt ausdrücklich, dass sie möchte, dass sich alle in einem sicheren Raum fühlen und alles teilen, was den Prozess verbessert.
-
Mit einer Frage öffnen, die beide Antworten zulässt. Möchte jemand mit etwas beginnen, das gut lief, oder mit etwas, das wir verbessern könnten? Alex antwortet mit einem Erfolg: Tablets in Downtown installiert und funktionsfähig.
-
Namentlich reihum gehen. Gilly wird direkt zu North gefragt, und nachdem sie denselben Erfolg bestätigt hat, bringt sie von sich aus das erste echte Problem ein: Die Tischumschlagzeit ist nicht so stark gesunken wie gewünscht. Alex bestätigt dasselbe Muster.
-
Das Problem an die Menschen weiterreichen, die es erklären können. Statt es im Raum zu lösen, fragt Peta die Küche nach ihrer Sicht. Zane berichtet, der Ticketfluss sei reibungslos und gut nachzuverfolgen gewesen, aber Bestellungen seien weiterhin zurückgegangen. Larissa bestätigt das, ergänzt, dass es weniger waren als zuvor, und berichtet von sich aus, dass die Küche auf Basis des neuen Ticketflusses bereits betriebliche Änderungen vorgenommen hat, mit denen sie zufrieden ist.
-
Anerkennen, dann parken. Peta benennt die zurückgegangenen Bestellungen als Priorität für weitere Analyse und bietet eine eigene Sitzung zu den Küchenverbesserungen an, was die Retrospektive davor bewahrt, zu einem Arbeitsmeeting zu werden.
-
Schlechte Nachrichten gut aufnehmen. Seydou leitet die technischen Probleme, die bei der Point-of-Sale-Integration gefunden wurden, mit einer Entschuldigung für die Nachricht ein. Peta behandelt es als gute Nachricht, weil sie schnell behoben wurden, und macht daraus eine Maßnahme: das Prozesshandbuch aktualisieren, damit die Lösung beim nächsten Mal leicht zu finden ist. Dann verfolgt sie den Faden weiter und bittet Seydou zu prüfen, ob hinter dem Problem der Ticketgenauigkeit ein technisches Problem steckt.
-
Verantwortlichkeit an sich selbst vorleben. Peta berichtet ihre eigenen Beiträge, dass wöchentliche Lieferantencalls die Abhängigkeiten klar gehalten haben und dass der Survey aussagekräftige Daten erfasst hat, und benennt dann ein internes Versäumnis: betriebliche Probleme an den Standorten, mit denen niemand geplant hatte und die die Arbeit des Teams gestört haben. Ihre Verbesserung ist, die Geschichte jedes Standorts zu verstehen, bevor beim nächsten Rollout mit der Planung begonnen wird.
-
Die anderen ziehen nach. Seydou gibt zu, dass die Umsetzung wegen nicht eingerechneter Urlaubszeit länger gedauert hat als erhofft, und getrennt davon, dass der Birthday Club wenige Teilnehmende bekam, wobei seine eigenen Korrekturarbeiten bereits laufen. Zane bittet darum, die Kapazität im Back of House vor dem Hauptlaunch hochzufahren. Larissa spricht das wechselseitig fehlende Verständnis zwischen Front of House und Back of House an und merkt an, dass geteilte Erfahrungen die Neigung verringern würden, sich gegenseitig die Schuld zu geben. Alex schlägt vor, die Schulung des Servicepersonals neu zu gestalten und sie womöglich zu teilen, damit sie neben den Tablets auch den täglichen Serviceablauf abdeckt.
Die Form ist bemerkenswert. Die ersten beiden Beiträge sind reine Erfolge; die kritischen Punkte kommen erst, nachdem Peta namentlich reihum gegangen ist und selbst ein Versäumnis eingeräumt hat. Die schwersten Punkte, das teamübergreifende Verständnis und die Neugestaltung der Schulung, kommen zuletzt, und zwar von den Personen, die früh am wenigsten gesagt haben.
Aktivität: die Retrospektiven-Auswertung
Abschnitt betitelt „Aktivität: die Retrospektiven-Auswertung“Die letzte Aktivität hat aus den Survey-Ergebnissen und diesem Meeting das Retrospektivendokument gebaut. Die Vorlage ist ein einzelnes Blatt mit fünf Spalten und sonst nichts:
| Spalte | Was hineinkommt |
|---|---|
| Feedback From | Die Quelle des Punkts, etwa Kundschaft oder Projektteam |
| Type | Lief gut, oder Verbesserungsbedarf |
| Description | Die Erkenntnis in einem Satz |
| Evidence | Die konkrete Survey-Frage und die Anzahlen, oder die namentlich genannte Person in der Retrospektive, die es angesprochen hat |
| Actions | Was dagegen getan wird |
Meine fertige Fassung hat zwölf Zeilen, aufgeteilt zwischen Kundenfeedback aus dem Survey und Projektteam-Feedback aus dem Meeting.
| Quelle und Typ | Erfasste Punkte |
|---|---|
| Kundschaft, lief gut | 72 Prozent bewerteten das Erlebnis mit Gut oder Großartig; 82 Prozent fanden den Checkout schnell, einfach und sicher; 78 Prozent meldeten sich am Tablet für den Newsletter an |
| Kundschaft, Verbesserungsbedarf | Bestellgenauigkeit bei 72 Prozent gegenüber dem Ziel von 98 Prozent; nur 48 Prozent fanden die Navigation leicht; 54 Prozent warteten mehr als 15 Minuten auf einen Tisch |
| Projektteam, lief gut | Alle Tablets an beiden Standorten installiert und funktionsfähig; Tickets kamen in gutem Tempo an und waren leicht nachzuverfolgen; wöchentliche Lieferantencalls hielten die Abhängigkeiten klar |
| Projektteam, Verbesserungsbedarf | Die Tischumschlagzeit bewegte sich kaum; Bestellungen gingen weiterhin zurück; und eine zusammengefasste Zeile für die durch nicht eingerechnete Urlaubszeit verlängerte Umsetzung, das noch nicht hochgefahrene Back of House, die Verständnislücke zwischen Front und Back of House und die neu zu gestaltende Schulung des Servicepersonals |
Die Disziplin, die das Blatt erzwingt, ist die Spalte Evidence. Jede Zeile muss entweder eine Survey-Frage mit ihren Anzahlen oder eine namentlich genannte Person aus dem Meeting anführen, was verhindert, dass das Dokument in Eindrücke abdriftet. Die Spalte Actions muss dann konkret genug sein, um sie jemandem zu übergeben: die Installationsschritte im Lieferanten-Playbook dokumentieren, wöchentliche Lieferantencalls als feste Taktung im Rollout-Runbook übernehmen, die Wartezeit in der Lobby ins Betriebsdashboard aufnehmen, teamübergreifende Hospitationen durchführen, die Umschlagzeit vier Wochen nach dem Launch gegen die Baseline messen.
Wiederholungs-Zusammenfassung
Abschnitt betitelt „Wiederholungs-Zusammenfassung“Weiter: Projektabschluss → - Probleme kommunizieren, der Closeout Report und der Impact Report.