Project lifecycle

Academia is designed to manage the full academic project lifecycle from early group formation to final defense. This page explains that lifecycle as a practical sequence and maps each stage to the roles that act in it.

Fastest route through this guide

• Start with Lifecycle at a glance if you need the eight stages quickly.
• Read Real operating sequence if you want the practical order departments follow.
• Open the linked deep-dive pages when you need one phase in operational detail.

The current frontend and backend already show a clear operating model:

1. Department setup and workflow preparation
2. Student group formation and approval
3. Proposal drafting and submission
4. Proposal review and project creation
5. Advisor assignment and project activation
6. Milestone delivery and review
7. Evaluation and defense preparation
8. Final defense and outcome tracking

Lifecycle at a glance

Stage	Main purpose	Primary roles
1. Setup	Prepare templates, rules, and department readiness	Department head, coordinator
2. Group formation	Students form approved project groups before proposal work begins	Student, coordinator
3. Proposal	Approved student group leaders create and submit a project idea	Student
4. Review	Proposal is reviewed and either approved or rejected	Coordinator, department head
5. Project activation	Approved proposal becomes a real project and gets an advisor	Coordinator, department head, advisor
6. Milestones	Students deliver work step by step and advisors review it	Student, advisor
7. Evaluation	Evaluators and committee members review assigned projects and prepare scoring	Evaluator, committee member, coordinator, advisor
8. Defense	Defense sessions are scheduled, completed, and recorded	Student, evaluator, committee member, coordinator, advisor, department head

Deep-dive paths from this page

If you need to understand...	Open this page
how students become approved groups before proposals start	Student group formation and approval
how proposals become approved projects	Proposal review and approval
how students upload work and advisors review it	Milestone delivery and advisor review
how evaluators score projects and defenses are tracked	Evaluation and defense workflow
how coordinators and department heads manage assignment health	Staff oversight and assignment

Stage 1: Department setup and workflow preparation

Before projects start, the department has to be ready to run them.

What happens here

• department head completes onboarding and verification
• department configuration is reviewed
• academic phases and policy defaults are prepared
• milestone templates are created or reviewed
• faculty and staff are invited into the department

Role ownership

• Department head: owns department readiness, invitations, and policy surfaces
• Coordinator: may help configure department-level workflow, milestone templates, and operational settings

What the backend supports

The backend already supports department milestone templates and default milestone generation. The default department template includes a five-step flow such as:

1. Project Proposal
2. SRS
3. SDD
4. Implementation & Testing Report
5. Final Defense

Stage 2: Student group formation and approval

Before any proposal can be submitted, students have to become an approved project group in the platform.

What happens here

• student applies to become a group leader when needed
• approved group leader creates a draft group
• students join through invitations or join requests
• the group leader submits the completed group for department review
• coordinator reviews the submitted group and the team becomes officially approved

Role ownership

• Student: applies, creates or joins groups, manages membership, and submits the group for approval
• Coordinator: reviews submitted groups for official registration
• Department head: may oversee policy and readiness around group formation

What the backend supports

The current student group flow already includes:

• group leader request endpoints
• group creation for approved group leaders only
• group invitations and join requests
• group submission for review
• group approval or rejection by department reviewers

Why this matters

The proposal flow does not begin from an isolated student account. It begins from an approved group structure that the platform treats as the project unit.

For the detailed early student workflow, see Student group formation and approval.

Stage 3: Proposal drafting and submission

This is the point where an approved student group leader starts the academic work.

What happens here

• student creates a proposal draft
• the proposal contains exactly three candidate titles
• the student uploads the proposal PDF
• the student submits the proposal for review

Role ownership

• Student: creates the draft, uploads the file, and submits it
• Coordinator and department head: receive the submitted proposal for review

What the backend supports

The backend proposal flow includes:

• POST /projects/proposals for proposal draft creation
• upload-first flow with proposal PDF support
• POST /projects/proposals/:id/submit for review submission
• notifications to coordinator and department head when a proposal is submitted

What the frontend shows

The student upload and submissions flows already describe proposal-first behavior clearly. The upload page switches into a dedicated proposal mode and requires the proposal PDF before final submission.

Stage 4: Proposal review and decision

Once the proposal is submitted, it moves into a department review stage.

What happens here

• coordinator or department head reviews the proposal package
• reviewer can add feedback comments before the final decision
• proposal is approved or rejected
• if rejected, the group revises and resubmits

Role ownership

• Coordinator: primary operational reviewer in the main proposal-to-project flow
• Department head: can also review and decide on submitted proposals
• Student: receives decision and feedback, then revises if needed

Important system behavior

Approval is not just a status change. In the current backend flow, approving a proposal creates a real project immediately.

That means the lifecycle moves from idea review into active project management without a manual second data entry step.

Stage 5: Project creation and advisor assignment

After approval, the proposal becomes an active project.

What happens here

• backend creates the project from the approved proposal
• project may initially exist without an advisor
• coordinator or department head assigns an advisor immediately or later
• project inherits or applies a milestone template

Role ownership

