How to review a project before taking on the next one
By Alice Huang, Chief of Staff and operator
Review a project using evidence, the team's experience and a small set of owned changes before starting the next round of work.
Before you rush into the next project, understand the one you just finished. Otherwise the same broken handoff can follow you into a new plan.
Atlassian's retrospective guidance asks teams to discuss what worked, what did not and what could improve, then choose actions. This suggested project review adapts that habit beyond software work. It does not require a particular delivery system.
Bring the original plan
Compare the intended outcome with what happened. Check dates, scope changes, decisions and completion evidence. Do not rewrite the goal to make the project look successful.
Ask the people doing the work what they experienced. Keep observations, interpretations and unresolved questions separate. A loud opinion is not a verified cause.
Discuss useful questions
- What helped the work move?
- Where did it wait, return or fail?
- Which assumption was wrong?
- What changed after agreement?
- What should we keep, stop or try?
Focus on a process the team can improve, not a public trial of a colleague. Accountability matters; blame without evidence rarely tells you what to change.
Choose a few changes
Give each change an owner, next action and evidence to check. Record dependencies. If nobody can carry it, do not mark it as an action because the meeting liked the idea.
A fictional example: check the customer handoff before the next launch. The action is agreeing required fields and an owner, not "communicate better."
Follow up
Atlassian recommends following up on retrospective actions. Put the review where the team will see it. If a change did not help, revise it rather than pretending the meeting fixed the problem.
The result should be a better next round of work. A polished review with no owned change is just another document.