Industry group project

A team project is assessed on three things at once: the product, the process, and each person's contribution to it. The client is real, the deadline is real, and someone outside the team will use what the team built. The unit exists because that combination is the closest the programme comes to professional work, and where most of the difficulty lives.

The difficulty is rarely the code. It is the coordination around the code: agreeing what will be delivered, obtaining ethics approval before anyone is contacted, keeping the client involved without letting the scope drift, and showing that each member carried their share. Each of those rests on practice, and on a claim more contested than it first appears. Can a shared mark be fair to an individual?

A brief is an opening, not a specification

An external brief arrives short and confident. Suppose a client writes that they need an application so their volunteers can log their hours. That sentence decides almost nothing. What counts as a shift, and who approves it? Does it work without a signal in a village hall? Who owns the record when the project ends? Every unanswered question is a decision the team will make by accident later.

Scope negotiation turns the brief into a written agreement. A workable one fixes the deliverables and, equally, the exclusions, the assumptions, the dependencies it does not control, the acceptance criteria, and the route by which a change is requested and priced. A list of deliverables alone cannot absorb a change at week twenty; the exclusions and the change route are what make the agreement usable. Sommerville's requirements engineering and project planning chapters cover this ground (Sommerville, 2021).

The honest contest is between a baseline and a moving target. The agile tradition prefers scope that evolves as the team learns, and distrusts early specification. A project that must be handed over, and assessed against a fixed standard, needs something firmer than an intention. The defensible position is a baseline plus change control, not a frozen document and not a verbal understanding. What is not supported is the stronger claim that a written agreement guarantees a better product; that case rests on the accreditation requirement, not on a controlled study.

Ethics approval comes before the first participant

Research with people needs approval before any participant is contacted. The BPS Code of Human Research Ethics sets out four principles for research with human participants: respect for the autonomy, privacy and dignity of individuals and communities; scientific integrity; social responsibility; and maximising benefit while minimising harm (British Psychological Society, 2021). It expands these into valid consent, risk, confidentiality and debriefing.

The failure mode is easy to fall into. A team wants quick feedback, so three members ask a few friends to try the prototype over coffee. Participant contact and data collection have now happened without approval, and the notes cannot be used. Approval gates the whole sequence: approval, then recruitment, then consent, then collection. The application is useful design work, because it forces the team to state the purpose, the participants, the consent process, the data it holds, and the risks.

What approval does not do deserves saying. A committee judges a proposal against principles; it cannot make a study harmless, and different committees apply the same principles differently. The code places responsibility for an adequate protocol with the researcher (British Psychological Society, 2021). Treating the form as a hurdle, rather than as the point at which the design is settled, is the costly mistake.

The client belongs in the loop at checkpoints

A stakeholder who first sees the product at the end is a stranger with a veto. The alternative is a small number of agreed checkpoints, each with a working slice to demonstrate and the acceptance criteria exercised in front of the client. Sommerville's chapters on software processes and agile development present incremental delivery as the alternative to one delivery at the end (Sommerville, 2021). The risk argument is simple: a system delivered in increments surfaces misunderstanding early, while correcting it is still cheap.

Consider two teams with the same brief. The first works in private for two terms and presents a finished application in the final week. The second agrees three checkpoints at six-week intervals and shows a usable slice at each, with a short record of the client's response. The second team's advantage is not better engineering. It is that objections arrive while they can still be answered.

The evidence here is weaker than the practice suggests. Claims that client involvement improves outcomes are mostly argued from experience, not shown in controlled comparisons, and involvement has a failure mode of its own, design by committee. What can be defended is narrower: checkpoints make disagreement visible early, and that reduces the cost of a late reversal.

Management proportionate to a team

Project management on a student team fails in one of two ways: too little, so problems surface late, or too much, so the paperwork becomes the work. The proportionate minimum is a plan, a risk register and a decision log, each short enough to be kept current. Sommerville devotes separate chapters to project management and to project planning, which is the scaffolding compressed here (Sommerville, 2021).

A risk register is only useful if each entry has an owner, a likelihood, an impact and a mitigation with a date. A team member may leave is not a risk. The second developer starts a placement in January, so deployment must move to December or be documented for a replacement, is a risk with a decision attached. The decision log is its companion: what was decided, when, on what information, and what was rejected. That is the difference between a team that remembers and one that repeats the same argument in March.

A concrete dependency shows why this matters. Suppose the product relies on a third-party mapping service, and the supplier changes its terms partway through the year. A team with no register treats the change as a crisis. A team with a register has already named the dependency, identified a fallback and agreed the trigger for switching. The register did not predict the change; it turned it into a decision the team had rehearsed.

The repository is the team's memory

