In this guide
Most team-project friction is not about effort — it is about ownership. When four people share every task, nobody can answer for anything, and the group viva exposes it within minutes. The fix is simple: divide the project into ownable components, not tasks.
Components, not tasks
A task is "do the research" or "make the PPT" — shared, vague, and impossible to defend. A component is a vertical slice of the system that one person owns end to end: the hardware build, the firmware, the cloud dashboard, the documentation. In the group viva, examiners ask each member about their piece. "I owned the sensor interfacing and calibration" is a defensible answer. "We all did a bit of everything" is not.
Warning: The most common failed split is dividing by phase — everyone researches, everyone builds, everyone writes. It feels fair and produces a project nobody fully understands. Divide by component, so understanding has an owner.
Size the components to your team
Aim for roughly one substantial component per member, plus documentation shared or assigned explicitly. Uneven slices are fine as long as they are agreed upfront — a documentation-heavy component can balance a hardware-heavy one.
| Team size | Example split |
|---|---|
| 2 | Member A: hardware build + sensor interfacing. Member B: firmware/cloud + report writing. |
| 3 | Member A: hardware. Member B: firmware + mobile app. Member C: cloud dashboard + documentation. |
| 4 | Member A: hardware. Member B: embedded firmware. Member C: cloud/backend + app. Member D: testing + full documentation. |
If a component is clearly twice the work of the others, split it — "firmware" can become "sensor firmware" and "communication firmware." The test is always the same: can one person explain their component's design decisions, failures, and fixes without help? If not, the slice is wrong. And check the split against your feasible timeline — a four-component architecture with three weeks left is a plan to fail.
Match report sections to ownership
The project report should mirror the split. Each member writes the sections covering their component: design, implementation, testing, and results for their slice. One person — usually the documentation owner — edits for consistency, but nobody writes about a component they did not build. This has two benefits: the writing is accurate because the builder writes it, and every member has genuinely read and understood the part of the report they will be questioned on. Shared sections (abstract, introduction, conclusion) are drafted together or by the documentation owner from everyone's notes.
Handle late members with a written agreement
Decide before you start what happens if someone falls behind — not during the crisis. A practical agreement covers three points: a weekly check-in where each member demos progress on their component, a rule that anyone blocked for more than a few days asks for help immediately, and a rebalancing clause — if a component slips badly, the team redistributes it rather than letting it sink the submission. Put the split and these rules in writing, even if it is just a shared document everyone signs off on. When everyone agreed upfront, rebalancing feels like process, not betrayal.
Tip: Write the split down in the first week and share it with your guide. A one-page component list with names next to each item prevents most "but I thought you were doing that" arguments — and guides respect teams that arrive with a plan.
Solo projects: a legitimate choice
Going solo is not a fallback — for some students it is the better option. You keep full ownership, every design decision is yours to defend, and there is no coordination overhead. The trade-off is scope: one person cannot build a four-component system in the same time. If you go solo, narrow the deliverable deliberately — one strong, finished component beats a sprawling system with three half-built ones. State the solo scope clearly in your custom project requirement so expectations are set before work begins.
Specify the split upfront
Whether team or solo, write the work split into your project requirement before building starts: who owns which component, who writes which report sections, and the deadline each component must be demo-ready. A written split turns good intentions into a plan your guide can approve — and gives the whole team something to point at when the semester gets busy.