What to expect¶

What the team will produce for you, when it arrives, and what seven weeks of second-year undergraduate effort realistically buys. Read this before you write the brief, not after.

What lands in your inbox, and when¶

Five documents and a demonstration. Each formal document is a PDF, emailed to you before noon on the day preceding the relevant meeting, and copied to the project organisers for assessment.

Functional Specification and Project Plan

Week 2 — draft ≥24 hours before Meeting 2, final within 24 hours after

The single most important document you will receive. It sets out the problem as the team understands it, the functionality to be provided, the major components and their interfaces, the acceptance criteria for the finished product, the group's management strategy, and the technical contribution each member will make. The plan assigns tasks with time estimates and dependencies.
Progress Report 1

≥24 hours before Meeting 3, week 4

A written progress update, as a PDF, ahead of your third meeting.
Progress Report 2

≥24 hours before Meeting 4, week 6

A second written progress update ahead of your fourth and final meeting.
Video presentation

By noon, Thu 11 Mar 2027

No more than four minutes. It introduces the project, highlights the technical challenges and the team's solutions, and demonstrates the project working. Videos are published for staff, clients and students to watch and vote on.
Final Group Report

By Wed 17 Mar 2027

Describes the project's successes and failures, elaborates on lessons learned, and documents the work done by each member of the team including their specific technical contributions.
A demonstration at the exhibition

Wed 17 Mar 2027

Every project is demonstrated at a public exhibition on the last Wednesday of Lent term, alongside the screening and awards.

Meeting 2 is where the scope is fixed

If the scope looks wrong, say so at Meeting 2. After this point the team is working to a fixed budget and a fixed end date.

What seven weeks actually buys¶

The single most common cause of a disappointing project is a brief scoped for a professional team working full time. These are the constraints the students are working inside.

Budget: 60 hours per member

The project plan must work to a budget of no more than 60 hours per person, and the course expects 30–60 hours of work each, spread over seven weeks. Multiply by your team size for the total engineering effort available — then assume a good part of it goes on learning, co-ordination and writing.

Seven weeks, and a hard stop

Building runs from week 1 to the code freeze at noon on Thursday 11 March 2027. No credit is given for features added after that, so development genuinely stops — there is no quiet extra fortnight.

Students are assigned, not recruited

Group membership is decided by the department. Students express preferences but there is no guarantee they get them, so your team may not have chosen your project. They are second-year undergraduates working alongside a full lecture load.

The briefs are meant to be ambitious

Design briefs are deliberately intended to push the bounds of what students can achieve, often involving new technologies, substantial engineering effort, or research problems that have never been solved before. Expect a strong prototype, not a production system.

It is assessed as learning, not delivery

Credit is awarded for working effectively as a team, maintaining a professional relationship with the client, and each member making a substantial technical contribution. A project can succeed academically without shipping everything you hoped for.

You do not automatically get the code or the IP

The repository is submitted to the examiners via Moodle. Ownership of copyright in the source code and any other intellectual property is something to discuss and agree with the team — the organisers can advise if asked.

Doing the arithmetic

The course caps each student at 60 hours and expects 30–60 hours of work, spread across seven weeks alongside a full lecture load. Multiply by your team's size to get the ceiling on total effort — then remember that a real share of it goes on learning unfamiliar technology, co-ordinating as a group, and writing the four documents you will receive. The time actually spent writing product code is a fraction of the headline figure.

What a good outcome looks like¶

Reasonable to expect

A working prototype that demonstrates the core idea end to end; a clear written specification of what was built; honest documentation of what worked and what didn't; a four-minute video demonstrating it running; and a team that has engaged seriously with your problem.
Not reasonable to expect

Production-ready, deployed, maintained software; comprehensive test coverage or security hardening; ongoing support after the code freeze; work delivered to a contractual specification; or any guarantee of a particular feature set — the scope is agreed with the team at Meeting 2, not fixed by your brief.

How the students are actually assessed

Four ticks: one to the whole group for the project succeeding, and three to each student individually — for working effectively with their team, maintaining a professional relationship with their client, and personally making a substantial technical contribution. Performance is not assessed relative to other students, and the expectation is that everyone receives all four. Your role is to be a good client, not to grade them.

Code, intellectual property and what happens next¶

You are not automatically given the code or the rights to it

The repository is submitted to the examiners via Moodle — that is an assessment submission, not a delivery to you. Ownership of copyright in the source code and any other intellectual property is a matter to discuss and agree with the team. If you need particular rights, raise it early — ideally in the brief and again at Meeting 1 — rather than after the project has finished. See Intellectual Property.

Agreeing it fairly

If work is taken forward, every member of the team needs to agree they have been fairly treated. That means discussing who holds copyright in the source code or other IP, and how any revenue should be fairly divided. The organisers can advise if asked.
Ways projects continue

Publishing the code as open source or contributing it upstream; licensing it to a company, charity or school; a student visiting your organisation to transfer what they learned; a summer internship between Part IB and Part II; or a Part II individual project developing the ideas further.
Hardware you lent

If you lend equipment it must all be returned at the end of the project. The group's final tick is not awarded until it has been, so it is worth confirming the handover directly with the team.
When the course ends

The formal course and assessment end once personal reports are in and ticks are decided. Anything after that is between you and the students — it does not affect their marks, but it can still be valuable to everyone.

A professional relationship, in both directions¶

What the course expects

One of the three individual ticks is explicitly for maintaining a professional relationship with the client. Students are being assessed on how they work with you — which makes prompt, clear, respectful communication from your side part of what makes that possible.
If something goes wrong

The department will not tolerate offensive or inappropriate behaviour, including bullying or harassment. If you have a concern about a team — or about anything else — contact the organisers at group-project@cl.cam.ac.uk. Correspondence is read by the organising team.