Project Groups for the Uninitiated


Teams should communicate early and often about their project and the projects status should be available for anyone to look at. If you don’t read the rest of this article, take that piece of advice to heart.


Since August I have been working on my MS HCI (Masters of Human Computer Interaction) at Georgia Tech. I also received my undergraduate degree from there and as such, had many many projects for class. Most of these were group projects. Overall, I felt that while the projects were good and fun, we never had a comprehensive “This is how you function in a group” type of lecture or reading. With that said, I have decided to write one.
This article is targeted mostly at college students working on software projects together. This also assumes that there is the ability to shuffle priorities and goals as reality unfolds. In situations where there are firm features decided by a different person (such as a professor or TA) then some of these pieces of advice are less useful.

Forming the Team:

While most classes which have group projects will be up front about that requirement, the details will usually be left out until much later in the term. You should not worry about forming groups until there are firm guidelines for the project. This post isn’t about how to pick good teammates, but in general favor people who know you will work well with. The worst team problem to have is being under pressure and not liking the people who you need to get a good result.
Between the time you meet your teammates and your first meeting some things should happen.

  • Exchange phone numbers, email addresses etc
  • Create a Google group and invite all members
  • Create a Google doc and share it

The idea is that this will be the backbone for communications within the group. After this, schedule a meeting withing a week of forming the group. There is a lot of work to be done and the team has to get used to each other sooner rather than later.

First Meeting:
The first meeting is about team structure and introductions. Even if you already know each other, it is a good idea to reintroduce yourselves in terms of why you are in the class and what you hope to get out of the project. The project leader and note taker should be decided.
Introductions and reintroductions are going to be different for different groups. Generally, each person should say why they think their skills will be useful to the project, decide which skill they want to improve, and give a statement about what will make them think the project is a success.
Next, leadership should be assigned. The project leader is responsible for making sure that there are no roadblocks, keeping meetings on track, and being the final arbiter on plans for execution. The note taker should record decisions made at meetings and publish them in the shared documents.
Finally, discuss the project itself. This is a brainstorming session. Try to block out features in wide swaths and try to get a feel for the technical needs of the project. From here, assign different people to different areas of the project based on their expertise and their desires to learn. This is why we did reintroductions and reintroductions.
Finally, have everyone post their entire course schedule with deadlines of assignments onto a shared document. This should be used to get an initial gauge about how much time and when members can contribute. When this is done, decide a time for a second meeting and break.

Second Meeting:
In this meeting, the team will begin working on the actual project. If this is a software project, have someone set up source control, a build server, and have these issue regular emails to the team about the status of the project. Subversion, Hudson, and Google Apps will help these respectively. The idea here is to maximize transparency, everyone can see when everyone else worked and they can easily see what work was done on what day.
Begin paper prototyping. A table PC will help with digitizing and sharing the records, but a pen and paper and scanner work as well. Play with lots of things and have fun. Run through some scenarios describing users and what the system will do in response to action. From this experiment determine a list of goals. Put these goals on a time line and make this your schedule.
This is a good meeting to discuss technologies in earnest. Try to pick a system which will maximize everyone’s involvement and will allow people to grow new skills. Don’t worry about your design being too simple, a good software project will scratch an itch and be stable.
Finally have the note taker post the drawings and notes as well as determine the next meeting.

Continuing the Project:
As the project goes on, interest will wax and wane until crunch time. The team should meet regularly, but not continuously. Once every two weeks should be the minimum. but meeting more than twice a week could prove frustrating.
At these meetings the schedule should be reviewed as well as everyone’s contributions on their parts. If someone is behind try and figure out why. This isn’t a time to assign blame, but it is a time to make sure that the project isn’t going to be in jeopardy.
If after a few meetings the team doesn’t like the results, find out why. It is OK to start over and radically change ideas. One of the points of the build server is so that it is easy to asses the project as it stands at any time.
During this time, have frank and honest discussions. It is much easier to address problems early in a project than later.

Crunch Time:
Crunch time is a miserable to for all participants on a team, but it does provide focus and drive for getting a project completed. There really isn’t much advice that can be given here other than:

  • Eat well
  • Sleep regularly
  • Relax regularly
  • Be respectful

Many people will forgo all of these at the expense of their enjoyment of the project. If a teammate is stuck on a feature, have them work on something else. The product can always use polish in various areas and a little presentation will go a long way on the final grade. If problems arise, solve them quickly.

I hope that someone finds this advice useful. Feel free to comment and I will respond. This document will be proofread and updated as time goes on, but I felt it best to publish early and publish often.