Version control and continuous integration are team obligations, not personal preferences. Fowler defines continuous integration as the practice in which each member merges changes into a shared mainline at least daily, with every integration verified by an automated build that includes tests (Fowler, 2024). The supporting practices are specific: keep everything in version control, automate the build, make it self-testing, commit to the mainline daily, trigger a build on every push, fix a broken build immediately, and keep the build fast.

Fowler opens with the case that motivates it, a site where separate components had been integrating for months and nobody could say when the work would finish. The modern answer is trunk-based development, in which the team commits to one shared line and relies on the build to catch what breaks. Winters and colleagues reach the same position from a larger scale, describing a formal version control system as something no organisation bigger than a few people can do without (Winters, Manshreck and Wright, 2020).

Be honest about this evidence. The benefits of continuous integration are reported from practice, and Fowler himself lists conditions under which it is the wrong choice, including a codebase that cannot be tested automatically. For a five-person team that integrates once a month, what is missing is a habit, not a tool, and the commit history will show it.

Code review is a team obligation, with limits worth naming

Review is the practice in which someone other than the author examines a change before it enters the shared code. At Google, essentially every change is reviewed before it is committed, and the reviewer's agreement, recorded as looks good to me, is what permits the commit (Winters, Manshreck and Wright, 2020). The stated goal is not only to find defects: review also spreads knowledge of the code and creates a second person who understands each part.

Sadowski and colleagues studied the practice at Google through twelve interviews, a survey of forty-four respondents and review logs for nine million changes (Sadowski et al., 2018), reporting the motivations behind review, the current process, and developers' satisfaction and challenges. The scale is unusual, and the study examines one company.

Two limits matter for a student team. The first is context: a process refined across nine million reviews is tuned for a codebase and a staffing model a five-person team does not have, and the paper's own references include work arguing that reviews do not primarily find bugs. The second is that review can become performance, with approval granted quickly to keep the queue moving. A small team gets most of the benefit from one light rule, applied consistently: no change reaches the mainline without a second reader.

Individual accountability inside a shared mark

This is the contested question. BCS requires that a group project's assessment measure each student's individual contribution against the learning outcomes, and that the marks a student receives reflect their individual achievement and input (BCS, 2022). The instrument is usually a mix of a group mark, an individual mark and peer review. The tension is that the project's value comes from the collaboration, while the assessment must disaggregate it.

The research on teams says the thing being measured is real. Hoegl and Gemuenden define teamwork quality through six facets: communication, coordination, balance of member contributions, mutual support, effort and cohesion. Using data from 575 members, leaders and managers of 145 German software teams, they found teamwork quality associated with team performance, though the strength of that association depended on who rated the performance (Hoegl and Gemuenden, 2001). Balance of member contributions is one of the six facets, not an add-on.

Why individuals slack is also studied. Latane, Williams and Harkins found that in rope-pulling, clapping and shouting tasks, individual effort fell as group size rose, and that the fall was not explained by coordination losses alone; they called the effect social loafing (Latane, Williams and Harkins, 1979). Anonymity within a group is part of the mechanism, which is why identifiable contribution is the design response.

A real programme shows what that looks like. King's College London runs three group projects in sequence. Its monitoring software records attendance at meetings, minutes, contribution statistics from GitHub and a weekly experience survey, and runs a peer assessment afterwards, to detect social loafing, communication failure, unresolvable conflict and non-participation early (BCS, n.d.).

None of this makes the measurement fair, and the honest account should say so. Commits, attendance and lines of code are proxies: a commit count rewards volume and punishes the member who writes the documentation or reviews others' work. Peer assessment carries friendship bias and the risk of retaliation. No scheme has been validated as fair. The defensible aim is evidence plus a route to challenge it, not a single number that claims to settle the matter.

Handover, reflection, and the test that outlasts the mark

Handover is where a student project becomes someone else's problem, and one question judges it: could a competent stranger, given the repository, run and maintain the product without asking the team? Documentation, a deployed artefact and a closing presentation are the outward forms. The real test is whether the repository, the decision log and the risk register tell that stranger what was built, why, and what was known to be unfinished.

The reflective account closes the loop, and its purpose is learning rather than confession. Schon argued that professionals know more than they can put into words, and that they think through action and afterwards about it (Schon, 1983). A strong account names what went wrong, says what the team did about it, and draws a rule for next time; a weak one describes the term in order. BCS lists critical self-evaluation of the process among the things a project must let a student demonstrate (BCS, 2022).

Be clear about what remains unsettled. The evidence that any particular accountability mechanism is fair is thin, the evidence that client involvement improves outcomes is mostly practice-based, and the best documented engineering workflow comes from a company whose scale a student team does not share. The habits the project demands, evidence over assertion and evaluation over enthusiasm, are the same habits that the closing study of research frontiers turns on.