Group projects: the problem isn't the people

You know the pie chart. One slice is 90 percent and it's labeled "me," and the other four are slivers.

It gets reposted every semester because everyone recognizes it. What I want to argue is that it's usually not a story about four lazy people. It's a story about a division of labor that was decided in the first ten minutes of the first meeting, by people who didn't want to seem bossy, and that made the outcome nearly inevitable.

The default split, and why it fails

Four people, four sections, everyone writes theirs, someone staples it together the night before.

Three things go wrong with this, reliably.

Nobody owns the whole. Four sections written independently produce four voices, four formatting conventions, and a conclusion that answers a different question than the introduction asked. The seams are visible from across the room and graders notice immediately.

The dependencies are invisible until they bite. The person writing the analysis can't start until the person collecting data finishes. That was always true and nobody said it out loud, so it surfaces on Thursday when the data person hasn't started.

Integration falls to whoever cares most. It's not assigned, it's not on the schedule, and it turns out to be eight hours of work. Whoever does it becomes the 90 percent slice. That's the mechanism.

Split by role, and make integration a job

The better structure has one person who owns the finished thing, and that ownership is stated out loud, with a deadline.

Concretely:

• Agree the argument first, together. Before anyone writes a word, the group agrees on one sentence: what is this project claiming? Twenty minutes now saves the entire integration problem later, because everyone is writing toward the same thing.
• Divide by function, not by section. Research and data, analysis, drafting, integration and final voice. These handoffs are visible, so the dependencies get scheduled.
• Integration is a real assignment, with hours attached and a name next to it. If someone has that role, they're not doing as much drafting. That's the trade and it should be explicit.

The first meeting, which decides everything

Twenty minutes, and it's worth insisting on.

1. Read the rubric out loud, together. Groups routinely optimize for something the rubric doesn't reward. Two minutes.
2. Agree the one-sentence claim.
3. Write down who does what, with dates — and make the internal deadlines earlier than the real one. Three days of buffer, minimum.
4. Pick the check-in. A standing fifteen minutes, weekly. Not "we'll message if anything comes up," because nobody messages.
5. Decide where things live. One shared folder, one document. The most avoidable group project failure in existence is three versions of the same file in three inboxes.
6. Exchange contact info that people actually check. On US campuses this is usually a GroupMe or a Discord server. Email will not be read by anyone in a group of five undergraduates.

The check-in is the highest-value item on that list. Most group failures aren't discovered late because someone hid the problem — they're discovered late because nobody ever asked, and by the time the seams show it's Thursday.

Being the person who cares most

Sometimes it happens anyway and you're the one holding it. Options in rough order.

Ask directly and specifically, early. Not "how's it going" — that gets "good" every time. "Can you send what you have by Wednesday so I can start pulling it together?" A specific ask with a date is much harder to slide past, and often the honest answer is that they were stuck and embarrassed.

Make the state visible. A shared document where everyone's section is either there or visibly empty. Social pressure works considerably better than nagging, and it costs you nothing to maintain.

Shrink the ask. If someone's frozen, a smaller task is more likely to happen than a big one. "Can you find three sources for section two" beats "can you write section two."

Then talk to the instructor, before the deadline, not after. This is the part people get wrong. Complaining after grades are posted reads as excuse-making and there's nothing to be done. Flagging in week three — "I want to let you know the group is having trouble with division of labor, here's what we've tried" — is a completely different conversation, and instructors have seen it a hundred times and generally have tools.

Many courses now use peer evaluation for exactly this. If yours does, note it in the first meeting, out loud. It changes behavior when everyone knows it exists.

If you're the one who's behind

Sometimes it's you. Something happened, or you didn't understand the task, or you just didn't start.

The thing that turns a recoverable situation into the pie chart is silence. Groups can absorb a person having a bad week. They cannot absorb a person who stops replying, because then nobody knows whether to wait or to start over.

Say something, even if it's late and awkward. "I'm behind, I can have it by Friday" preserves everything. Vanishing until the day before does not.

What's actually being taught

The reason group projects exist despite everyone hating them is that coordinating work with people you didn't choose is the default condition of most jobs.

You don't get to pick your team, some people are less invested than you, dependencies are unclear, and nobody's in charge. The skills that solve that are surfacing dependencies early, making state visible, asking specifically rather than generally, and escalating before the deadline instead of after.

That is what makes the difference between a group that works and a group that produces the pie chart, and it's decided in the first ten minutes far more often than in the last three days.