How do project supervisors address the "freeloading" problem in group projects?

From your experience, what is commonly done for a supervisor to spot freeloaders in a group project and how are penalties handed down? How can I work with my supervisor now (who maybe completely unaware of the situation) to effectively put these people back to work?

As somebody who taught many courses with a similar structure to what you described: the common approach for supervisors to handle this situation is to do nothing (at least not on their own initiative). You are likely not aware of it, but you are in the middle of learning something that will presumably be more valuable to you than the hard technical skills of the project. You are learning how to handle team work that isn't going smoothly.

There is a good chance your supervisor is already aware that things are not working out in your project (your team mates have been reporting that things are "under research" for half a year while you have been delivering results - any half-decent supervisor knows what that means). He does not step in because one of the main learning outcomes of such a project is that he expects you to learn how to handle such issues.

So far, you are not handling it well. You are clearly very annoyed by the situation, but you do not mention any clear steps to resolve the issue. You cover their asses by taking over their work, and have as far as I can tell not formally escalated the problem. Instead, you are hoping that the "higher-ups" will figure it out on their own, and step in without you having to take responsibility. This is exactly how you should also not handle this situation in the real world.

And, I should add, do not hope that this situation will not come up when you work in industry. Replace "we don't have time for this because of other courses" with "we don't have time for this because of other projects", and you will have the exact same problem in the real world. Only in industry, the stakes for failing will be higher. As usual, university gives you a comparatively low-risk environment to train working on the same kinds of problems that you will also routinely face later on.

To end this with a practical remark: stop focusing so much on what they do, and what your supervisor should do. Start thinking of your environment as a context that you can't (directly) change, at least not without effort. Your task is to figure out what you can do to work in the environment you are given. This may include taking more responsibility for managing the group, or getting into a big, potentially productive fight with your team. This may also include formally escalating the problem.

I teach a design course. We have a number of checks in place to discourage this from happening.

Perhaps the biggest is we give a little practice team experience before assigning real teams. We ask each team member to evaluate their peers on the team. Students are then surprised to find out that their grades for the team portion of the overall grade are adjusted by up to a full letter based on these evaluations. We then let them know that this is how the rest of the year will be graded. This gets the grade-motivated students participating.

The rest comes down to making sure that each player has some buy in on the project. Our course is customer driven, with students applying to work on specific teams. Once the real teams are formed, I give a mini lecture on project management skills, based on a book by Heerkens (Project Management, from the Briefcase Series -- especially the section on "Accidental Managers"), and we discuss as a class why people participate more or less on teams. I point out that our starting assumption is that since everyone applied to participate on the team they ended up on, that everyone wants to make the customer happy. We also discuss that different people are motivated by different things. I ask the students to think about if they would be disappointed if they got less than an A in the class. After they think a bit, I ask them to consider whether their teammates feel the same way. I point out that some students have real obstacles that a team as a whole can help deal with -- like the student that lives off-campus and can't make 11PM meetings, or even a student that might be supporting a family the team doesn't know about, and has an entirely different priority set.

Once the projects get kicking, I ask for lists of weekly action items and who is to carry them out. If a TA (I have a fleet of TAs) notices that someone isn't taking action items, or not delivering on them, we'll intervene to see how we can get the student some more buy-in on the project, often by making sure there's an aspect of the overall project they can call their own.

Is this 100% effective?? Obviously not, but I feel I have some grip on such issues.

In this particular case, one must consider the possibility that the original asker might be part of a poisonous team dynamic that I see over and over and over (usually in the practice team experience, and then I teach about it in my project management lecture so it comes up less often on the real projects). This is where one team member becomes the self-appointed leader without really understanding what that role means. When this happens, you can end up with one person who assumes leading means doing more work, and sometimes can make other team members not want to work with that person. So, without trying to analyze the team, the person who believes that the others aren't doing their fair share might want to reflect on the situation and ask himself if he's done anything to help create this situation. A leader works hard to make sure he's getting the most that can be gotten from every team member, and the teammates are eager to work with him or her.

To offer simple advice for this case -- you seem to have periodic meetings and progress reports. That's a start. I recommend Gantt Charting the whole project, so you can start showing which parts of the project are moving along and which are not. This way, your teammates see it staring them in the face. Make it clear which tasks you are willing to work on and which parts you are not. When it becomes clear that there are gaping areas, figure out which teammates are going to handle what's left. Help them break up the big tasks into bite sized subtasks, with each tasks assigned to a responsible person. While you're doing this, you might consider asking your teammates if you're doing anything that is pushing them away from the project. If there is, figure out how you can make that stop happening. Apologize, if its called for, and let them know you don't want to dwell on it, but want to move on.

Every meeting should end with a list of ACTION ITEMS, along with the party responsible for each, and a target date of completion.

This way, assuming your teammates want to help (unless you've really alienated them!!) but simply are overwhelmed and don't know how they can best take a bite out of their project, you're actually helping them through the process (i.e., actually leading). Also, you'll have a record of who's supposed to do what, and it will be clear to everybody where progress is happening and where it's not.

Lastly, when you really sit down and start Gantt Charting, you might figure out that the plan is overly ambitious for the remaining time. If this is the case, no use tilting at windmills. Reestablish a new scope of the project that's actually achievable given the time and resources (human or otherwise), and talk this over with your teammates and supervisor.

In the long run, depersonalize it and stop working on blame. Your team is at point A, you need to be at point B. Figure out how to best get there with the resources you have.

Good luck.

The issue you are referring to is called "social loafing" and is a very common problem in teamwork. To fix this, us need to do a number of things but the most important is to shine a spotlight on everyone. When people are anonymous, they tend to do things the would not otherwise do (or tend to avoid things they would otherwise not avoid).

So, ideally, when forming the team, you would set out the ground rules for what is required to join the team and what are the rules for continues membership. However, this does not seem to work in your current situation (and the nature of your work might have made this unrealistic at the start).

The next thing to do is to ensure that everyone is responsible to everyone else in the team. That is, the members do not simply answer to the supervisor but they also answer to everyone else. In this case, they answer to you (and you answer to them). If they are not fulfilling the requirements for continued membership, then they get warned or removed from the team. However, again, this seems difficult in your situation.

If you do have the option of solving the problem through team design, then you need to resort to coaching/leadership. That is, you need to find a way to motivate them. Of course, nobody can you tell you what it takes because we do not know them. You need to find out what really motivates them and then you should work with that to try to get them inspired enough to actually get their jobs done. Of course, leadership ability does not happen overnight but it can be developed. The first thing you should do is to take a stand. That is, tell them that enough is enough and it is unreasonable and unfair that you are doing the lion's share of the work while they are trying to take an equal share of the credit.

The last recommendation I would make is to bring up to your supervisor what is actually going on. I assume he/she is bright enough to be able to monitor what's really going on. After all, yours is not the first team of students to encounter the issue of social loafing.

If you have no penalties (your supervisor should have these tools available) then your only option is leadership/coaching. Best to use both, if you can.