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

Question

I am currently leading a three person team to tackle an undergrad engineering project that involves several parts. I am responsible for data analysis using sophisticated computer algorithms, another is responsible for creating a software graphical display and another is involved in the programming of a piece of hardware.

The problem is that both of those other students are freeloading on my efforts and neither has contributed much since the project started in May of this year (that's 6 months of doing next to nothing).

In the lasts couple of months, every two weeks we would have a team meeting with our project supervisor. The team meeting involves a submission of progress since last meeting. Here's what would happen: one or two days before the meeting, a person will do something that is tangential to what he is assigned to do. For example, it could be setting up a piece of software, or trying someone else's code. Nothing is ever successful and in every single progress report I would see them putting down "investigating alternatives" or "still under research". What? You have been researching for more than half a year.

The most irritating issue for me is that they are both freeloading on my efforts. Because data analysis requires a huge amount of experiments and organization of the data, every once a while I would get them to spend less than 30 minutes with me (amidst whining and complaining and playing with cellphone) on organizing about 4 TB worth of data, while I spend the next week incessantly work on the data analysis, organization of the data, and preparing for presentation at project meetings. You've guessed it, this is exactly what they would put down on the progress report - "helped team member X to perform data organization". In addition, when they are stuck on their parts, I am often forced to take over just to meet the deadline. To be honest, I have single handedly spear-headed every single aspect of project (even though I have never done GUI or hardware programming!) because things are never delivered and there are no immediate, effective checks to keep them from not delivering their work.

MOST irritating aspect: they have put my work onto their LinkedIn profile!

The top excuse that they give is that they are busy with other courses. Since this project is over a long period of time and graded based on overall success, they do not think it is as important as their other half semester courses. They keep on telling me how they are so busy with their courses and everything is due on the next day and midterms is next week they never think that I have the exact same workload (if not more). I also don't have any financial power or control over their grades as we do not have any official reporting system put in place to get them working. Also it is impossible to kick them off of the team without shutting the project down.

I want to signal to my project supervisor that they are not performing AT ALL. This will definitely come as a surprise to him since every meeting there are enormous progress (all from my end) and the project has been an overall success. I am also kind of upset that my team members are going to chip in on a potentially big prize at the end of this year.

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Fire your team. Tell your supervisor that you're going it alone. The other team members are free to take what you've contributed so far and finish it up, which they probably will have trouble doing. I had a programming partner who basically dropped out of school to do drugs and so I submitted the final project with only my name. He complained to the instructor but I responded with how he abandoned the project to party and do drugs. The instructor let him take what I had given him to that point and try to complete it. He could not.

"Leadership" can't solve most problems like this. Next time choose your partners more carefully. No amount of inspiring leadership will make incompetent team members competent. The key to leadership is choosing the right team. If everyone on the team is good then the other problems take care of themselves.

In the private sector, it is the supervisor's job to find dead weight and either put them somewhere that they can be productive or get rid of them. Dead weight is incredibly corrosive to any team and once a few people start getting away with it spreads like a cancer to everyone around them. "If so-and-so can get away with hardly doing anything, then I will too!" If the whole company is like that, and I've seen it happen, then the solution is to find a better job.

xLeitix mentioned this is like the real world with competing project priorities. If it's a matter of resources available due to project priorities, then the supervisors will have to work out as a company which people need to be working on which projects. If your supervisor tells you someone can't help you with the current project, then you tell him or her it will take longer since you'll be doing it all alone. And if company politics don't allow you to work on the other guy's technology stack, then the project will simply have to be on hold until that changes.

Answer 5

I was with a similar group in uni. Instead of seeing it as a hindrance, I embraced it. Their lack of input and interest meant that I had full autonomy and control over the project. Yea you have to work harder personally, but what you produce will be top quality, and lets face it, if they did contribute, it would probably be so half-assed it would drag your grade down anyway.

I embraced it so much that I elected the same lazy f**ks for all of my group projects. I enjoyed having full control. I was never disappointed with any of my grades, that's for sure.

Answer 6

Group dynamics are the responsibility of the group

The short answer to "How do project supervisors address the “freeloading” problem in group projects" is that they don't. It's generally the responsibility of the group to allocate the tasks and the share of effort. If they are unable to do it in a way that's satisfactory to everyone (such as your example) then the solution is to change groups - if everyone really is freeloading off of you in the manner described, then you obviously are capable to do the project on your own. Due to the problem of sunk effort, it's preferable to identify such cases early and split up before too much work is done - giving this advice is something that the supervisors should be doing.

Other than that, the only long term effect is to avoid doing common work with those people in future. For such cases, it helps if such projects are organized not a single event but rather multiple smaller projects with possibly different groups - where functioning groups can stick together for multiple projects, and conflicting groups can re-form in a possibly better configuration.