At 11.42pm on the night before submission, the shared report is called GroupProject_FINAL_v7_USE_THIS_ONE. Two people are editing the introduction at the same time. Nobody knows whether the references have been checked. One member has produced 1,800 words for a section that was supposed to contain 700, while another has sent three paragraphs without any sources. The presentation contradicts the written recommendation, and the person who volunteered to submit the work has stopped replying.
This is usually described as a teamwork problem. More specifically, it is a management problem.
A university group project creates a small temporary organisation. It has a deadline, a shared objective, limited resources, dependent tasks and people with different skills, schedules and incentives. It may have a nominal leader but no genuine manager, no employment contract and very little authority to reward good work or respond to poor performance. The final mark is often shared even when the work was not.
Under those conditions, it is unsurprising that capable students sometimes produce disorganised work. The team may have divided the report without agreeing on its argument. Members may reduce their effort because individual contributions are difficult to see. A dominant student may take control while quieter members stop challenging weak decisions. Everybody may privately recognise that the schedule is unrealistic but avoid saying so until the deadline is too close to move.
A group project is not five individual assignments placed in the same file. It is one interdependent project that requires decisions about roles, standards, timing, communication, conflict and accountability.
Understanding why group projects fail is useful beyond university. The same problems appear in workplaces, voluntary organisations, professional partnerships and project teams. A student group simply exposes them quickly because the team has little time to establish trust or repair a poor structure.
A bad group mark can hide several different failures
When a project goes wrong, students often reduce the explanation to one sentence: somebody did not pull their weight. That may be true, but it does not identify why the contribution was poor or what would have prevented it.
Several different problems can produce the appearance of unequal effort:
- Deliberate free-riding: A member knowingly relies on others to complete the work while expecting to receive the shared mark.
- Social loafing: A person puts in less effort because their individual contribution is difficult to identify, seems unimportant or is unlikely to affect the outcome.
- Coordination failure: Members are willing to work but duplicate tasks, leave gaps or produce incompatible sections because ownership and dependencies were unclear.
- A blocked contribution: A student encounters illness, employment pressure, caring responsibilities, inaccessible working arrangements, a technical problem or a task they do not understand, but the team does not identify and manage the obstacle.
- Defensive withdrawal: A member stops contributing ideas because one person repeatedly dismisses, rewrites or takes credit for their work.
- Rescue behaviour: One student assumes that nobody else will meet the required standard, takes over most of the project and then resents the others for contributing less.
These situations should not be managed in the same way. A deliberate free-rider may require documented escalation. A blocked student may need a changed task or an adjusted deadline. A dominant student may need to surrender control of some decisions rather than work even harder.
The first management task is therefore diagnosis. Before accusing somebody of laziness, ask whether the team made the expected output, deadline and standard clear; whether the person understood the task; whether their work depended on something that never arrived; and whether they had a realistic opportunity to contribute.
Unclear roles create invisible gaps
Many groups begin with what sounds like a sensible plan: divide the assignment into equal sections, give one section to each member and combine everything at the end.
This distributes words, but it does not necessarily distribute the work.
Consider a 4,000-word management report requiring a problem analysis, use of theory, evaluation of evidence, recommendations and a presentation. Dividing it into five blocks of 800 words leaves several questions unanswered:
- Who decides the report's central argument?
- Who selects the organisation, case or dataset?
- Who checks whether everybody is using the same definitions?
- Who identifies reliable sources?
- Who ensures that the recommendations follow from the analysis?
- Who removes repetition and resolves contradictions?
- Who checks the marking criteria, references and word count?
- Who converts the report into a coherent presentation?
- Who uploads the final version and confirms that it opens correctly?
These tasks are easy to overlook because they do not correspond neatly to a section heading. They are also the tasks most likely to determine whether the submission feels like one report or five unrelated pieces of writing.
Break down the work before allocating it
Professional project planning often begins with a work breakdown structure: the project is divided into smaller outputs and activities before people or dates are assigned. The Association for Project Management's guidance on work breakdown structures explains that this process helps identify the work required before it is placed into a schedule.
For a student project, the breakdown might include:
- interpret the brief and marking criteria;
- define the question or problem;
- agree the main argument;
- create a preliminary structure;
- find and assess evidence;
- choose relevant theories or methods;
- analyse the case or data;
- draft each component;
- review each draft against the criteria;
- integrate the sections;
- check references and factual claims;
- design the presentation;
- rehearse and revise;
- format and submit the files.
Only after this list exists can the team see which tasks are large, which are dependent on earlier decisions and which may otherwise be left to whoever notices them at the end.
Give every task one clear owner
A full professional RACI matrix distinguishes between people who are responsible, accountable, consulted and informed. A student team can use a simpler version:
- Owner: The person responsible for making sure the task is completed.
- Contributors: People who provide research, ideas or practical help.
- Reviewer: The person who checks the output against an agreed standard.
For example:
- Report structure: Aisha owns it, everybody contributes, Daniel reviews it against the brief.
- Evidence bank: Marcus owns it, Aisha and Priya contribute, Leon checks source quality.
- Financial analysis: Priya owns it, Marcus provides data, Aisha reviews the calculations.
- Recommendations: Daniel owns the first draft, the whole team challenges it, Priya checks whether it follows from the evidence.
- Final integration: Leon owns the integrated document, but original writers must respond to review comments.
- Submission: Marcus uploads the file, while Aisha independently checks the uploaded version before the deadline.
There can be several contributors, but there should normally be one identifiable owner. "Aisha and Daniel are both in charge" often means each assumes the other will deal with it.
Ownership does not mean doing everything personally. The owner coordinates the task, notices when it is blocked and makes sure the required output exists by the agreed time.
Social loafing is a predictable group effect
Social loafing occurs when people exert less effort in a collective task than they would if their individual contribution were separately identifiable. It is not merely a label for unpleasant classmates. A meta-analysis of 78 studies by Steven Karau and Kipling Williams found it to be a robust effect across different tasks and populations.
The likelihood of loafing changes according to the way the work is designed. People are more likely to reduce effort when:
- their individual output cannot be identified;
- they believe their work will make little difference;
- the task seems meaningless or repetitive;
- they expect other members to compensate;
- they think rewards will be distributed unfairly;
- the team is large enough for an individual to disappear within it;
- there is no meaningful review until the final submission.
A study of social loafing in student projects by Pooja Aggarwal and Connie O'Brien found that loafing increased with project scope and group size. Multiple peer evaluations during the project were associated with reduced loafing. This is a particularly useful finding because it suggests that accountability works better when it is built into the process rather than added as a complaint form after the mark has already been earned.
One older survey of 227 students working in online learning groups found that 35.7 per cent believed another member had engaged in social loafing, while only 8.3 per cent reported doing so themselves. This was one study in a particular online-learning context, not a national estimate of university group work. The gap is still revealing: people can usually see the pressures affecting their own contribution, while they see only the delayed or incomplete output of somebody else.
The "sucker effect" can make the problem spread
A conscientious student may initially compensate for a weak member. If the imbalance continues, they may decide that they are being exploited and deliberately reduce their own effort. This response is sometimes called the sucker effect: the person would rather accept a poorer collective result than continue doing extra work while everybody receives the same reward.
The final decline can therefore involve more than one person. One member misses tasks, another begins withholding effort, and a third takes over because they no longer trust either of them. The team then interprets the resulting chaos as evidence that group work is inherently unfair.
How to reduce social loafing
A team cannot eliminate every incentive problem, but it can make useful contribution more visible:
- allocate specific outputs rather than vague areas of responsibility;
- give each output a named owner, date and reviewer;
- use several small milestones rather than one final deadline;
- keep a task record linking members to drafts and completed actions;
- review contribution while recovery is still possible;
- make every role meaningful to the final result;
- avoid unnecessarily large groups where the course allows a choice;
- discuss workload openly instead of assuming that equal word counts mean equal effort;
- use the formal peer-assessment process honestly and with evidence.
Public humiliation is not an effective accountability system. Posting an angry message about "people who have done nothing" is likely to create defensiveness without clarifying which task is missing or how the project will recover. A useful message identifies the output, the agreement and the next decision.
For example:
We agreed that the competitor analysis would be ready for review by Tuesday. It is not yet in the document, and the recommendations depend on it. Can you complete it by 6pm tomorrow, or should we reallocate part of it tonight?
This gives the person an opportunity to explain a genuine blocker while making the consequence of further delay clear.
Weak leadership can mean too little direction or too much control
A student group leader is in an awkward position. They may be expected to organise the team without having any formal authority over the other members. They cannot change somebody's mark, require attendance or impose a disciplinary sanction. If they behave as though they are everybody's manager, the group may resist them. If they avoid every difficult decision, coordination collapses.
Leadership in this setting is better understood as a collection of necessary functions:
- clarifying the objective;
- making sure decisions are actually made;
- coordinating dependent work;
- monitoring progress without micromanaging;
- identifying risks and blockers;
- protecting the agreed quality standard;
- creating space for challenge;
- escalating serious problems early enough for action.
These functions do not all have to sit with one person. A team can appoint a project coordinator, a meeting chair, a final editor and a presentation lead. Distributing leadership prevents the nominated leader from becoming the group's unpaid administrator while everyone else concentrates only on their own section.
The leader should not become the permanent rescuer
Some leaders respond to uncertainty by taking control of every important task. They rewrite other people's sections, make decisions privately and complete unfinished work without saying anything until after submission.
This may protect the immediate mark, but it creates several problems:
- other members receive no timely feedback and cannot improve;
- the leader becomes a bottleneck;
- the true workload imbalance remains undocumented;
- members stop taking ownership because they expect their work to be replaced;
- the final product reflects one person's judgement rather than the team's combined knowledge;
- resentment is expressed only after it is too late to change the process.
A stronger response is to return inadequate work with a specific revision request linked to the marking criteria. If the analysis lacks evidence, identify which claim needs support. If it describes theory without applying it, state what case evidence needs to be connected to the model. Rewriting should be the last recovery option, not the normal quality-control method.
Leadership depends on whether people can admit problems
A team cannot manage a problem it does not know exists. Yet students often hide delays because they expect anger, embarrassment or ridicule.
Amy Edmondson defined psychological safety as a shared belief that a team is safe for interpersonal risk-taking. Her field study of 51 work teams found that psychological safety was associated with learning behaviour and helped explain differences in team performance.
A student group is not identical to a workplace team, but the mechanism is easy to recognise. A member who expects to be mocked may conceal that they do not understand the statistical method. Somebody who expects immediate blame may pretend that a section is nearly finished. By the time the problem becomes visible, there is no longer enough time to teach, revise or reallocate the task.
Psychological safety does not mean lowering standards or avoiding accountability. It means making it possible to say:
- "I do not understand this part of the brief."
- "My section is going to be late unless we change the scope."
- "I think our recommendation contradicts the evidence."
- "I made an error in the calculation."
- "I cannot attend that meeting, but I can complete this task asynchronously."
The team can then address the problem rather than discover it accidentally at the deadline.
More communication does not necessarily produce better coordination
A busy group chat can create the impression that a team is communicating well. In reality, 150 messages may contain no firm decision, named action or deadline.
Coordination also becomes more difficult as a team grows. A team of four contains six possible one-to-one communication relationships. A team of six contains fifteen. A team of eight contains twenty-eight. Each additional member creates more potential exchanges, different availability and more opportunities for information to become fragmented.
Common communication failures include:
- important decisions buried between unrelated chat messages;
- different versions of the file stored on several devices;
- private discussions that change the project without informing everybody;
- members assuming that silence means agreement;
- requests that do not identify an owner or deadline;
- meetings that repeat updates but make no decisions;
- voice notes or screenshots that cannot be searched easily;
- work discussed in one platform and stored in another without a clear link.
Create one source of truth
A small project normally needs no more than:
- one main communication channel for routine discussion;
- one shared workspace containing the current documents and evidence;
- one task tracker showing ownership, deadlines and status;
- one decision record showing what was agreed and why.
The task tracker does not need specialist software. A shared document can record:
- the task;
- the owner;
- the expected output;
- the deadline;
- the reviewer;
- whether the task is not started, in progress, blocked or complete;
- a link to the relevant file or section.
A decision record is especially useful when a group repeatedly revisits settled questions. It might state:
12 October: We will recommend option B because it meets all three criteria and is supported by the available cost evidence. Priya will draft the recommendation. Daniel will check whether the risk section changes the conclusion.
This is far more useful than searching through several days of messages to reconstruct who agreed to what.
Make messages actionable
A productive request contains four elements:
- Context: What part of the project is affected?
- Action: What needs to be produced or decided?
- Owner and date: Who will do it, and by when?
- Standard: What will count as complete?
"Can someone look at the slides?" is easy to ignore because nobody is clearly responsible and look at could mean almost anything.
A better request is:
Leon, could you review slides 4 to 7 by 3pm tomorrow? Please check that each claim appears in the report, that every graph has a labelled source and that the section can be presented within three minutes.
Keep meetings short and decision-focused
A regular 20-minute meeting can follow the same structure:
- What has been completed since the last meeting?
- What is currently blocked or at risk?
- Which decisions must be made now?
- What will each person complete next, and by when?
- Has any risk to the final deadline changed?
End by recording the actions in writing. A meeting that concludes with "everybody knows what they are doing" often produces five different interpretations of what was agreed.
Conflict avoidance allows weak decisions to survive
Students often believe that a successful team is one in which everybody gets along and disagreements are kept to a minimum. In practice, a group that never challenges an idea may be avoiding the conversations needed to improve its work.
Research distinguishes between several forms of conflict:
- Task conflict: Disagreement about ideas, evidence, interpretation or the substance of the work.
- Process conflict: Disagreement about roles, workload, timing and how the work should be completed.
- Relationship conflict: Personal tension, hostility or dislike between members.
A meta-analysis by Frank de Wit, Lindred Greer and Karen Jehn examined 116 studies covering 8,880 groups. Relationship and process conflict had stable negative relationships with group outcomes. Task conflict was more complicated: it could be less damaging, or occasionally useful, when it remained separate from personal hostility and occurred in the right decision-making conditions.
The practical lesson is not that teams should argue constantly. It is that disagreement about the work needs a safe, structured route before it becomes a dispute about the people.
Challenge the claim rather than the person
Compare these statements:
You clearly have not understood the question.
I do not think this section answers criterion two because it describes the theory but does not apply it to the organisation. Could we add evidence from the case and explain which part of the theory it supports?
The second version is more demanding academically, but less personal. It identifies the standard, the gap and a possible solution.
Useful disagreement can follow four rules:
- State the issue precisely. Identify the claim, calculation, design choice or missed agreement.
- Use an external criterion. Refer to the brief, evidence, data, marking criteria or agreed project objective.
- Offer an alternative. Explain what should change rather than merely rejecting the existing work.
- Separate the decision from the person. A weak paragraph does not make its writer a weak student.
Agree how decisions will be made
Groups often assume that decisions require complete consensus. That becomes impractical when time is limited or several options are defensible.
A team can agree in advance that:
- the marking criteria take priority over personal preference;
- factual questions are settled by the strongest available evidence;
- the member with relevant technical expertise recommends an option but explains the reasoning;
- minor design choices can be decided by a majority;
- the project coordinator can make a time-sensitive decision after hearing objections;
- genuine ambiguity in the brief will be referred to the tutor rather than guessed at repeatedly.
Recording the decision prevents a losing argument from being reopened each time the person who preferred the other option becomes dissatisfied.
Unrealistic planning begins with the submission date
Many groups believe they have a plan because they know the deadline. They do not.
A deadline describes when the finished output is required. A project plan identifies the work, order, dependencies, resources, risks and internal dates needed to produce it. The Association for Project Management treats project planning as an integrated process covering scope, quality, time, resources, risk, communications and measures of success.
Students are particularly vulnerable to the planning fallacy: the tendency to underestimate how long their own future work will take, even when they know similar work has overrun before.
In a classic study by Roger Buehler, Dale Griffin and Michael Ross, 37 students predicted that their theses would take an average of 33.9 days to complete. The average actual time was 55.5 days, and only 29.7 per cent finished by their predicted date. Even the average worst-case estimate, 48.6 days, was shorter than the actual completion time.
A group project combines several optimistic estimates. If five people each assume that their section will take two days, the plan may ignore:
- the time needed to agree the approach;
- delays in obtaining data or sources;
- work and family commitments;
- dependencies between sections;
- feedback and revision;
- integrating different writing styles;
- checking references and calculations;
- preparing and rehearsing the presentation;
- technical problems during submission.
Plan backwards from a finished submission
Backward planning begins with the final required state and works in reverse. Experimental research into backward planning and goal pursuit suggests that this approach can improve planning for complex goals by encouraging people to identify the steps required before the outcome can exist.
Start with the final deadline and ask:
- When must the file be uploaded?
- When must the final quality check be complete?
- When must the integrated draft be ready?
- When must revised sections be returned?
- When must the first full drafts be available for review?
- When must the evidence and analysis be complete?
- When must the structure and central argument be agreed?
For a four-week report and presentation, a realistic schedule might look like this:
- Days 1 to 2: Interpret the brief, agree the outcome and create the work breakdown.
- Days 3 to 5: Agree the argument, methods, sources and section relationships.
- Days 6 to 11: Complete research, data collection and preliminary analysis.
- Days 12 to 17: Produce first drafts and presentation material.
- Days 18 to 20: Conduct cross-review and return specific revision requests.
- Days 21 to 23: Revise sections and resolve contradictions.
- Days 24 to 25: Integrate the full report and complete reference checks.
- Days 26 to 27: Rehearse the presentation and test timing.
- Day 28: Conduct a final file check and submit before the formal deadline.
This schedule contains time for integration because integration is part of the project. It is not an administrative task that happens automatically after everybody finishes writing.
Define what "finished" means
"Complete your section by Friday" is ambiguous. One student may interpret it as a rough set of notes, another as a polished and referenced contribution ready for submission.
A useful definition of done might state that the section must:
- meet its agreed word range;
- answer the assigned part of the question;
- use the agreed theory or method;
- contain properly linked evidence;
- include complete references;
- follow the shared terminology and structure;
- be ready for another member to review without additional explanation.
Clear standards reduce both disappointment and the ability to claim that an incomplete task was technically delivered.
Identify dependencies and the critical path
Some tasks can occur at the same time. Others cannot.
The student writing recommendations may need the analysis first. The person preparing graphs may need cleaned data. The final editor may need every revised section. The presentation team may need the agreed conclusions before designing the final slides.
If a delayed task holds up several later tasks, it lies on or near the project's critical path. It should receive more frequent attention than an independent task that has several days of spare time.
A useful weekly question is therefore not simply, "Is everybody busy?" It is, "Which unfinished task could now delay the whole submission?"
Keep a small risk register
A student risk register can be very short:
- Risk: Interview participants do not respond. Response: Contact more participants early and agree an alternative evidence source.
- Risk: One member cannot use the analysis software. Response: Arrange a training session and allocate a reviewer with the required skill.
- Risk: Drafts use incompatible theories. Response: Agree the analytical framework before writing begins.
- Risk: A member has a major employment commitment during the final week. Response: Move their critical tasks earlier.
- Risk: The university's rules on generative AI are unclear. Response: Ask the tutor before using it and record the answer.
- Risk: The presentation exceeds its time limit. Response: Hold the first timed rehearsal several days before submission.
The purpose is not to predict every possible problem. It is to notice foreseeable problems while the team still has choices.
Measuring individual contribution is genuinely difficult
A group mark is attractive because the final report, design or presentation is a collective product. It becomes controversial because the route to that product may involve very different levels and types of contribution.
Contribution cannot be measured reliably by word count alone. A student who writes 1,500 weak words may create more work than somebody who writes 600 strong words and identifies a major flaw in the team's analysis.
Nor is attendance a complete measure. A member can attend every meeting without preparing or completing any action. Another may be unable to attend a particular time but provide excellent research, editing and asynchronous feedback.
Useful but often invisible contributions include:
- finding a decisive source;
- checking the accuracy of calculations;
- organising meetings and actions;
- identifying a contradiction between sections;
- helping another member understand a method;
- editing the report into one consistent argument;
- resolving a conflict before it damages the project;
- testing the presentation and identifying timing problems;
- maintaining the reference list and evidence record.
This is why a final question asking students to assign everybody a number from one to ten can become a popularity vote rather than a reliable measure of contribution.
Peer assessment works better with training and repeated evidence
A meta-analysis of peer assessment by Hongli Li and colleagues examined 134 effect sizes from 58 studies. Students who took part in peer assessment showed an average performance improvement of 0.291 standard deviations compared with students who did not. Rater training was the most important moderator identified in the study.
This research concerned peer assessment as a learning activity rather than solely the division of group marks, so it does not prove that every contribution score will be fair. It does support the value of teaching students how to assess work and provide evidence-based feedback instead of assuming they can do so instinctively.
Contribution reviews are more credible when they occur at several points:
- an early review of preparation and initial tasks;
- a midpoint review while workload can still be changed;
- a final review supported by the project record.
Repeated reviews reduce the risk that one recent disagreement determines every score. They also allow a student who receives weak feedback at the midpoint to change their behaviour before the project ends.
Use behaviour-based criteria
A contribution form should ask about observable behaviour rather than personality. Useful categories include:
- Reliability: Did the member complete agreed tasks by the required time or give adequate warning when they could not?
- Quality: Did their work meet the agreed standard and respond to feedback?
- Preparation: Did they arrive at decisions and meetings with the required material?
- Communication: Did they respond to important requests and make blockers visible?
- Intellectual contribution: Did they provide useful analysis, evidence, challenge or problem-solving?
- Integration: Did they help connect their work with the rest of the project?
- Support for the team: Did they review, explain or assist without taking over?
Each score should be supported by an example. "Priya contributed less" is an allegation. "Priya missed the agreed data deadline twice, did not respond for four days and provided the file after the analysis had been reassigned" is evidence that can be checked.
Keep records without turning the team into a surveillance system
The purpose of a contribution record is to support coordination and fair review, not to count every minute. Useful evidence includes:
- the shared task tracker;
- version history in collaborative documents;
- meeting actions;
- drafts and review comments;
- records of changed responsibilities;
- warnings about blockers or missed deadlines;
- the final peer-assessment explanations.
Message volume is poor evidence. The most active person in the group chat may contribute little to the academic work, while a quieter member may produce excellent analysis and detailed comments in the document.
Likewise, version history needs interpretation. A student may make hundreds of minor formatting edits, while another makes one change that corrects the entire argument. Activity is not the same as value.
A team charter should be an operating agreement
A team charter records how members intend to work together. It can sound unnecessarily corporate, but the underlying idea is simple: assumptions that remain unspoken are likely to become disputes.
A study involving 124 students in an introductory organisational behaviour course found that students perceived charters as helping to clarify roles, responsibilities, accountability, communication and the team's shared direction. The research was conducted in one course at one university and relied on student perceptions, so it should not be treated as proof that a charter automatically raises marks.
The more important question is what happens after the form is written. Research first published online in 2025 found that revising team charters during the semester, together with feedback and coaching, produced stronger commitment, satisfaction and individual effectiveness than relying on a one-time charter.
A useful charter should answer:
- What final standard is the team aiming for?
- What does each person own?
- What known availability constraints need to be planned around?
- Which channel will be used for urgent and non-urgent communication?
- What response time is reasonable on working days?
- How frequently will progress be reviewed?
- How will missed deadlines be handled?
- How will disagreements be decided?
- How will individual contributions be recorded?
- What uses of generative AI are permitted by the university and accepted by the team?
- When will the charter itself be reviewed?
"Everybody will communicate well and work hard" is not an operating agreement. "Members will acknowledge an important task message within 24 hours, flag anticipated delays before the deadline and update the tracker before the weekly meeting" is much more useful.
A practical agenda for the first 45 minutes
A group can prevent many later problems during its first properly structured meeting.
Minutes 0 to 8: interpret the assignment
- Read the question and marking criteria together.
- List every required output.
- Identify restrictions such as word count, presentation time, source requirements and individual components.
- Write a one-sentence description of what a successful submission must demonstrate.
Minutes 8 to 18: define the argument and structure
- Agree the problem the project will address.
- Identify the likely central argument or decision.
- Sketch the main components and explain how they connect.
- Record questions that need clarification from the tutor.
Minutes 18 to 28: break down and allocate the work
- List research, analysis, drafting, review, integration and submission tasks.
- Assign one owner and one reviewer to each important output.
- Match tasks to genuine skills where possible.
- Avoid allocating all coordination and editing work to the same person.
Minutes 28 to 36: build the schedule
- Work backwards from the final deadline.
- Set dates for the structure, evidence, first drafts, review, revision, integration and rehearsal.
- Record known work, placement or caring commitments.
- Identify the tasks that could delay everything else.
Minutes 36 to 42: agree working rules
- Select the communication channel and shared workspace.
- Agree reasonable response expectations.
- Choose the decision-making and conflict process.
- Agree how contribution will be recorded.
Minutes 42 to 45: confirm immediate actions
- State each person's first task and deadline.
- Record unresolved questions.
- Book the next checkpoint.
- Make sure everybody can access the files and tracker before leaving.
A management case study: the five-person report
Imagine five students have four weeks to produce a 4,000-word consultancy report and a ten-minute presentation.
At their first meeting, each person selects a section. Zara volunteers to combine the work. The group does not agree on a central argument because members assume this will become obvious once the research is complete. They create a group chat but no task record. Everyone agrees to finish their section "a few days before" the deadline.
Three weeks later:
- two members have analysed different organisations;
- one section uses stakeholder theory while another assumes a completely different framework;
- the financial evidence needed for the recommendations has not been collected;
- one member has written double the agreed length;
- one has supplied notes rather than a finished section;
- Zara discovers that integration requires extensive rewriting;
- the presentation team has designed attractive slides based on conclusions the report no longer supports.
The group may blame the student who supplied notes. That contribution is certainly a problem, but it is not the only cause of failure.
The management diagnosis includes:
- Scope failure: The team never agreed on the exact case or central question.
- Role ambiguity: Members owned headings rather than complete outputs and dependencies.
- Planning failure: "A few days before" was not an internal schedule.
- Weak control: No checkpoint revealed the inconsistent approaches.
- Integration risk: One person was expected to repair every inconsistency at the end.
- Communication failure: Discussion occurred, but important decisions were never recorded.
- Performance-measurement failure: The team had no way to distinguish incomplete work from invisible coordinating effort.
A better design would have agreed the organisation and analytical framework during the first week. Research findings would have been collected in a shared evidence bank. Each section would have had an owner and a cross-reviewer. The first drafts would have been due at the end of week two, leaving time for integrated analysis, revised recommendations and a presentation based on the final argument.
This would not guarantee equal enthusiasm or perfect work. It would make emerging problems visible while the team still had time to respond.
How to deal with common group problems
A member misses one deadline
Check the position promptly and privately rather than launching a public accusation. State the missing output, ask whether the task is blocked and agree a specific recovery point.
If the person needs clarification or a modest change in scope, resolve it. If the task affects the critical path, consider dividing it so the rest of the team can continue.
A member repeatedly misses deadlines
Do not continue relying on assurances without changing the plan. Reassign urgent dependent work, record what has happened and use the module's escalation procedure before the final submission.
Early escalation is not an act of betrayal. It gives the tutor an opportunity to clarify expectations, support the student or apply the course's group-work process. A complaint made only after the mark is released is much harder to investigate.
One person dominates every decision
Separate expertise from authority. The most knowledgeable member should explain their recommendation, but others should still be able to question the assumptions and evidence.
For important decisions, ask each member to contribute before the group settles on an option. Written comments can help people who need more time to process or find fast verbal debate difficult.
Do not automatically appoint the dominant person as final editor. Editing gives substantial power over which arguments and contributions survive into the submitted version.
A section is poor but the writer believes it is finished
Review it against an agreed definition of done and the marking criteria. Replace "This is not good enough" with specific gaps:
- the section contains no evidence for two central claims;
- the theory is described but not applied;
- the analysis repeats the introduction;
- the recommendation does not follow from the findings;
- the references are incomplete.
Set a revision deadline and identify who will check the revised version.
A member disappears
Begin with a neutral welfare check. There may be a serious reason for the silence. At the same time, protect the project by identifying which work is now at risk and alerting the tutor according to the course procedure.
Do not remove somebody's name, deny them access or invent a mark penalty without academic guidance. The university, not the group, decides formal consequences.
Two members cannot agree
Ask each person to state:
- the decision they want;
- the evidence supporting it;
- the marking or project criterion it satisfies;
- the main risk of the alternative.
Then apply the team's agreed decision rule. If the disagreement reveals a genuine ambiguity in the assessment, send one concise question to the tutor rather than continuing an unresolvable internal debate.
Generative AI creates an additional coordination problem
The HEPI Student Generative AI Survey 2026 found that 95 per cent of surveyed students used AI in at least one way and 94 per cent used generative AI to help with assessed work. Twelve per cent reported directly including AI-generated text in assessed work.
In a group project, one person's approach to AI can affect everybody. A member may use a tool in a way the module prohibits, introduce invented references or insert text that nobody else has checked. Another member may regard all AI use as unacceptable even where the university expressly permits limited uses such as brainstorming or language support.
The group should establish at the beginning:
- what the module and institution permit;
- whether use must be declared;
- which tasks, if any, the team agrees may involve AI;
- who is responsible for checking every factual claim and reference;
- how generated material will be rewritten, verified or recorded;
- whether sensitive, personal or restricted information must be kept out of external tools.
An AI-generated paragraph should never be treated as researched simply because it sounds polished. If the tool supplies a source, a group member must locate the real publication, confirm that it exists and check that it supports the claim.
AI policy is not a matter of individual preference once work is being submitted collectively. Where the rules remain unclear, obtain written guidance from the tutor before the team relies on the tool.
A 24-hour rescue plan
Some teams do not introduce a management system until the project is already close to failure. With 24 hours remaining, the goal is no longer to create the ideal process. It is to protect the strongest defensible submission possible.
- Save a clean master copy. Stop editing several uncontrolled versions.
- Audit the marking criteria. Identify missing requirements before spending time polishing minor wording.
- Freeze the structure. Do not continue moving sections unless the existing structure makes the argument impossible to follow.
- List the critical defects. Separate factual errors, missing evidence and contradictions from optional improvements.
- Allocate each repair once. Prevent two people from fixing the same paragraph while another gap remains untouched.
- Appoint one final editor. Other members should suggest changes rather than simultaneously rewriting the master document.
- Check every reference and calculation. Remove unsupported claims that cannot be verified in time.
- Align the report and presentation. The recommendations, figures and conclusions must agree.
- Test the final files. Open them on another device and check formatting, audio, links and file names.
- Submit with a buffer. Do not reserve the final minutes for an upload that may fail.
This is not the time for a comprehensive argument about who caused the problem. Record the facts needed for peer assessment or academic review, complete the submission and address the process afterwards.
How group work becomes a management case study
A university group project provides direct evidence of several management concepts:
- role ambiguity and responsibility allocation;
- social loafing and perceived fairness;
- formal and informal leadership;
- power without authority;
- psychological safety;
- task, process and relationship conflict;
- communication structures;
- project scope and work breakdown;
- dependency management and critical paths;
- risk management;
- performance measurement and control;
- team learning and feedback.
Students writing about leadership, organisational behaviour, project management or team performance are usually expected to do more than name a model. Saying that a team entered Tuckman's "storming" stage because two people argued is description. Stronger analysis asks what they argued about, why the team lacked a decision process, whether task conflict became relationship conflict and what management intervention would have changed the outcome.
Similarly, assigning Belbin labels to every member does not explain why an important task had no owner or why the final editor became a bottleneck. The model must be connected to observable evidence, its explanatory limits and a justified recommendation.
Students who need support interpreting management theories, applying them to organisational evidence and structuring reports or case studies may find specialist management assignment help useful. The underlying academic skill is the same one required in the project itself: moving from a familiar complaint about people to a properly evidenced explanation of systems, incentives, behaviour and performance.
A checklist for a group project that is already under way
Check the outcome
- Can every member describe the project's central argument in roughly the same terms?
- Does the structure answer the actual question?
- Are all required outputs and marking criteria covered?
Check ownership
- Does every important task have one named owner?
- Are reviewing, integration and submission allocated as real tasks?
- Do members know what "finished" means for their output?
Check the schedule
- Is there a date for the first complete draft?
- Is time reserved for review, revision and integration?
- Which current task could delay the entire submission?
Check communication
- Is there one current version of each file?
- Are decisions recorded outside the chat stream?
- Do requests name an owner, action, deadline and standard?
Check team performance
- Are missed commitments discussed promptly?
- Can members admit confusion or delay without being humiliated?
- Is disagreement focused on evidence and criteria rather than personalities?
- Is contribution being reviewed before the final day?
Check academic integrity
- Does everybody understand the institution's rules?
- Have all sources been located and verified?
- Are AI-assisted elements permitted, checked and declared where required?
Group projects usually fail gradually
A disastrous submission rarely begins with one dramatic event. It develops through a series of small unmanaged decisions: a role that was never clarified, a draft that arrived a day late, a concern nobody wanted to raise, a meeting without recorded actions and a schedule that assumed integration would take an hour.
The familiar "lazy teammate" may be part of the story. It is rarely the whole explanation. Group performance is shaped by whether effort is visible, whether responsibilities are specific, whether people can challenge weak work, whether delays are identified early and whether the reward system recognises individual contribution fairly.
A good system will not make every student equally skilled, motivated or available. It will make differences visible before they become emergencies. It will also prevent the most conscientious member from becoming responsible for every piece of hidden coordination and last-minute repair.
The most effective group does not necessarily contain the most agreeable people or the member who sends the most messages. It is the one that turns a shared assignment into defined work, makes decisions using evidence, treats conflict as manageable information and leaves enough time to produce one coherent result.
Sources and further reading
- Karau and Williams, Social loafing: A meta-analytic review and theoretical integration
- Aggarwal and O'Brien, Social loafing on group projects: Structural antecedents and effect on student satisfaction
- Piezon and Ferree, Perceptions of social loafing in online learning groups
- Edmondson, Psychological safety and learning behavior in work teams
- De Wit, Greer and Jehn, The paradox of intragroup conflict: A meta-analysis
- Buehler, Griffin and Ross, Exploring the planning fallacy
- Wiese and colleagues, research on backward planning and goal pursuit
- Association for Project Management, project planning guidance
- Association for Project Management, work breakdown structures
- Li and colleagues, Does peer assessment promote student learning? A meta-analysis
- Andrade, research into students' perceptions of team charters
- Luvison and Michel, research into revising team charters
- University of Warwick, guidance on group and peer assessment
- Higher Education Policy Institute, Student Generative AI Survey 2026