Design questions for a project retrospective

Author: AILesson7 min setupTested with:ChatGPTReviewed: 2026-08-28

Quick answer

Create psychologically safer, evidence-seeking questions that move from outcomes and context to controllable experiments. Provide: Project outcomes and timeline, Participants and safety context, Retrospective goal and constraints. Expected result: A sequenced retrospective guide with evidence prompts, participation methods, and action conversion.

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

Project outcomes and timelineParticipants and safety contextRetrospective goal and constraints

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Design a project-retrospective question guide from the supplied evidence and safety context.

Goals, scope, dates, milestones, outcomes, changes, incidents, stakeholders, and evidence:
[project]

Roles, power, absent voices, conflict, confidentiality, facilitation, accessibility, and evaluation boundaries:
[participants]

Learning/decisions, duration, pre-work, evidence, authority, follow-up capacity, and exclusions:
[goal]

Sequence questions from shared facts and expectations to variation, contributing conditions, decisions, signals, strengths, trade-offs, and controllable next experiments. Use neutral wording that asks what happened and under what conditions, not who failed or why someone behaved badly. Separate event, impact, mechanism hypothesis, and judgment. Invite disconfirming cases and perspectives from affected people who are absent. Avoid generic prompts whose answers cannot change a practice, forced positivity, hindsight certainty, therapy, blame, and promises of anonymity not supported by the setting. Return: pre-work evidence request; opening frame; prioritized questions with purpose, evidence prompt, method, time box, and follow-up probes; questions to avoid and replacements; participation/safety design; action-selection rule; experiment template with owner/evidence/review date; parking lot; and close/check-out.

Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

Project outcomes and timeline: Eight-week billing migration for 26 enterprise accounts. Goal: move all accounts by 30 June with no invoice delay over one business day and no incorrect total. Actual: 24 moved; two deferred after tax-rule questions. Three invoices were delayed two days; one showed an incorrect tax total and was corrected before sending. Timeline changed in week 4 when the vendor released a new import format. Support logs, migration checklist completion, defect records, customer emails, and decision log are available. The checklist was completed for all 26 but tax-country evidence was missing for four. A manual peer review caught the incorrect total.
Participants and safety context: 45-minute session: project manager facilitates; billing operations lead, two analysts, engineer, support lead, and vendor representative attend. Operations lead manages analyst performance, so avoid round-robin personal confession. Two customer-success managers and affected customers are absent; their written observations can be requested. Session is internally attributed, not anonymous. Captions needed. Contract dispute with vendor is out of scope and goes to procurement.
Retrospective goal and constraints: Understand which controls worked or failed, improve the next migration wave, and select at most two experiments that the team can run within three weeks. Pre-work can include a factual timeline and anonymized cases. Operations lead can approve process changes; engineering changes need separate planning. Do not evaluate individuals or reopen the already-corrected invoice with the customer.

Example output

Pre-work: circulate a locator-linked timeline, the four tax-evidence gaps, three delay cases, corrected-total case, checklist definition, vendor-format change, and written observations from the two absent customer-success managers. Ask participants to mark factual corrections before the session; do not ask for anonymous comments when attribution is visible.

Opening: “We are examining the migration system and decisions, not rating individuals. We will distinguish evidence from hypotheses and select no more than two three-week experiments. Procurement issues go to the parking lot.”

Questions: (1, 6 min) What outcomes differ from the original goal, and which source confirms each? Purpose: shared facts; silent review then clarify. (2, 6 min) Where did the three delayed cases follow the normal path, and where did conditions differ? Probe timing relative to the vendor format. (3, 6 min) How could all checklists be complete while four tax-country evidence items were absent? Treat “checkbox did not require evidence” as a hypothesis until the checklist is inspected. (4, 5 min) What enabled peer review to catch the incorrect total before sending, and when would that control not work? (5, 5 min) What evidence supports or challenges the claim that the format change caused delays? (6, 4 min) Which absent customer/support effects should change the next process? (7, 7 min) Which two controllable changes have the best expected risk reduction within capacity?

Avoid “Who missed the tax data?” Replace with “At what step should tax evidence have been required, and what did the interface/checklist permit?” Avoid “What went well?” Replace with the control-specific peer-review question. Action rule: select only experiments within authority, each with owner, affected cases, expected signal, guardrail, and review date. Candidate experiment: require tax-evidence locator before checklist completion; owner Operations lead; test on next 10 cases; evidence zero completed rows without locator; review in three weeks. Engineering validation remains unassigned until separate planning.

Why this works

1
Beginning with shared evidence reduces hindsight stories and disagreement about the basic timeline.
2
Action-selection rules turn learning into a small number of owned experiments instead of an unbounded wish list.

Check the result

Do questions distinguish observed events, impacts, hypotheses, and judgments?
Can lower-power and absent perspectives be represented without unsupported anonymity promises?
Will the process select only actions with an owner, observable evidence, and review date?

Use it with confidence

Frequently asked questions

Practical answers about when to use this recipe, what to provide, and where human review still matters

What should I prepare before using “Design questions for a project retrospective”?

For “Design questions for a project retrospective,” prepare Project outcomes and timeline, Participants and safety context, and Retrospective goal and constraints. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Design questions for a project retrospective” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A sequenced retrospective guide with evidence prompts, participation methods, and action conversion—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Design questions for a project retrospective”?

The published test record for “Design questions for a project retrospective” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

More ways to explore