The twelve-slide structure
| Slide | Content | Time |
|---|---|---|
| 1. Title | Project title, team members, guide, department | 15 sec |
| 2. Problem | The problem in one sentence, with who it affects | 45 sec |
| 3. Existing systems | What exists today and its specific gap | 45 sec |
| 4. Objectives | Three to five measurable objectives | 30 sec |
| 5. Proposed system | Your approach in one diagram | 60 sec |
| 6. Architecture | System architecture with data flow | 90 sec |
| 7. Technology | Stack with a one-line reason per choice | 45 sec |
| 8. Modules | Module list with who built what | 45 sec |
| 9. Demo | Live demonstration of the main flow | 3–4 min |
| 10. Results | Metrics, test results, screenshots | 90 sec |
| 11. Limitations & future scope | Honest boundaries and next steps | 45 sec |
| 12. Conclusion | What was achieved, in two lines | 20 sec |
Slide design rules that survive a projector
- Maximum six lines per slide. If it needs more, it needs two slides.
- Font size 24 or larger. Projector resolution and room lighting are always worse than your monitor.
- One diagram per concept, drawn large enough to read from the back row.
- High contrast: dark text on light background survives a bright room better than the reverse.
- No paragraphs. If you write full sentences, the panel reads instead of listening.
- Screenshots must be cropped to the relevant part, not full desktop captures.
The demo is the centre — rehearse it separately
Half your presentation time goes to the demo, so it deserves its own rehearsal. Decide the exact click path in advance and practise it until it needs no thinking, because you will be talking while you click.
Prepare the environment in advance: logged in, data seeded, browser tabs open in order, notifications silenced, and the terminal ready if you need to show logs. Never start a demo by opening an editor and running a build.
Demo failure insurance
- Record a full screen capture of the working demo the day before and keep it on your phone and a pen drive.
- Prepare a reset script or a database snapshot so a failed action can be undone in seconds.
- Have a hotspot ready in case the room network blocks your application.
- If something fails, do not debug in front of the panel. Switch to the recording, explain what it shows, and continue.
- Keep a second laptop with the environment set up if your project has a complicated local setup.
Dividing the presentation across a team
Give each member a contiguous block that matches what they built, not alternating slides. Handovers cost time and look rehearsed in a bad way.
The member who builds the core module should present the architecture and run the demo, because the follow-up questions will land there and they should not be relayed.
Every member must be able to answer for the whole project regardless of who presented what. Examiners deliberately ask the quiet member about someone else's module.
What to say when the panel interrupts
Interruptions are normal and usually a good sign — it means they are engaged. Answer the question fully, then say where you were and continue. Do not skip your remaining slides in panic; ask if they would like you to continue or move to the demo.
If you are running out of time, cut slides 3 and 7 rather than the demo or the results. Those two carry the least weight and can be answered verbally if asked.