Chapter 8 of 8 · 5 checks · 3 min
Timeline checkpoints
Fixed checkpoints across the year stop work from bunching at the end. Put your department's dates in the calendar and check the team against each one.
Put every department deadline in a shared calendar on day oneMust
Why it matters and how to check
Collect every date from your handbook and FYP coordinator: group registration, proposal submission and defence, mid evaluations, report drafts, similarity check submission, final report and final evaluation. Add them to a shared calendar with reminders a week before each.
The University of Lahore's Islamabad campus guidelines, for example, place a proposal deadline early in the semester and deduct marks for late submission. Missing a fixed date is the easiest way to lose marks. Check it is done: every department deadline is in a shared calendar with a reminder.
Do
- Add every department date to a shared calendar
- Set reminders a week before each deadline
Avoid
- Relying on one member to remember deadlines
By the proposal deadline: team, supervisor, agreement and approved scopeMust
Why it matters and how to check
Before the proposal is submitted, the team should have: a confirmed group meeting the department's rules, a supervisor who has read the draft, a signed team agreement, a shared repository and task board, and a proposal with a must list that fits the calendar.
Check it is done: each of these exists and can be shown to the supervisor.
Do
- Confirm group, supervisor, agreement, repository and board
Avoid
- Submitting a proposal the supervisor has not read
By the mid evaluation: core flow working end to end and a draft reportMust
Why it matters and how to check
By the mid evaluation, the core user flow should run end to end, even roughly, and the requirements and design documents should be done. Many departments expect a substantial report draft by the later checkpoints; the University of Lahore's Islamabad campus guidelines, for instance, ask for a report 80% complete before the second mid evaluation.
Check it is done: you can demo the core flow from start to finish and the report has drafts of the early chapters.
Do
- Demo the core flow end to end
- Have requirements, design and early report chapters drafted
Avoid
- Many unconnected screens with no working flow
Freeze features a few weeks before the final evaluationShould
Why it matters and how to check
Agree a feature freeze date two or three weeks before the final evaluation. After it, the team only fixes bugs, improves tests, finishes the report, prepares slides and records the backup demo video.
New features after the freeze are the most common cause of broken final demos. Check it is done: the freeze date is in the calendar and no new feature branches are opened after it.
Do
- Set a freeze date two or three weeks before the final
- Use the time after the freeze for testing, report and rehearsal
Avoid
- Adding features in the final week
Before final submission: complete package checked by every memberMust
Why it matters and how to check
A week before the final deadline, assemble the full package your department needs: final report, source code or repository link with README, any similarity report, signed declarations and approval pages, and any required copies or media. Each member checks it, including their own sections and code.
Tag the submitted version in Git so you can show exactly what was submitted. Check it is done: every item on the department's submission list is ready, and the submitted version is tagged.
Do
- Assemble the full package a week early
- Tag the submitted version in Git
Avoid
- Discovering missing signatures on the deadline day