After participating in many student team projects, as a student and now as an instructor, I have collected a set of student project myths. These myths have been observed by me several times over the years, and I continue to see them. By presenting these myths, I hope to enlighten you BEFORE you fall into the relevant traps - thus maximizing your successful completion of your project on a technical and personal level.
Myth #1: Everything Will be OK if I Work with My Friends.
Many students like to work with their friends. Enough that complaints are often raised when that is not the case in a class. Sometimes the friends are also roommates, and so convenience is an issue. But the usual reason is that students are confident that the project will be successful when they work with someone they know and who knows them (and how they work, think, etc.). This is very risky.
You are friends with someone, and thus you know their character, background, ambitions, skills, moods, and how he/she approaches a problem. This being the case, this may not be a good enough reason to work with the person. Just because you know these things about a person, it doesn't mean that these are positive things. Yes, there is the saying that the "enemy that you know is better than the enemy that you don't know." But that is a sad approach to a friendship and to a project. For example, one student team included two close friends (out of 5 people). One of the friends consistently did not participate in meetings nor contribute to the project work. Occasionally he would hand in something of poor quality, and it would be late. This affected the project and all of the other members were unhappy about this behavior. The student who was a friend of the "slacker" told me that he know that his friend was like that but he wanted to work with him anyway because he was his friend. This is a true story, and it baffles me to this day. Other issues that can arise are:
I have seen all of these things in several student teams. And since the friendship is primary, I don't think that the students see these as issues. While working with a friend will not inherently ruin your project or team, there are risks that counter the myth that you should consider.
Lastly, you are missing out on making new friends and learning from them. I made many good friends from people that I met on teams.
Myth #2: Long Meetings Are Useful
Time is precious. You may have a job, a family, other coursework, and perhaps other team projects. As such you want to spend time with all of these parties while still having some time for yourself. Long meetings work against that. What is long? Over 2 hours is too long.
The longest meeting for a team project that I was a part of was 6 hours. And a great deal was writing a document as a group (see Myth #2). To be frank, I walked out of that meeting very irritated and mad at the person who insisted that we meet to write the document as a group. I felt that my time was wasted.
More recently, I have had students tell me that they had meetings as long as 12 hours long! And these meetings often went into the early morning. These meetings were usually right before some critical aspect of the project was to be delivered (using an incremental process model).
What could have shortened the meeting time -- preparing for a meeting and creating a schedule (and sticking to it). Really long meetings are often considered "working meetings" whether it be writing a document or coding. These meetings can be shortened to what a meeting should be. Work is done ahead of time to prepare to the meeting, and then the meeting is held to discuss or refine the work. If you do all of the work there too, the meeting automatically becomes longer. If preparation is done ahead of time, you aren't losing the team's input but instead you have something to discuss or build upon. You can accommodate the preparation with the project schedule and determining intermediary deadlines for tasks that will ultimately become agenda items for the relevant meeting.
Such meetings can also be a sign that people don't trust that their teammates will complete the work. This is an issue that needs to be dealt with on it's own and having long meetings won't solve the trust issue.
Myth #3: Distraction and Goofing Around Does No Harm
I talk about this a bit in Myth #6, but you don't have to be at someone's apartment/house to be distracted or to good around. I know that students (including myself) have enjoyed teams where people feel comfortable around each other enough to joke around. But you don't want the lightheartedness to eat away at your meeting time. The same can be said with distractions.
Distractions can take many forms, whether they be based on a prop (e.g. cell phone, project-related equipment, game) or a person (e.g. people walking/talking around or near the meeting). Both types of distractions can prolong a meeting, can cause long lapses of project activity, and can cause hard feelings among members.
We all know someone who seems to have their cell phone surgically attached to their hand (and ear). Distractions in the form of interruptions may seem to only affect the person getting the phone call or the instant message, but that person is being pulled away from the team. Waiting for the result of an interview is a special occurrence, but constant interruptions are viewed as rude where one's commitment to the project may be questioned. Discuss this early in the project, and have rules regarding distractions in general and specific types (e.g. cell phones).
I had a team that kidded around so much that they also put it in their meeting minutes! This can lead to problem though, especially when these minutes are shared with a person external to the team (e.g. project sponsor, instructor). If you need some time to "get it out", do so in the first few minutes and then move on. But excessive joking (e.g. wisecracks, name calling, etc.) can cause the meeting to be much longer than it would otherwise have, which can cause some people to become very irritated over time. Also, people's feelings can be hurt depending on the nature of the joking around. It can also been viewed as being unprofessional by some who are not in "the group" which may have an impact on their perception of you.
I had a team where several members were friends, and the rest became fast friends with the others. However the joking spilled over to a meeting with an external visitor and myself, which came across as being VERY unprofessional. This came out in their evaluation.
Myth #4: Student Team Projects Are Not Like Projects in Industry
I believed this myself at one time and I hear this from students from time to time, especially when things are not going well. It is probably a way of not losing hope that things can improve. Yes things can improve, but let's step back and think about it for a moment.
You are on a team in an upper-division course with a student who is not doing his/her share of the work. You think to yourself "well this would not happen in industry." Well, this student will likely graduate and will get a job somewhere. Out in the workplace, there are teams that may contain members who are not working there fair share. This may be for many reasons, and it may even be the case that this person will not be fired (e.g. the CEO's kid). Some people are also very adept at hiding their lack of participation. There are MANY stories of such happenings in the workplace. The same can be said for:
But before you change majors, computing is not alone here. The skills that you acquire and build upon will prepare you to navigate your way through these things as they happen.
Myth #5: Meetings are Productive When Held at Someone's House/Apartment
While convenient and comfortable, holding meetings at someone's house/apartment is asking for trouble. The biggest hurdle to productivity is distraction and a college students place of residence is full of distractions that some or all of the team would rather use or do over the meeting at hand. The biggest distractions are:
Each of the items or individuals mentioned about is a part of life for many people, but there is a time and a place for everything - and mixing them with meetings can be not only harmful but also destructive to the project.
As much as I like playing video/computer games, I will use it as an example. As an instructor, I have had more than one team explicitly mention that computer games (in these cases online games) played at someone's apartment during what should have been team meetings was disastrous to the quality and quantity of what was delivered. This was compounded by the fact that 3 of the 5 of them were friends and roommates. They were bright and capable, but they admitted that the distraction of gaming in the apartment was hurting them (and their grades).
It is a good idea to meet at a neutral location that is conducive to getting work done. If there are meeting rooms or tables in your department or library, use them. Many schools nowadays have nice meeting places that have whiteboards, computers, projectors, and nice round tables that are helpful in conducting meetings. If you need to reserve such resources, then do so and do so as early as possible. Such meetings locations and resources will enable you to conduct a more productive meeting than in someone's cramped dorm room or apartment. Such locations are also easy to find for everyone, relatively quiet (no roommates or pets around), and there is enough parking (generally speaking).
Myth #6: Everyone Should be Accountable for Everything
This is often a side effect of not having or using team roles properly. Even with a egoless team structure there is accountability. If you say that "everyone is accountable for everything", you mean that no one is accountable for anything. Part of having a team is to use the efforts of many to solve a large problem. To do this, you want to have some control over what is happening and where the project is going. Just because someone is accountable for something does not mean that he/she is the only person doing the "something." In the case of the project, you want (and need) someone to be the lead or manager for things such as tool support, scheduling, customer liaison, system architecture, or a specific technology. Even things like packaging the system for deployment or sharing the meeting agenda before the meeting should have someone who is responsible for them. People can rotate responsibility, but at any given time you should know what you are responsible for. This will improve morale and confidence among the team members.
I have spoken to many student teams who say that they don't use roles. These are often the teams who lose their documentation, meet excessively, deliver systems with missing or incorrect requirements, and say "I thought you were going to do that" many times during the project.
Myth #7: A Team's Mindpower equals that of the Individuals that Comprise it
Many people do not understand the power of teams. In software development, projects are often large and complex - to much so for any one person to deliver (within a reasonable amount of time anyway). Hence the needs for teams. Even in project courses this is the case as you are given a relatively large project and you have a relatively short time (a few weeks) to deliver it. To accomplish the project, you and some of your classmates are assembled in a team. You all may be smart and have a high level of technical skill, but no one of you can deliver the project by yourselves.
How I see this manifested in teams is where work is always delegated to team members (where the expert in a task is always the one assigned the task) and no collaboration takes place. Instead the project is merely seen as a set of tasks that need to be completed but no collaboration or even much discussion takes place. When discussion does take place, it is usually a person or two who drives it based on their prior experience.
This is where the myth comes to be. Many students (and others) believe that the team is made up of individual brains that each have their assigned tasks for the whole. While there is truth to that, the REAL benefit from being in a team is that the team "brain" is bigger than those of the individuals. It is this bigger team "brain" that can be used to solve more complex and bigger problems than any one team member can solve. It should also be said that the individuals grow personally to as the collective mindpower is an excellent resource to gain new skills which will be helpful later on in subsequent projects.