- Careers & Skills
- Final Year Projects
FYP Presentation and Viva: How to Defend Your Final Year Project
How to present your FYP and pass the viva: a 12-slide structure, live demo prep with a backup video, common viva questions and how to answer them, team roles and nerves.
AuthorRehmat Ullah10 min read
Table of Contents
After two semesters of building, your final year project comes down to a short presentation and a set of questions from people who have seen hundreds of projects. Groups with good projects lose marks here every year, and groups with modest projects often do well.
The difference is rarely the code. It is whether the group can explain what they built, show it working, and answer "why" without looking at each other.
This guide covers how to present an FYP and get through the viva: a slide structure that fits most formats, how to prepare a demo that does not fail, the viva questions examiners tend to ask with how to answer them, how to split the work in a team, and what to do about nerves.
Before anything else: every university, and often every department, sets its own presentation format, time limit, marking scheme and viva procedure. Use this guide to prepare, then follow your supervisor's and FYP coordinator's instructions wherever they differ.
What examiners look for in an FYP defence
Examiners are checking three things: that the project works, that you understand it, and that each member did real work on it.
The presentation shows the first. The viva checks the second and third, usually by asking each member questions about their own part and someone else's. A polished slide deck cannot hide a project you do not understand, and a nervous presenter who clearly knows the system usually comes across well.
If your proposal was clear, much of this is already written. Your objectives, scope and methodology from the FYP proposal become the backbone of the presentation, and examiners often compare what you promised with what you delivered.
FYP presentation slide structure (12 slides)
Most FYP presentations fit into 10 to 12 slides. If you have 15 to 20 minutes, spend about a minute on each slide and five minutes on the demo. If your department gives you a template, use it and map these points onto it.
| # | Slide | What it must answer |
|---|---|---|
| 1 | Title and team | Project name, members, supervisor |
| 2 | Problem | Who has the problem, and what happens today? |
| 3 | Objectives and scope | What you promised, and what is out of scope |
| 4 | Existing systems | What already exists, and the gap you fill |
| 5 | Proposed solution | The system in one picture and one sentence |
| 6 | Architecture | The main parts and how data flows between them |
| 7 | Tech stack and why | Each tool and the reason you chose it |
| 8 | Key features | The three or four things the system does best |
| 9 | Live demo | Show it working, end to end |
| 10 | Testing and results | How you tested, and the numbers |
| 11 | Limitations and future work | What it cannot do yet, and what comes next |
| 12 | Conclusion and Q&A | Objectives met, and an invitation to questions |
Make the slides easy to follow
- One idea per slide, with a short heading that states it: "Bookings drop from 12 minutes to 2", not "Results".
- Diagrams over paragraphs. An architecture diagram with four or five boxes beats a list of technologies. The C4 model is a simple way to draw one at the right level of detail.
- Large text. If it does not read from the back of the room, cut words until it does.
- Real screenshots of your system, not stock images.
- Number your slides, so an examiner can say "go back to slide 6".
Rehearse with a timer
Run the whole presentation out loud at least three times, timed. PowerPoint's Speaker Coach gives private feedback on your pace, filler words and when you are simply reading slide text (Microsoft Support), and a friend who interrupts with questions is even better.
Prepare a live demo that does not fail
A working demo is the strongest evidence you have, so prepare it as carefully as the slides. Most demo failures come from the room, not the code: a different network, a projector resolution, an expired login.
- Write a demo script. One realistic path through the system in three to five minutes: log in, do the main task, show the result. Use sensible sample data, not "test123".
- Rehearse on the real setup. Use the laptop, network and projector you will use on the day, or as close as you can get.
- Start from a clean state. Fresh browser session, cleared test data, notifications off, other apps closed.
- Remove dependencies on the room. If the internet is unreliable, run the server and database locally, or use a phone hotspot you have tested.
- Check accounts and keys. API keys, free-tier credits and login sessions expire. Check them the day before.
- Keep a second device ready with the system already open, in case the main laptop fails.
Record a backup video
Record the full demo as a screen video a few days before the presentation and keep it on the laptop and a USB drive. OBS Studio is free and open source and records the screen on Windows, macOS and Linux.
If the live demo breaks, say so calmly, switch to the video, and explain what the examiners are seeing. Do not spend five minutes debugging in front of the panel. Check with your supervisor beforehand whether a recorded demo is acceptable as a backup; most panels prefer a live one when it works.
Common FYP viva questions and how to answer them
Viva questions fall into a few predictable groups. Prepare an answer for each one below, in your own words, and practise saying it out loud.
Problem and scope
- What problem does your project solve, and for whom?
- How is it different from existing systems?
- Why did you leave out feature X?
How to answer: name the real user and the real situation. For scope, point to your out-of-scope list from the proposal and give the reason: time, data, or the team's size.
Architecture and design
- Explain your architecture. How does data flow from the user to the database?
- Why did you design the database this way?
How to answer: walk through your architecture slide from left to right, one box at a time. Be ready to draw it on a whiteboard without slides, because some examiners ask exactly that.
Why this stack
- Why React and not Angular? Why MongoDB and not MySQL?
- Why did you use this AI model or API?
How to answer: give a reason linked to the problem, not a preference. "Bookings and payments are relational, so we chose Postgres" is an answer. "It is popular" is not. It is fine to say the team already knew a tool, as long as you also say why it suits the problem. If you are still choosing your stack, our guide to how to choose a final year project covers this.
Testing and results
- How did you test your system? How many real users tried it?
- How did you measure accuracy or performance?
How to answer: give numbers and the method behind them: test cases written and passed, users tested with, response times measured, accuracy on held-out data. "It works fine" is the answer that costs the most marks.
Limitations and future work
- What are the limitations of your project?
- What would you do with another six months?
How to answer: name two or three real limitations honestly, then say how you would address them. Examiners trust groups that know their weak points. Claiming there are none is a red flag.
Individual contribution
- What exactly did you build? Show us your code for this module.
- Explain a part your teammate built.
How to answer: know your own module in depth, down to the code, and know every other module well enough to explain what it does. Your Git history helps here: the GitHub contributors graph shows who committed what over time, which is one reason to commit from your own account from week one.
Questions you cannot answer
If you do not know, say so and say how you would find out: "I'm not sure; I would check it by measuring X." A confident wrong answer usually does more damage than an honest "I don't know".
Divide the presentation between team members
Every member should present something and answer questions on their own part. A group where one person does all the talking invites examiners to question the others harder.
| Role | Presents | Prepares for questions on |
|---|---|---|
| Member 1 | Problem, objectives, existing systems | Requirements, users, scope decisions |
| Member 2 | Architecture and tech stack | Design, database, why each tool |
| Member 3 | Live demo and key features | Implementation, integrations, code |
| Member 4 (if any) | Testing, results and limitations | Test method, numbers, future work |
Adapt the split to who actually built what. If your group has two members, combine the roles. Practise the handovers between speakers so nobody is unsure when it is their turn.
Handle nerves on the day
Nerves are normal and examiners expect them. What helps most is preparation you can fall back on when your mind goes blank.
- Know your first minute by heart. Once you are past the opening, the rest usually follows.
- Breathe slowly before you start. The NHS suggests breathing in through the nose and out through the mouth, counting to five each way, for a few minutes (NHS).
- Arrive early to set up the laptop, test the projector and open the demo.
- Pause before answering. Taking three seconds to think looks confident, not slow.
- Ask for the question again if you did not understand it. Answering the question you wish they had asked loses marks.
- Bring water and a printed copy of your slides and architecture diagram.
FYP presentation and viva FAQ
How long is an FYP presentation?
It depends on your department, and it often differs between the mid-term and final evaluations. Ask your FYP coordinator for the exact time for the presentation, the demo and the questions, then rehearse to it with a timer.
Are viva questions asked to each member separately?
Often, yes. Many panels question each member individually, including about parts they did not build. Prepare as if every member could be asked anything about the project.
Can I read from my slides or notes?
Short notes for numbers and names are usually fine. Reading paragraphs off the slides suggests you do not know the material, so keep slides brief and practise speaking around them.
What if someone else built most of the project?
Then the viva is where it shows. Buying, outsourcing or copying an FYP is academic misconduct, and examiners ask the questions that expose it. Get help understanding things, and build your own part yourself.
Key takeaways
- Follow your department's presentation format, time limit and viva procedure above any general guide.
- Use about 12 slides, one question each, with the demo after the architecture and before the results.
- Rehearse the demo on the real setup, remove dependencies on the room, and keep a recorded backup video.
- Prepare answers for each question group: problem, architecture, stack, testing, limitations and individual contribution.
- Give reasons and numbers, admit limitations honestly, and say "I don't know" rather than guess.
- Every member presents and knows the whole project, not only their own module.
Get ready for your FYP viva with a mentor
Softhat mentors final-year students at our Mardan, Khyber Pakhtunkhwa office or remotely, including mock presentations and viva practice with the hard questions examiners ask. You build the project and give the defence; we question, review and help you prepare. See FYP mentorship. If you are a batch behind and still choosing an idea, start with our final year project ideas for computer science or for IT students.
