Codeshare: group projects that actually take off

Graded group work rarely fails on ability. It fails because nobody ever wrote down who delivers what, by when, and what the finished thing is supposed to look like. Four competent people with an unwritten agreement will hand in a worse report than three average people with a written one, and they will hand it in two days late.

The most expensive promise in group work

We will split it up later is the cheapest sentence to say in the first meeting and the most expensive to have said. It sounds cooperative, ends the meeting early, and everybody walks out with a different picture of what happens next.

It postpones the split to the point where there is no slack left to absorb it. In week two a badly divided task can be divided again. In week six it cannot: whatever is missing has to be produced by whoever notices, usually one person and usually at night. The cost of postponing is not the ten minutes you saved. It is the negotiating room you gave away.

The softer versions are the same thing in nicer clothes: let us see how it goes, we will coordinate in the chat, everyone does what they can. None of those are decisions.

The first meeting is the only critical one

Almost all the leverage in a group project sits in the first sitting, and most groups spend it introducing themselves. An hour is enough, but it has to produce specific outputs rather than a good atmosphere. Five things should be settled before anyone leaves:

• What the finished thing looks like. Not the topic, the format: how many pages, how many slides, which sections exist, what the marking criteria actually reward. Read the assignment sheet aloud together, because people who read it alone read it differently.
• Who does which part, stated as a deliverable rather than an area of interest. Not somebody handles the theory, but the section on X, four pages, first draft in the shared folder.
• Dates, including internal ones. Every part carries a date, and that date is not the submission date.
• One place for files. One shared folder, one naming convention, one current version. Attachments passed around in a chat guarantee that somebody works on an outdated file.
• One person who merges. Not a leader and not the one who does more work. Somebody whose named job is to assemble the parts into one document, and who is not writing the largest section.

Write the results down in five lines and post them where everyone can see them. This is not bureaucracy. It is the only artefact the group has, and it makes a later disagreement checkable instead of personal.

Split by boundaries, not by sympathy

The instinct is to divide the work among people you get along with and hope the pieces line up. The better criterion is where the seams are. A piece should be something one person can finish without waiting for anybody else, and something whose end is recognisable. Two people editing the same section in parallel produce conflicts and duplicated effort.

That means splitting along the structure of the artefact rather than along phases. Giving one person research, another writing and another formatting looks efficient and is not: the second cannot start until the first finishes, and the third sits idle for weeks and then panics for a day. Give each person a self contained section with its own sources, text and figures, and the group can genuinely run in parallel.

Where something truly cannot be divided, such as a joint analysis or a shared dataset, treat it as a meeting rather than a delegation.

Anything that stacks needs an earlier internal deadline

Some parts feed others. The analysis needs the cleaned data. The discussion needs the results. Whoever holds an upstream part is holding everybody else’s schedule, and that is almost never said out loud.

Any part with dependants gets an internal deadline well before the real one, with days of slack rather than hours. If the results are due on the fifteenth and the report on the thirtieth, whoever writes the discussion has two weeks. If they arrive on the twenty eighth because nobody set an earlier date, that person has two evenings, and the section carrying the analytical weight becomes the weakest thing in the document.

The internal date is also the only early warning system the group has. A missed internal date on day fifteen is a conversation. The same slip discovered on day twenty nine is a crisis that somebody else absorbs.

Merging is its own job with its own time

Four correct sections do not make a report. They make four sections with different terminology, three definitions of the same variable, references in two styles, and a conclusion that discusses something the introduction never promised. Assembling them into one document is real work and takes hours.

So it gets its own slot in the plan, several days before submission, while everybody is still reachable. The person merging reads it end to end for consistency rather than correctness, and sends back specific gaps: this section defines the term differently, this figure has no caption, this claim appears twice.

Merge on the evening before and nobody has time left to fix what the merge reveals. The document goes in with visible seams, and seams cost marks, because coherence is usually graded explicitly.

Naming a delay before it turns into a conflict

When somebody is behind, the working move is to raise it early and keep it attached to the deadline rather than to the person. There is a large practical difference between you never do anything and the draft was due Tuesday, it is Thursday, what do you need to get it in by Saturday. The first is a verdict and invites defence. The second is a question about a date and usually gets an answer.

Do it in the shared channel rather than in private messages, not to expose anyone but so the group keeps one record of what was agreed. And do it at the first missed date, not the third. By the third, resentment has accumulated, the tone has changed, and the conversation is no longer about the schedule.

When to involve the lecturer

Bring in the supervisor when the delay threatens the submission and internal attempts have not worked, and do it before the deadline rather than after. Most departments have a procedure for uneven contribution, and almost all need the problem to be visible while it can still be repaired. A complaint filed after the grade is published rarely changes anything.

When carrying it yourself is the cheaper option

Sometimes doing it yourself is genuinely the cheapest option. If a missing section is two pages and the negotiation to get it delivered costs more energy than writing it, write it. That decision is better made deliberately in week three than resentfully in week six. But make it with open eyes: do it because it costs less, not because you expect it to be acknowledged afterwards. It usually is not, and that expectation converts a practical decision into four weeks of stored grievance.

The reverse warning matters more, and it applies to the people most likely to read this. If you routinely take work back because you can do it faster, you are manufacturing the passengers you complain about. A group in which one person silently absorbs everything teaches everybody else that nothing they hand over is load bearing, and after two rounds they stop handing anything over. Holding people to a date is uncomfortable. Doing their part for them is more comfortable, considerably more expensive, and trains the exact behaviour it tries to fix.