Post-Project Review

One-sentence summary

Stopping when a project ends to write down, in an organised way, what went well, what was hard and what you would change next time is called a post-project review (a retrospective).

Why does it matter?

The most valuable part of a project often appears after it is finished. Whether the robot worked or not, you made many decisions along the way, tried many things and got stuck a few times. If you do not keep track of these, you may get stuck in the same place on your next project.

Reviewing turns memory into a written note. Details that are clear today become blurry two weeks later. A lesson you write down is like a small note left for a future version of yourself.

It is also an honest habit. It is easy to remember only the things that went well, but real progress starts with naming the hard parts clearly. This is why engineers, programmers and teams hold a short “look back” meeting when a project ends.

This is the final lesson of the academy. Our goal is not to close a door but to leave you with a habit that lets you keep learning on your own.

What a review looks at

Throughout this lesson we will use one concrete example: the automatic night light we designed in earlier modules. A small circuit that turns on an LED when the room gets dark and turns it off when the room gets bright. We are not claiming it was actually finished; we use it only to make the review concrete.

A good review answers four simple questions.

1. What went well?

You should write down the things that worked, because you will want to repeat them on purpose next time. Maybe drawing the circuit on paper before building it helped a lot. Maybe testing after every change let you find the mistake early.

Example: “I tested the light sensor on its own first, so I quickly saw that the problem was in the wiring, not the sensor.”

2. What was hard?

Here we do not look for someone to blame; we name the obstacle. The place where you struggled is the most valuable clue for your next project.

Example: “The LED sometimes turned on during the day too. I did not know how to choose the threshold value and had to try many times.”

3. What did I learn?

Learning does not always have to be technical. A technical lesson (“the resistor value matters”) is just as valuable as a working-habit lesson (“leaving it to the last day made me rush and make mistakes”).

4. What changes next time?

Every lesson should turn into a small change you will make in the future. “I will be more careful” is vague. “I will check the parts list before building the circuit” is a decision you can actually follow.

The retrospective table

Instead of remembering these four questions from scratch each time, a small table makes the job easier. Below is an example retrospective table, filled in for the night-light project.

There is only one rule when filling in the table: keep every row short, concrete and honest. The goal is not to look good but to help the future you.

Blank template

You can use the blank template below for your own project.

PROJECT NAME: ________________
DATE: ____ / ____ / ______

WHAT WENT WELL?
- 
- 

WHAT WAS HARD?
- 
- 

WHAT DID I LEARN?
- 
- 

WHAT CHANGES NEXT TIME?
- 
- 

Keeping the learning going

A review is more than closing a single project; it is a map for your next step. The items in the “What changes next time?” column can actually be the first ideas for a new project.

A few simple habits to keep learning alive:

• Keep a small learning journal. Add the table to it at the end of every project.
• Write down a question you are curious about. Even if you cannot answer it today, it may become a project one day.
• Explain a lesson to someone else. If you can explain it, you have truly learned it.
• Do not throw away a finished project; bring it back to life by adding one feature.

Example: if the night-light retrospective said “tuning the threshold by hand was hard,” then the next idea is already showing itself: make the threshold adjustable with a knob.

Mini practice

Choose something you recently finished (or left half done). It could be a school assignment, a Scratch game or a small circuit.

1. Copy the blank template above into a notebook.
2. Write at least two items in each of the four sections.
3. Pick one item from “What changes next time?” and star it.
4. Turn that item into a concrete sentence you will apply on your next project.

Here is how to test whether an item is good: could someone else read it and do the same thing? If the answer is yes, the item is clear enough.

If you like, take one more step: explain your starred item to a friend or an adult. If you get stuck explaining it, the decision is not clear enough yet. If you can explain it, you have truly grasped that lesson and you are ready to use it on your next project.

Common mistakes

Writing only the bad parts

A review is not a complaint list. If you do not write the things that went well, you cannot repeat them on purpose.

Blaming yourself

“I am useless” is a judgement, not an observation, and it does not help. Instead, name the event: “I forgot to check the connections.” Once you name a problem, you can solve it.

Writing vague decisions

“I will be better” cannot be measured. “I will tick off the parts list before building” can be followed.

Never doing the review at all

This is the most common mistake. When a project ends we relax and put off writing the lessons down. But the details should be written while they are freshest, that is, right at the end.

Safety note

If you want to share your review with others, look at what is inside it first. Your notebook can be just for you, and that is completely normal. If you choose to share it, leave out personal information (your full address, photos of other people, a friend’s name without their permission). Asking an adult for their opinion does not weaken an honest review; it makes it stronger. The point of a review is not to speak badly of anyone but to understand the process better, so use respectful language when you mention other people too.

Lesson summary

• A post-project review is the habit of writing down, in an organised way, what went well, what was hard, what you learned and what will change.
• The four questions fit into a retrospective table, and every row should be short, concrete and honest.
• Writing down what went well lets you repeat it on purpose.
• A good decision should be measurable and doable: not “I will be better,” but a concrete step.
• A review is a map for keeping the learning going and starting your next project.

Review questions

1. What is a post-project review (retrospective)?
2. What are the four core questions of the retrospective table?
3. Why should we write down what went well, not only the parts that were hard?
4. Why is “I will be more careful” a weak decision? Give a better example.
5. When sharing your review, what information should you leave out?

Answers

1. It is the process of writing down, in an organised way, what went well, what was hard, what you learned and what will change next time, after a project ends.
2. What went well? What was hard? What did I learn? What changes next time?
3. If we do not write down what went well, we cannot repeat it on purpose on the next project; a review is a tool for improvement, not a complaint list.
4. It cannot be measured and is vague; no one can turn it into a concrete step. A better version: “I will tick off the parts list before building.”
5. Personal information: your full address, photos of other people without permission, a friend’s name without their consent.

Source and verification note

For “Post-Project Review”, verification focuses on whether the relationship between What a review looks at and 2. What was hard? remains consistent across examples. A project page should make a result claim only when it is supported by a real prototype, test record or observation. Numbers such as cost, duration and success rate must be labelled clearly when they are estimates.

Next lesson

Start a new project: turn your own idea into reality with what you have learned