Most final-year projects fail at the planning stage, not the coding stage. A simple way to pick a size that fits your semester.
A major project usually goes wrong long before the demo. The idea is too big, the parts arrive late, and the last two weeks turn into a scramble. Scoping well at the start saves most of that pain.
Start with one sentence
Write what your project does in one sentence a classmate would understand. "A tank sensor that alerts my phone before it overflows" is a project. "A smart IoT platform for water management" is a wish list.
Split it into must-have and nice-to-have
List every feature, then mark only the ones the demo cannot work without. Build those first. Everything else waits until the core works end to end.
- Must-have: read the sensor, show the level, send one alert
- Nice-to-have: history charts, multiple tanks, a mobile app
Plan around the parts list
Hardware is where schedules slip. Write the full parts list in week one, check what your lab already has, and order the rest early. Keep a spare of anything cheap and easy to burn out.
Set four milestones
- Parts in hand and each one tested on its own
- The core feature working end to end, even if ugly
- Tested with notes on what fails and why
- Report, slides and a practised demo
Put a date on each one and share them with your guide or mentor. If you miss the first milestone by more than a week, cut a nice-to-have now rather than later.
Know who does what
In a team, agree early who owns firmware, wiring, the dashboard and the report. It makes the work fairer, and it means everyone can explain their part honestly in the viva.
Ready for the next step?
Get mentor help with your project