The real product of computing education
Every profession is ultimately judged by the capability of the people it produces. Medicine produces physicians. Law produces advocates. Engineering produces engineers. Computing education should therefore be judged not by the number of software projects completed each year, but by the number of graduates capable of engineering digital systems that organisations trust, adopt and continuously improve.
Universities do not supervise computing projects because society needs more undergraduate software. They supervise them because society needs graduates capable of engineering digital systems long after graduation. This distinction has become one of the defining educational questions of the artificial intelligence era.
A project model designed for another era
For decades, the final-year project has served computing education well. Students identify problems, review literature, gather requirements, design systems, develop software, document their work and defend it before panels. In principle, the model is sound. In practice, computing itself has moved faster than the educational architecture through which future computing professionals are developed.
Programming evolved into software development. Software development matured into software engineering. Software engineering became a foundation of digital transformation. Artificial intelligence is now reshaping how software is conceived, developed and maintained. Through this evolution, the professional value of computing has shifted steadily away from writing code alone towards engineering complex socio-technical systems.
What More Than a Decade of Project Supervision, Examination and Assessment Reveals
Universities supervise hundreds of computing projects every year, yet many begin where previous projects began rather than where previous projects ended. After more than a decade of supervising, examining, marking and serving on project defence panels across several universities in Ghana, I have repeatedly observed patterns that deserve serious academic and policy attention.
Across institutions, similar organisational problems frequently reappear with remarkably similar system architectures, database designs, user interfaces and documentation. In some instances, substantially similar systems have appeared in different universities. Rather than extending the engineering achievements of previous cohorts, many projects restart the same journey, raising important questions about originality, engineering ownership and cumulative innovation.
Methodology presents a similar concern. Agile software development is frequently identified as the adopted methodology, yet many reports provide little evidence of iterative planning, stakeholder feedback, sprint reviews or progressive system refinement that characterise authentic Agile practice. Methodology is increasingly described rather than demonstrably applied.
Literature reviews frequently summarise existing knowledge but often remain insufficiently connected to requirements engineering, architectural decisions and implementation. Research evidence therefore does not consistently become engineering evidence.
Perhaps the greatest weakness lies in problem understanding. Students are often expected to engineer software for organisations they have had limited opportunity to study systematically, users they have seldom observed and operational workflows they have rarely validated.
Under such conditions, software engineering risks becoming an exercise in technological construction rather than organisational transformation.
Current project timelines further compound the challenge. Meaningful engineering often begins only after topic approval and proposal defence, leaving limited time for sustained organisational engagement, iterative development, validation and refinement. Professional software matures through continuous evolution; many undergraduate projects instead encourage completion rather than engineering maturity.
Taken together, these observations point not simply to shortcomings of individual students but to structural characteristics of the educational architecture through which universities organise computing project work. The diagnosis is therefore architectural, providing the foundation for the discussion that follows.
AI is not the deepest problem
Artificial intelligence has not fundamentally changed the educational purpose of computing projects. It has fundamentally changed the level of evidence required to demonstrate authentic engineering capability. AI can assist with code, documentation, explanation, design and debugging. Used responsibly, it can strengthen learning. The deeper danger is not AI itself, but a project model in which submitted artefacts can be mistaken for engineering capability.
If a student uses AI but can explain the architecture, validate the requirements, debug the code, justify design decisions and improve the system, learning may still occur. Outsourcing is more damaging because the engineering process itself is transferred away from the student.
The student may submit software, but the educational process that should produce engineering capability has been bypassed.
Software development is not software engineering
Software development answers the question, 'Can this system be built?' Software engineering asks the more demanding question, 'Should this system be built in this way, for these users, within these organisational, ethical, regulatory and operational constraints?' Many universities still organise computing project education around software production, while employers increasingly recruit engineering capability.
Modern organisations do not only need graduates who can produce functional screens, dashboards and database tables. They need professionals who can investigate problems, engage stakeholders, understand workflows, manage cybersecurity risks, design resilient architectures, evaluate alternatives, validate with users and exercise sound engineering judgement. The project is not the educational product. The engineer is.
Engineering Capability and Engineering Evidence
The central objective of computing project education should be Engineering Capability: the ability to investigate, design, implement, validate, defend and continuously improve digital solutions in real contexts. Engineering Evidence is the proof of that capability. It is the cumulative record showing that engineering judgement, rather than software production alone, shaped the evolution of a digital solution.
Engineering Evidence is reflected in problem discovery, stakeholder engagement, requirements evolution, architectural reasoning, implementation history, testing, validation, deployment planning and continuous improvement. It demonstrates not merely that software exists, but that genuine engineering has taken place.
Why computing has become multidisciplinary
Software did not become multidisciplinary because universities introduced interdisciplinary education. Universities introduced interdisciplinary education because software itself became multidisciplinary. Digital systems now operate within healthcare, finance, education, agriculture, logistics, public administration, governance and industry. They carry legal, ethical, financial, operational and human implications.
The computing student remains central to architecture, implementation, integration, security, testing and deployment. However, a student cannot be expected to invent the legal model, financial controls, marketing logic, organisational workflow, communication strategy and adoption pathway alone. Real systems require real domain intelligence. This is why project work must increasingly move from isolated technical exercises to multidisciplinary project engineering.
Time, continuity and industry reality
The current timeline also weakens project quality. A project may formally span an academic year, but meaningful implementation often begins late, after topic approval, proposal writing and proposal defence. By then, students have limited time for fieldwork, requirements validation, system design, implementation, testing, deployment and user feedback. A serious computing project cannot be treated as a short academic ritual if universities expect industry-relevant outcomes.
Project work should begin earlier and mature progressively. Students should encounter problem discovery, field observation, prototyping, version control, testing, deployment and validation before the final year. Project portfolios, industry problem banks and continuity across cohorts can reduce repetition and turn student work into institutional memory. One cohort may validate a problem, another may build the prototype, another may improve architecture, another may test adoption and another may commercialise or publish the outcome.
Industry must also move from ceremonial observer to co-engineer. Organisations named in project titles should help validate problems, review requirements, comment on prototypes and evaluate usefulness. Academic grading remains the responsibility of universities, but industry can provide the operational reality that makes software meaningful.
Ghana’s opportunity
Ghana has an opportunity to contribute meaningfully to this international conversation. Thousands of undergraduate computing projects represent substantial intellectual capital. Properly organised, they can evolve into institutional digital assets, research platforms, innovation pipelines, startup opportunities and enduring university-industry partnerships that strengthen national engineering capability.
The issue should not be framed as institutional embarrassment. It should be framed as national opportunity. The same conditions that expose weaknesses in the current model also create the urgency to design a better one. Ghanaian universities can move from producing isolated final-year submissions to building structured ecosystems that produce engineers, prototypes, research outputs, startups and deployable solutions.
The conversation must change
Universities have spent decades refining how computing projects are organised, supervised and evaluated. The next decade must be devoted to refining how computing professionals are developed. The universities that will shape the future of computing education will not necessarily be those that supervise the largest number of projects. They will be those that develop the largest number of graduates capable of engineering digital systems that organisations trust, adopt and continuously improve.
The question before higher education is therefore no longer whether the final-year project should change. It is whether the architecture through which universities develop Engineering Capability remains fit for a profession that is transforming faster than any educational model built to serve it. My next article introduces an integrated computing project engineering ecosystem that offers one possible direction for that transformation.
The writer Augustina Dede Agor, PhD (is a Senior Lecturer in the Department of Information Technology Studies at the University of Professional Studies, Accra (UPSA).
