Projects and Teams
Every capstone team works one project for three terms with one project partner or mentor. This page covers how that project and that team come to exist, and what happens if either has to change.
How Projects Are Proposed
Section titled “How Projects Are Proposed”Project partners (industry, faculty, staff, entrepreneurs) and students submit projects through the same portal. The instruction team reviews each one and lists the approved projects before fall week 0.
- Deadline. Submissions close when fall term starts; the earlier they arrive, the more time we have to help you refine them.
- Category. Every project belongs to one of the four project categories, and the category decides how the project partner evaluates the outcome.
- Student proposals. A student may submit a project of any category, but it needs a project partner or an approved mentor. If it is accepted, the student and any teammates named in the proposal are assigned to it automatically; it may not appear in the public list at all.
- IP and NDA flags. A proposal states whether it requires an intellectual property agreement, a non-disclosure agreement, or both (see IP, NDA, and Licensing below).
How Teams Form
Section titled “How Teams Form”Students bid on projects in a survey before the term starts, and the instruction team announces the teams in fall week 1 (the schedule has the week). We aim for teams of 3 to 4 students; real teams range from 2 to 5 depending on enrollment and project needs, and the instructors balance skills and preferences across all teams.
- Bidding is the default. You rank the projects; we do our best to place you on a top choice. That is not a guarantee.
- Friends. Rank the same projects in the same order. Still not a guarantee. The only sure way to be on a team with your friends is to propose a project together before the term starts.
- Reserving a spot. Not possible, with two exceptions: you submitted the project, or your project partner submitted it in collaboration with you.
- Asking a partner beforehand. Some project descriptions say you may contact the partner with questions. That is information, not a reservation; the instruction team places students.
- Every team has an external partner. Research and Consultancy projects have one by definition. New Product or Game and FOSS projects must find one or more mentors (faculty, industry professionals, or anyone who can move the project forward). Mentors are approved by the instruction team and evaluate the team every term; their evaluation carries the same weight as a project partner’s (Project Partner Evaluation), so align expectations with them in the first meeting.
- Outside the cohort. A CS team may collaborate with a separate ECE capstone team on a shared project, collaborate with a research group, or work with people from other colleges, professional organizations, and online communities. Joining an ECE or multidisciplinary (ENGR) team outright means enrolling in that section instead of this one.
Once the teams are announced, the first move is to meet your project partner or mentor. Start from the introduction email template, then clarify the project, the expected deliverables, and the timeline, and walk them through the assignments they will see this term.
IP, NDA, and Licensing
Section titled “IP, NDA, and Licensing”Students hold the intellectual property of the work they produce during capstone, unless the project was flagged as requiring an IP agreement. Ideas belong to whoever proposed the project. Discuss IP and licensing with your partner in the first sprint, even if the project will be open source; choosealicense.com is the reference, and closed source is a valid choice if you intend to commercialize.
Instructors cannot sign an IP agreement or an NDA. A team under NDA is assessed through live walkthroughs and sanitized evidence; the assignments overview has the mechanics, and the points are identical either way.
Changing Teams
Section titled “Changing Teams”Changing teams requires your instructors’ approval. It disrupts both teams, so it happens only when the alternative is worse. If a concern is building, talk to your TA or instructors as soon as possible; most team problems are solved earlier and cheaper through the conflict guide than through a transfer.
Reasons that have justified a change: a conflict that mediation could not resolve; a skills mismatch so large that the student would clearly contribute more elsewhere; a multi-team project that needs its people rebalanced.
The process:
- Write to the instructor: the reasons, and what you already tried inside the team.
- The instructor talks to everyone involved and decides.
- If approved, both teams agree on a transition plan covering responsibilities, knowledge, and in-flight work, and the reasons, the decision, and the plan are written down.
A student who changes teams is assessed on their contributions to each team for the time they were on it; the assignments overview states the roster-change rule. The grade may be adjusted based on the impact of the change on both projects.
Changing or Pivoting Projects
Section titled “Changing or Pivoting Projects”Pivoting or changing projects requires your instructors’ approval and may require finding a new project partner or mentor. Teams pivot for reasons like ill-defined requirements, no product-market fit, a problem that turns out to be infeasible, data that cannot be obtained, a disagreement over IP terms, or an irreparable conflict with the partner. Front-load the discovery work that surfaces those risks: the requirements guide and the Find Users activity exist for this.
Your grade is based on the project you present at each milestone, with the same standards throughout. The later you pivot, the less runway you have; teams that wait until winter or spring to pivot rarely recover. If you suspect a dead end, say so in the next sprint note and cohort check-in.
To pivot:
- Write down the current path, why it is not viable, and how the new direction fixes that.
- Revise the plan: scope, timeline, roles, given how much of the year is left.
- Get the instructors’ approval and bring your project partner and mentor along. They evaluate your work; do not leave them in the dark.
- Restart from whichever point the new direction requires, and expect extra effort.
Abandoning a project is rare and usually means the project should not have been approved. A team that invested substantial effort before external factors beyond its control ended the project may receive partial credit, on the strength of an exhaustive post-mortem submitted to the instructors.