How to run a project review
A project review fails when the hour is spent and nobody can say what continues, what changes, what begins, and what ends.
Goal
Leave with a named slice of work and a close someone can execute:
- What this review covers (one sprint, one launch, one delivery — not "the team in general").
- Which spine you ran (KISS, 3R, or AAR).
- Actions with owners, or a next-time change specific enough to try on the next similar event.
Include practices the group can keep or stop: meetings, tools, handoffs, tests, communication habits. Cut impressions with no next move ("I think we did okay") and personality labels.
Method
People already have a feeling about the work. The hard part is converting that feeling into practice before the next cycle starts.
Name the slice first. A review of "how we work" fills with slogans. A review of "sprint 14" or "the billing launch" can be sorted.
Then pick one spine. If it is you alone after a meeting or a work block, 3R is enough. If the team already agrees on what happened, KISS sorts Keep / Improve / Start / Stop. If people still disagree about intent, or the recap has no cause, run AAR's four questions before you file actions. Do not stack all three in one sitting.
Steps
1. Name the slice on the invite
One sprint, one launch, one incident, one delivery. Put the dates on the agenda. If two events are tangled, pick the one the next cycle will repeat.
2. Decide the room
Solo or two people and a same-day note: 3R. Team that already knows what happened: KISS. Team that cannot yet say intent versus actual: AAR. Do not invite a full AAR for a personal journal.
3. Collect candidates, not moods
For KISS: list practices people actually did. For AAR: restate the intent that was in force at the start, then the observable outcome. For 3R: write the sequence of what you did, how, and what resulted.
4. Run one spine
KISS sorts each item: Keep, Improve, Start, Stop (the 2×2 of good/bad result × sustainable/unsustainable helps when people stall). AAR runs intent → actual → why → next time, on the process, not on who to blame. 3R records facts, reflects on motives and repeating patterns, then refines a method small enough to test next time.
5. Close with owners or a next-time rule
Keep items need an owner only if they would fade. Improve and Start need a next attempt. Stop needs a date it actually ends. AAR next-time needs a checklist item, a decision rule, or a rehearsal — "communicate better" is still a recap.
- Slice: [sprint / launch / delivery] Dates: [start] → [end]
- Spine: [KISS | 3R | AAR]
- KISS
- Keep: [practice + owner if it would fade]
- Improve: [practice + next attempt]
- Start: [practice + first date]
- Stop: [practice + end date]
- AAR (if used)
- Intent: [what we meant to accomplish]
- Actual: [what happened]
- Why: [process, timing, resources — not a person]
- Next: [specific change]
Frameworks
How each framework helps with this problem.
Primary
KISS Review Framework
Turn a review of recent work into four action buckets: what to keep, improve, start, and stop.
Alternative — personal loop
3R Review Framework
Learn from a recent piece of work by recording what happened, reflecting on why, and refining the method you will use next time.
Alternative — intent vs actual
After-Action Review (AAR)
Compare what was intended with what actually happened after a completed event, then name why the gap occurred and what will change next time, without turning the review into blame.
Example
KISS — sprint review
Slice: Sprint 14. Standup stayed useful (Keep). The handoff checklist exists but QA still misses a field (Improve: rewrite the three required fields, owner: Priya, this Friday). Pairing on the risky tickets happened twice and unblocked the board (Start: pair on P0s by default next sprint). The Thursday status meeting never changed a decision (Stop: last one this week).
The room can execute that list. "We should be more aligned" would not have been a review.
AAR — Friday demo that slipped
Intent: 30-minute customer-council demo of the search redesign, starting on time. Actual: started 25 minutes late; two filters still showed the old taxonomy. Why: staging refresh ran during the slot; a taxonomy PR was "almost done" and skipped the demo checklist. Next time: freeze staging two hours before external demos; nothing "almost done" goes on the script.
KISS can still sort the freeze and the checklist afterward. The AAR is what put intent and actual on the table first.
3R — after a messy meeting (solo)
Record: 40-minute design review; no decision; three new tickets from hallway asks. Reflect: you kept the agenda open because you did not want to cut a senior engineer. Refine: timebox each topic to eight minutes; park new asks on a parking-lot note; send the decision in Slack before leaving the room.
Mistakes
- Reviewing "the team" instead of one sprint, launch, or delivery
- Ending on a mood with no Keep / Stop / next-time line
- Running AAR and KISS as two workstreams in the same hour
- Using 3R as a facilitated team blame round
- Personality labels in the Why ("careless," "heroic")
- Stop items with no end date
- Treating a quiet success as not worth an AAR
- Copying last retro's actions without checking whether they happened
Next step
Put the slice and the dates on the invite. If you are reviewing alone, run 3R. If the team already knows what happened, sort with KISS. If intent versus actual is still missing, start with AAR, then file actions.
Apply this to your own context
Bring your situation into Advisor. It helps you choose a framework and work through the next step.