• Coordinator: often handles proposal approval flow and advisor assignment
• Department head: may also approve or assign depending on the department workflow
• Advisor: becomes the supervising owner for the active project

What the backend supports

• proposal approval can return a real project.id
• advisor assignment is handled by project advisor assignment endpoints
• milestone template application can happen at project creation time

Why this matters

This stage connects academic approval to real delivery work. After this point, the system stops tracking only a proposal and starts tracking a managed project with milestones, members, and supervision.

Stage 6: Milestone delivery and advisor review

This is the longest part of the lifecycle and the one students experience most often.

What happens here

• students see project milestones on their dashboard
• each milestone has its own due date and status
• students upload milestone deliverables
• advisors review submissions, approve them, or request revision
• progress is updated as milestones move forward

Role ownership

• Student: uploads deliverables and resubmits when required
• Advisor: reviews milestone work, gives feedback, approves, or requests revision
• Coordinator and department head: monitor progress at a department level

Important system behavior

The backend and docs already describe a stepwise or sequential milestone rule:

• Milestone 2 cannot move forward until Milestone 1 is approved
• Milestone 3 depends on Milestone 2, and so on

This creates a controlled academic progression instead of a loose document dropbox.

For the detailed milestone loop, see Milestone delivery and advisor review.

Stage 7: Evaluation readiness and evaluator workflow

Once the project is mature enough, it enters evaluation-oriented work.

What happens here

• advisor clears the project toward evaluation readiness
• evaluator receives assigned projects
• committee members receive defense-stage review context when required
• evaluator reviews documents, project details, and scoring history
• committee members review materials needed for committee participation and final discussion
• evaluation moves through states such as pending, in progress, submitted, and reviewed

Role ownership

• Advisor: prepares the project for evaluation readiness
• Evaluator: reviews, scores, and submits evaluation work
• Committee member: joins committee-facing review and participates where the department uses committee workflows
• Coordinator: tracks evaluation readiness and evaluator progress

What the frontend shows

The evaluator dashboard already centers on:

• evaluation pipeline status
• assigned projects
• upcoming schedule
• evaluation actions and reports

The product also exposes committee-facing workspaces so late-stage review is not limited to the evaluator role alone.

For the detailed late-stage workflow, see Evaluation and defense workflow.

Stage 8: Defense scheduling and final defense

The last major stage is defense preparation and execution.

What happens here

• defense sessions are scheduled
• students prepare required defense materials
• evaluators and committee participants see the schedule
• scoring and final review are completed around or after the defense session
• outcomes become visible in reports and final records

Role ownership

• Student: prepares the required material and appears for the defense session

• Evaluator: completes formal review and scoring responsibilities

• Committee member: participates in committee review and decision support during the defense stage

• Coordinator: manages logistics, timing, and readiness

• Advisor: supports readiness and academic continuity around the defense

• Department head: oversees department-level completion and governance visibility

• Student: prepares the presentation, materials, and defense readiness items

• Evaluator: joins the scheduled defense and submits evaluation output

• Coordinator: manages or monitors defense scheduling and readiness

• Advisor: supports readiness and often participates in the defense context

• Department head: keeps oversight on the final stage and outcomes

What the frontend shows

The student dashboard includes a defense page and materials checklist. The evaluator workspace also includes defense schedule pages and evaluation preparation actions.

This stage is also covered in Evaluation and defense workflow.

End-to-end role view

If you read the lifecycle by role instead of by stage, the flow becomes:

Department head

• prepares the department
• oversees proposal decisions and department operations
• monitors quality, policy, and reporting

Coordinator

• manages proposal review operations
• assigns advisors and tracks readiness
• coordinates evaluation and defense activities

Advisor

• supervises the active project
• reviews milestone submissions
• helps move the project toward evaluation readiness

Student

• applies to become a group leader or joins a group
• reaches approved group registration
• creates the proposal
• submits milestone work
• responds to feedback
• prepares for final defense

Evaluator

• reviews assigned projects
• submits scores and evaluation outcomes
• participates in scheduled defense sessions

Real operating sequence

For a department using the platform in practice, the most natural sequence is:

1. Department head sets up the department and invites users.
2. Students form groups and submitted groups are approved.
3. Approved student group leaders create proposal drafts and submit them.
4. Coordinator or department head reviews proposals.
5. Approved proposals become real projects.
6. Advisors are assigned.
7. Students work through milestones and advisors review them.
8. Evaluators receive ready projects and complete scoring.
9. Defense sessions are scheduled and completed.

Related pages

• Onboarding and first setup
• Roles and dashboards
• Student group formation and approval
• Proposal review and approval
• Milestone delivery and advisor review
• Evaluation and defense workflow
• Overview
• Architecture

Best next reads

• Start with Onboarding and first setup if you are documenting first access for a new department.
• Open Roles and dashboards if you want the same platform explained by user role instead of by lifecycle stage.
• Move into Student group formation and approval if you want the real student starting point before proposals.
• Move into Proposal review and approval if you want the first operational deep dive after this overview.