How do project supervisors address the "freeloading" problem in group projects? 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?
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.