How do you review a small project without turning it into blame?
Discuss observable workflow, information available at the time and a change to test next. Avoid explaining one result through personality labels. Reducing blame does not remove accountability.
Review one concrete episode
- Compare the expected and actual events.
- Identify missing information or resources at the time.
- Agree one checkable process change and who will verify it.
Replace labels with a workflow description
Nobody was proactive might mean three people each assumed someone else would confirm the venue. A named owner and deadline address that ambiguity. This does not mean every problem is procedural or that breached responsibilities should be ignored.
A filled example
Worked change: One person confirms the venue and shares confirmation the day before; others no longer assume it happened.
What to do with your observation
| Observation | Next action |
|---|---|
| Description consists of personality labels | Reframe it as checkable events and process. |
| Responsibility is formally disputed | Use the agreed process rather than hiding it in a general review. |
A worksheet you can use
Expectation: __. Actual event: __. Available information: __. Gap: __. Change: __. Verifier: __.
Must a review identify something wrong?
No. Retain useful arrangements too, explaining specifically when they helped.
Evidence and scope
This original review arrangement is neither a formal investigation nor a research-validated team intervention.
Edmondson studies team learning, not these original scripts. Amy Edmondson (1999) — Psychological Safety and Learning Behavior in Work Teams
Sources and further reading
Amy Edmondson (1999) — Psychological Safety and Learning Behavior in Work Teams
This collection in Chinese and English · Life possibilities library