Every semester, the same story repeats itself in many universities.
A student begins a Final Year Project with a familiar title. Smart Home System. Temperature monitoring. Humidity detection. Light and fan control. Sometimes, the project includes a camera, face recognition, mobile app, dashboard, and several colourful charts to make the presentation look more impressive.
On the day of the viva, the system works. The LED turns on. The sensor gives readings. The dashboard displays data. The student explains the flow from sensor to microcontroller, from microcontroller to cloud, and from cloud to dashboard. The panel members nod. The marks are given. The project is accepted.
Then, after the presentation, something predictable happens.
The hardware is dismantled. The jumper wires are removed. The sensors are kept in a box. The source code is uploaded into a Google Drive folder that may never be opened again. The report is submitted. The student graduates. The project that was once “alive” for one semester slowly disappears.
The next semester, another student arrives with almost the same idea.
Smart Home System.
Again.
The student buys new hardware, writes new code, builds a new dashboard, connects the sensors, tests the demo, prepares the report, presents the project, and completes the requirement.
Then the same cycle repeats.
This is not a small issue. It is a pattern that has existed for years. Many Final Year Projects do not grow beyond one semester. They do not mature. They do not become better from one batch to another. They are rebuilt again and again, often from the same starting point.
The Problem Is Not the Student
The student should not be blamed for this situation.
In many cases, students use their own money to buy the hardware. They purchase NodeMCU boards, Raspberry Pi units, temperature sensors, humidity sensors, relays, jumper wires, breadboards, cameras, power supplies, and enclosures. Some students spend a significant amount just to make sure their projects look neat, professional, and ready for demonstration.
For a student, that cost is not small. It may come from personal savings, family support, or monthly allowance. After the project is completed, it is reasonable for the student to take the hardware back. The components belong to the student, not the faculty or the laboratory.
This is where the problem begins.
When the next batch arrives, there is often nothing solid left behind. There may be a report. There may be a few photos. There may be source code stored somewhere. But there is usually no working system that can be continued. There is no structured documentation, no shared architecture, no common platform, and no clear roadmap.
The next student has no choice but to start from zero.
This raises an important question for universities: are they building knowledge, or are they repeating demonstrations?
Final Year Projects Are Often Treated as Standalone Work
One of the biggest weaknesses in many system-based FYPs is how they are evaluated.
The usual question is simple: “Does the system work?”
If the answer is yes, the project is considered successful. The sensor sends data. The dashboard displays the readings. The mobile app controls the device. The notification works. The report is complete. The student passes.
But for an IoT system, that question is not enough.
A better question should be: “Can this system be continued by another student after this semester?”
That question changes the entire meaning of the project.
If the system only works during the presentation, then it is not truly a system. It is a demo. It may be a useful demo, but it remains temporary. A real system should have continuity. It should have documentation. It should have a modular design. It should have data history. It should allow another person to continue, improve, test, and expand it.
Industry does not build systems that disappear after 14 weeks. A smart building system, energy monitoring system, fleet monitoring system, cold-chain monitoring system, or factory monitoring system must continue running after the first version is launched. It must be maintained. It must be improved. It must handle failures. It must respond to user feedback.
That is the difference between a project and a system.
Universities Need to Think in Systems, Not Projects
The first change needed is a shift in mindset.
Universities should stop treating every IoT FYP as an isolated project. Instead, they should design FYPs as part of a larger system that grows over time.
A Smart Home project is a good example.
Instead of asking one student to build everything from scratch, the faculty can divide the Smart Home system into several modules. One student can work on lighting and fan control. Another student can focus on energy monitoring. Another can build security alerts. Another can develop the dashboard. Another can work on mobile access. Another can add analytics. Another can study user behaviour and automation rules.
Each module can still become a valid individual FYP. Each student still has a clear scope. Each student can still be assessed fairly. The difference is that every project contributes to a bigger system.
At the end of the semester, the modules are integrated. The system is tested together. The data is stored. The documentation is updated. The problems are recorded. The next batch continues from that foundation.
Over time, the system becomes more mature.
A simple prototype can grow into a proper testbed. Basic sensor monitoring can grow into a complete smart living lab. A student project can slowly become a real system that can be tested in an actual environment.
That is how knowledge grows.
Not by restarting every semester, but by building layer upon layer.
The Laboratory Should Become a Living Testbed
A university laboratory should not only be a place where students come to complete assignments, prepare demos, and rush before submission week.
It can become a living IoT environment.
Imagine a lab where temperature and humidity are monitored every minute. Energy usage is recorded throughout the day. Lights and fans can be controlled through a dashboard. Alerts are sent when readings go beyond normal levels. Occupancy patterns are studied. Air quality is tracked. Equipment usage is monitored. Data is collected continuously across semesters.
Now imagine that this system is not built by one student, but by many students across many years.
That creates a very different learning experience.
A student from the fifth batch can say that the dashboard was first created by a senior three years earlier, and his or her contribution was to add analytics and improve the alert rules. Another student can improve the energy monitoring module. Another can add Telegram alerts. Another can improve access control. Another can clean up the data structure.
That is not just project work. That is contribution.
Students begin to see that their work matters beyond the viva. They know someone else will use, test, improve, and depend on what they have built.
That feeling changes the way students approach their projects. They become more careful with documentation. They write cleaner code. They think more seriously about reliability. They begin to understand that their work is part of a bigger story.
Someone Must Lead the Roadmap
This kind of continuity will not happen by accident.
There must be someone who leads it.
It can be one lecturer. It can be a small group of lecturers. It can be a research group. It can be a lab coordinator. What matters is ownership.
Someone must decide what modules should be developed each semester. Someone must ensure that students do not keep repeating the same scope. Someone must maintain the system architecture. Someone must keep the documentation alive. Someone must help new students understand what has already been done before they begin.
This work may not look glamorous.
It may not attract loud applause during an exhibition. It may not look as attractive as a shiny new prototype. But it is the kind of work that makes continuity possible.
Without leadership, every new FYP will return to the same old pattern. Students will build separately. Systems will not connect. Documentation will be forgotten. Hardware will disappear. The lab will become a museum of unfinished ideas.
A roadmap gives direction.
It tells students that they are not starting from zero. They are continuing something meaningful.
That is how real engineering discipline is developed.
Faculties Must Invest in Shared Hardware
Another issue that must be addressed is hardware ownership.
If every device belongs to an individual student, the system cannot survive. The hardware will leave when the student leaves. The lab will have no permanent foundation to build upon.
Faculties need to allocate a small but consistent budget for shared IoT hardware. It does not have to be expensive. What matters is that the hardware remains in the lab and belongs to the system, not to any individual student.
The faculty can maintain a standard set of microcontrollers, sensors, gateways, relays, power supplies, communication modules, and enclosures. These components can be reused across semesters. They can be labelled, documented, tested, and maintained properly.
This should not be seen as a cost. It should be seen as an investment.
The return is not only in the hardware itself. The real return is in the quality of learning. Students learn how to build systems that continue to run. They learn how to maintain existing work. They learn how to improve something created by others. They learn how to deal with real-world constraints.
That experience is far more valuable than building another temporary prototype that disappears after the final presentation.
Bridging Academia and Industry Requires a Better FYP Culture
Universities often speak about bridging the gap between academia and industry.
It is a good ambition, but it requires more than speeches, seminars, and industry visits.
The gap will not close if students only build short-term projects that die after one semester. In industry, a system does not end after a presentation. A system must be deployed, monitored, maintained, secured, improved, and supported.
If students are expected to understand how industry works, the university environment must expose them to that reality much earlier.
They must learn that writing code is only one part of the work. They must learn about documentation, system architecture, data quality, security, maintenance, user feedback, and long-term improvement. They must understand that a dashboard is not the final destination. The real value comes when the system helps people make better decisions and take action.
This is especially important in IoT.
IoT is not only about connecting sensors to the internet. It is about creating a chain from the physical world to meaningful action. Sensor data must be collected, transmitted, stored, visualised, analysed, and used. If students stop at “the data appears on the dashboard,” they are missing the deeper lesson.
An IoT FYP should teach students how to think like system builders, not just demo builders.
From One-Semester Demo to Long-Term Knowledge
The question universities should ask is not only, “Did the student complete the project?”
The better question is, “What remains after the project is completed?”
Does the next student have something useful to continue? Does the lab have a working system? Does the faculty have documentation? Is there data that can be analysed later? Are there problems recorded for future improvement? Has the system become more mature than it was before?
If nothing remains, then too much effort has been lost.
Students are being asked to climb the same hill again and again, when universities should be helping them build a staircase for the next batch.
A good FYP should produce more than a report. It should produce reusable knowledge. It should create a foundation that someone else can extend. It should leave behind working components, clean documentation, tested modules, and lessons learned.
That is how a university becomes a place where knowledge grows continuously.
The Future FYP Should Be a Contribution, Not Just a Completion
Universities need to rethink what an FYP should represent.
It should not be only a project that ends with a viva. It should not be only a requirement for graduation. It should not be only a demo that looks good for one afternoon.
A strong FYP should be a contribution to a bigger system.
It should help the next student move faster. It should help the lab become better. It should help the faculty build long-term capability. It should help the student experience a more realistic way of working.
When FYPs are designed this way, everyone benefits.
Students gain deeper practical experience. Lecturers gain stronger project continuity. Faculties build real testbeds. Industry receives graduates who understand how systems are built and maintained. Universities become known not only for producing projects, but for producing living knowledge.
If every FYP ends with the project, then the knowledge ends too.
But if every FYP becomes part of a larger system, the knowledge continues to grow long after the student graduates.
That is when universities can proudly say they are not just producing certificates.
They are producing builders, thinkers, and systems that continue to live.
Dr. Mazlan Abbas is the CEO of FAVORIOT and a recognised thought leader in IoT and digital transformation across Southeast Asia. Follow his work at iotworld.co and mazlanabbas.com.
Leave a Reply