How do I eliminate a coworker from a project?

Question

For a university project I grouped up with two random students in my class (let's call them A and F). A, F and I are working on a project together that all three of us are REALLY passionate about. Me and A have been spending night and day slaving over making every detail perfect, because we are hoping to take this project beyond our class. Now the only problem is that F has spent little to no time on his portion of the project (even though we gave him SO MUCH opportunity to!), however he feels the same sense of entitlement and ownership of the project as A and I.

Now I don't care that he's getting a free ride on this project, but I'm curious as to how to tell him A and I DO NOT wont to work with him any more (for the second half of the semester), for A and I both have written 2-3 thousand lines of code, and we are not using a single line of code F wrote.

A and I need him gone, because he's just slowing us down if anything.

Answer 1

I really like Pawel Brodzinski and enderland's answers if your goal was an approach that could save F's participation in the team and make him into a working contributor. I'd strongly advocate this kind of feedback and expectation activity early and often when you have someone on your team who isn't meeting the minimum expectations of the group, and in a work situation it's almost obligatory that you do something similar before booting the person.

However, I wanted to make sure our answers covered actually getting rid of your non-performer. Assuming you've gone through as much feedback/expectation setting/re-negotation as you deem reasonable, here's some actual steps for elimination:

1. Talk to your professor or the advisor on the project. You have a serious situation and the professor needs to be in the loop. Different classes work differently on whether groups reform between projects or whether they are expected to be in a single team for the whole time - either way, your professor needs a heads up that you are changing the deal with respect to F.
2. Ideally he should be told BEFORE the grading has been handed out on the current phase. There are three reasons:
   • this was, really, a two man project. Hopefully it's an awesome, looks-like-3 people's worth of work type project - but the reality is that 1/3 of your team was broken. The prof may or may not take it into consideration when grading, but he deserves the information
   • who gets what grade should be figured out in parellel with the grade itself, and you aren't the one who decides whether or not this guy gets the same grade as you
   • whenever you have to restructure a team, advance notice is far better than emergency reconfiguration.
3. Talk through how to notify the guy with the prof. He probably has good ideas and may have actual things you MUST say to the guy. This is absolutely true in a real workplace - if you ever have to fire someone, legal and human resources will have LOTS of advice for you. Academic institutions are usually more fluid, but it doesn't hurt to get advice.
4. Assemble your facts, schedule a time with all 3 of you together, rehearse with A what you will say, and decide prior to the meeting what you want the end state to be. If you would be OK with an end state that includes F on the team, then you are really in the territory of other answers. I'm assuming your only acceptable end state is "F is not on my team", in which case, be clear on what assets would be available to F if he decides to pursue the project on his own. Can he use your source code? Can he use only his own source code? What about designs, test cases, or other documentation? Some of this will tie into what the professor proposes in step 3.
5. Be aware that there is no good way to have this meeting. You want it to be short, sweet, and very, very, very clear (so you don't have to do this twice). Avoid ambiguous wording and vague statements - it's easy to try to use wording that suggests that even though this guy has failed the team, he's still an OK guy - but there's really no way you can convey these two things simultaneously, and trying will result in (at best) confusion, and (at worst) the impression that there is no real problem. In cases like these, brutal clarity is really your best option - the analogy of ripping off a BandAid comes to mind.
6. When it's done, communicate it and the final status to the professor so he knows what's going on. Ideally, you want to write an email with everyone involved - something formal, written, and documented that shows your shared understanding of the situation.

From there, try to let F cool off. If you've been friends, the friendship is somewhat problematic at this point, and it's F's choice from here how much he wants to associate with you. Realize that everyone is going to see things in their own perspective, and give F the space to decide whether to continue to associate with you. It can go either way, so just take a break from the situation and proceed to work with A on what is clearly an intense project.

Answer 2

You need to have a conversation sooner, rather than later, where you discuss expectations from the group as a group. Do not keep delaying this conversation!

It sounds like you and A have been doing considerably more work than F was expecting to have to put in on the project. My guess is you have also had a lot of conversations with A about how awful F is, but never once talked to F or talked as a group about how to solve the situation.

Having dealt with similar situations in the past (multiple times...) with assigned team members, the key is to:

1. Come to a mutual understanding of expectations. Some people have higher expectations, are aiming for a 100% vs a 75%, etc, and this will be reflected in the amount of work they are willing to put in. Perhaps F is only aiming to pass, while you and your friend are trying to get a perfect grade - you need to at the very least be aware of this and talk through it as a group. Maybe F doesn't care about taking this beyond the class. You NEED to have an understanding on this subject or your semester will continue to be miserable.

2. Determine what efforts all of you can put in. Maybe after the conversation above, he wants to do documentation or reports or user interface design or something non-coding related or something you/A don't want to do? The conversation in (1) just has to happen. Figure out what each person's responsibilities are.

3. Treat this as a learning opportunity Regardless of how it is easy to just want to cut F from the team, consider that you are going to have to deal with people like him to varying degrees your entire life. In these cases, you need to work as a team - you, him, and A - and figure out how everyone can still contribute. I found it incredibly valuable in these situations in the past to treat it as a learning opportunity - "how can I better perform with non-contributing team members?"

4. Realize it's not just you who is frustrated It sounds like you/A just took the ball and ran with it. For all you know, the reason F is not contributing is because the two of you basically started without him and never really included him. He is probably equally frustrated, except his frustration probably is from the lines of, "these guys just don't care about anything I do." Ask yourself whether YOU would want to contribute under those circumstances.

Answer 3

What I believe you should start with is an open and honest conversation among all three of you. In such a situation it might be hard to keep the conversation only discussing the facts. After all, there are emotions of A and yourself involved.

Anyway, what you need to start with is everything you pointed here (and probably more):

• You're using mainly (only) code written by yourself and A.
• You both believe that there are enough opportunities for f to help.
• Yet you don't see him really working on the project.

Then, there's time to listen to f. For each and every of those points it is worth to ask you all questions: why? Possibly 5 times. Only then you may learn why f is failing you.

Then you may or may not decide to give him another chance. Either way, he's there with you till the end of this semester, isn't he?

Now, if you still want him to leave the group next semester, that's fine. I like the attitude that you don't care whether he's getting a free ride now. It will make it way easier to take parts.

What I'd do in such a situation I'd consider that everyone in the group has the same rights to whatever is the effect of your work till you break apart. I would do this even if there's no single line of code written by f. After all, if he didn't invested any work in it, the product and the code will be of little use for him anyway.

And this way you don't make anyone treated unfairly, thus make the whole split easier.

Answer 4

I guess you're looking for ways to break this gently? It seems your reasons are fairly objective. Tell him sooner rather than later.

Leaving him on your project could be a big mistake if you want to take this code outside the class. Although you may be able to show you've used none of his code, he can still claim he contributed to the project since his name is on it. And since you're making the code so perfect now, there is going to be strong evidence that the project code (with his name on it) is very similar to your production code.

Finish the project without all enhanced code. Branch the code into something new. Get a lawyer.

Answer 5

There is a critical detail missing in your question. You say that you hope to take the project beyond the class. But is that class two semesters long? When you say that you don't want to work with F in the second semester, does that refer to continuing the project beyond the class, or is that still within the class?

In any case, keep F on board until the school portion of the project is finished. Then, you two simply continue beyond the class, and keep F out of it. Put the code into a repository to which only you two have access and do not discuss with F any longer. Do not meet with F, and do not answer any of F's e-mails that are related to that project (if at all).

Do not bring in any of F's code (which you said you're not using anyway) and make sure that F's name does not appear on anything, since F didn't write any of it.

Answer 6

I encountered this problem as a project manager for a class programming project. There are two ways to go:

1. Be blunt with F. Phrase it such that it is a team grade and everyone's input is required. Granted, this far into the semester, this tactic is unlikely to work, and their continued disinterest is very probable.

2. Email or visit the professor. Explain the situation in whole. Describe the action you have tried to take and the continued lack of commitment from F, and how you would like to continue without F on your team.

The professor will either:

1. Tell you to deal with it. At that point, it is up to your best judgment to include or exclude F.

2. Talk to F and hopefully spur a change in behavior.

3. Remove F from your group and allow you to continue as a 2 person project.

If your professor is reasonable, your grade shouldn't be affected by the poor choices made by F. As long as it is obvious that an attempt to resolve the conflict occurred, and that you still have something to show for a final version, your grade shouldn't be affected.

Answer 7

I was in the same situation in the college days, but in my case, F was really a close frnd, thus it doesnt mattered that F worked or not as much as we did, but F gave the project presentation for us, in that F was really good.

In my case, A always try to be a perfectionist, thus he doesnt likes any of the work done by F. Every time, F tries to mark his presence, A always denies F's work, by saying almost the same words that you said The work F did in 4 weeks, i could have probably done in 2 hours.

So you better find out the best part of F(Asking a friend to leave the group is quite rude). Even if you want to do that, do it before its too late for F to get in some other project. Have an honest talk with F or even with the project guide.

Answer 8

Do it like you should:

• Bold: kick F out of the project right away telling him the exact reasons

or

• Diplomatic: wait until your team successfully delivers the project then never work with F again

That's how real life works.

The point is that I see too many great projects failing due to communication issues, just like the one @BakerBoy described. I think that waiting and hoping the time will solve your problems is not is good approach, also over-discussing a communication issue will only slow you down. You can spend your time with a great team creating awesome pieces of work, not over-analyzing this kind of things and over-looking for the perfect way to deal with a communication issue.

So I think the best solution is: make a damn decision and just do it. Obviously there are two solutions, a cold one and a warm one. I would just pick one and deal with it and continue to work on my project and "ship it".

• the cold one: "F", man, you're just slowing us down; maybe it's better to step down and leave us finish this thing [...]
• the warm one: "F", man, let's just finish this thing. These are your tasks, please make sure you'll deliver them on time [..] and then never work with this guy again.

And that's it, just move on. People come and go, some people are compatible and can work together, some are not. This is how life works and cuddling an issue like that is just a waste of time.

I hope I explained a little bit my answer above :)

Answer 9

I suspect the short answer to the question here is that you can't "eliminate your team mate"; as in many workplace situations, you and A simply do not have any direct power over who is (or is not) in your team.

This leaves you with three choices :

• find a way to make the project work and/or live with the situation
• make a case to someone who has that power (the Professor, or line manager)
• make the working enviroment so uncomfortable that the person withdraws

In selecting one of these I would suggest you should consider the longer term implications.

For example, as an employer, I tend to be more interested in what people have learned during their projects than the grade they obtained. This includes how they have managed a difficult or conflict situation with a co-worker - in fact I specifically ask this question of every potential employee, and take careful note of the response.

At interview, I'm not just looking for high-graded technical skills, but the soft skills and knowledge that you will bring into our team environment.

Two of the potential routes above would immediately flag you as an employee that is likely to be a signficant draw on my time as your boss; an employee that had managed to salvage the team situation has, to me, much higher value in the workplace.

While there are some good answers here that address the outcome you are looking for, I would strongly suggest that you and A need to reflect on how you could have managed this situation to a more productive outcome than simply "eliminating the coworker."