Final-Year Project Planning Template

The problem statement identifies who faces the problem and why it matters.

The statement avoids broad claims such as solving an entire industry issue.

Existing solutions or manual processes are briefly compared.

The expected improvement is realistic and testable.

The problem can be explained in one minute during review.

Objectives are specific, action-oriented, and feasible within the deadline.

Each objective maps to a module, experiment, feature, or documentation output.

Objectives separate must-have outcomes from optional enhancements.

Technical objectives can be demonstrated or tested.

The objectives are not copied from a generic project description.

In-scope and out-of-scope features are listed clearly.

The minimum viable submission is defined.

Constraints such as time, tools, data, budget, and team skill are documented.

The scope supports a working demo rather than only a concept.

Optional stretch goals are separated from required deliverables.

Each module has a name, purpose, input, output, and owner.

Core modules are prioritized before cosmetic or advanced features.

Dependencies between modules are visible.

User-facing features are connected to actual user tasks.

Incomplete modules are not presented as fully working features.

Frontend, backend, database, deployment, analytics, model, or hardware tools are listed.

Technology choices are justified by use case, learning goals, support, and feasibility.

Version requirements and installation steps are noted.

The team can explain why each major technology was selected.

Risky or unfamiliar tools have fallback options.

The architecture diagram shows users, UI, services, database, APIs, models, and external tools where relevant.

Data flow is explained from input to output.

Authentication, permissions, storage, and security concerns are considered if applicable.

Architecture matches the actual implementation, not an idealized diagram.

The team can explain tradeoffs and limitations.

Datasets, APIs, libraries, hardware, sensors, accounts, or hosting resources are listed.

Licensing, quotas, pricing, rate limits, privacy, and permission constraints are checked.

Sample data is available for development and testing.

The project has a fallback if an API or dataset becomes unavailable.

Sensitive data is handled according to institutional and legal expectations.

Milestones include planning, prototype, core implementation, testing, documentation, demo, and final review.

Each milestone has an output that can be shown to a supervisor or mentor.

High-risk tasks are scheduled early.

Buffer time is included for bugs, feedback, and documentation.

The timeline is updated when scope changes.

Each week has specific build, test, documentation, and review tasks.

Completed work is recorded with screenshots, commits, notes, or demo clips.

Blockers are documented with attempted fixes.

Team responsibilities are clear for group projects.

Supervisor feedback is converted into action items.

Required chapters or report sections are listed.

Architecture, method, implementation, testing, results, limitations, and future work are planned.

Screenshots, diagrams, code snippets, and references are collected during development.

The report explains decisions and learning, not just features.

References, citations, and reused code or assets are credited.

Functional tests cover core user flows or system functions.

Edge cases, invalid inputs, failures, and security risks are considered where relevant.

Model, algorithm, or data projects include evaluation metrics and baseline comparison if applicable.

Testing evidence is captured for the report and viva.

Known limitations are documented honestly.

The demo opens with problem, objective, and architecture before showing features.

The sequence follows the main user or system flow.

Sample accounts, data, devices, internet, and backup files are ready.

A fallback recorded demo or screenshots are prepared for technical failure.

The presenter can explain what is working, partially working, and planned future work.

The team can explain problem, objectives, scope, architecture, tech stack, and limitations.

Each member can explain their own contribution honestly.

Common questions about errors, alternatives, security, testing, and future work are practiced.

Evidence files such as code, commits, test results, and diagrams are organized.

The team avoids claiming features or expertise they cannot defend.

Technical, data, API, hardware, team, and timeline risks are listed.

Each risk has a prevention step and backup option.

The minimum viable version can still be submitted if advanced features fail.

Dependencies outside the team's control are monitored early.

Risk decisions are documented for transparency.

Code, report, presentation, demo files, installation steps, and datasets are organized.

The report matches the actual project implementation.

All reused code, assets, datasets, and libraries are acknowledged.

Screenshots, diagrams, testing evidence, and limitations are included.

Submission files meet department format and deadline rules.