What reviewers are scoring
Panels differ, but the underlying weights are consistent: roughly a third on whether the work is genuinely yours and you can explain it, a third on progress against the plan, and a third on documentation and presentation quality.
Notice what is not on that list: how impressive the idea sounds. A modest project explained precisely scores higher than an ambitious one explained vaguely, every time.
Review 1 — problem and design
This review happens before much code exists, so it is entirely about clarity of thinking. The most common failure is a scope that is obviously too large, which reviewers spot immediately.
- A problem statement in two sentences, with who suffers from the problem
- A literature survey with four to six papers and what each one did differently
- System architecture diagram with modules and data flow
- Module split showing who is building what
- Week-by-week timeline mapped to the remaining reviews
- Technology choices with a one-line justification each
Review 2 — partial implementation
Now the panel wants evidence of real progress. Something must run end to end, even if it is narrow. A team that demonstrates one complete path is in better shape than one showing four half-built screens.
- One complete flow working from input to output
- Database schema created and populated with realistic data
- Preliminary results if this is an AI or analytics project
- An honest list of what is not built yet, with dates
- Any change from the review one design, with a reason
Review 3 and the final review
The last review is a rehearsal for the viva with your internal panel. Everything should be integrated, tested and documented, and each member should be able to answer for their own module.
- Complete system with all planned modules integrated
- Test case table with expected and actual results
- Results and comparison section, including limitations
- Report draft ready for correction, not a blank template
- Deployment or a stable local setup that starts reliably
The forty-eight hours before any review
- Freeze the code. Do not add features the day before — new code is where demo failures come from.
- Run the full demo three times on the machine you will actually use, from a cold start.
- Prepare seed data so no screen is ever empty during the demo.
- Write down the five questions you are most afraid of, and prepare a fifty-word answer for each.
- Record a screen capture of the working demo as a backup, and keep it on a phone.
- Check the room: projector cable, resolution, internet access, and whether you need a hotspot.
Handling the questions you cannot answer
You will be asked something you do not know. The response that costs the fewest marks is short and honest: say what you do know, say what you would check, and move on. Inventing an answer is far more damaging, because panels ask a follow-up and the invention collapses.
The one answer that must never be uncertain is who built what. If a member cannot explain their own module, the panel will assume the project was outsourced wholesale — which is why every handover we do includes a walkthrough session for the team.
Common review-day failures and their fixes
| Failure | Prevention |
|---|---|
| Demo works on one laptop only | Test on a second machine a week before |
| Empty screens with no data | Seed the database and keep a reset script |
| Internet dependency fails in the room | Carry a hotspot and cache what you can |
| Hardware refuses to connect | Backup video, spare components, labelled wiring |
| One member cannot explain their module | Internal walkthrough where each explains to the others |
| Report not ready | Write chapters as modules complete, not at the end |