This note is fairly long, as there is no one-size-fits all summary for the issues groups face, and this advice may or may not be applicable to other situations at ITP. Take it with a grain of salt.
THE PROBLEM
Because groups require synchronization among people with different skills, styles, and goals, no group can be perfectly in synch all the time. Group work invariably creates periods of boredom and periods of stress (sometimes even at the same time, as when a group is procrastinating.)
Given these conditions, the surprise is not how often group projects fail, but how often they succeed. Put under pressure, creative people can accomplish remarkable things in short periods. However, even when the work is successful, there are two common downsides to group work at ITP.
First, when a group does a significant amount of work at the last minute, there is little time to consider alternate approaches to the problem at hand. Lack of reflective time is a disadvantage in any creative endeavor, but it is doubly bad in an educational setting.
Second, the experience of the individual often has more to do with the group process than the final product. Therefore, even if the project is a success, it can leave the participants with a distaste for group work if the process was agonizing.
The literature concerning work in small groups holds both good news and bad news for ITP.
GOOD NEWS, BAD NEWS
First, the bad news. Working in groups is not like baking a pie -- there is no recipe for getting it right every time. Groups are fantastically complex entities, and groups will sometimes fail no matter what you do.
The good news is that there are a number of things you can do to improve the odds of success. The literature is too large to summarize in any comprehensive way, but here are a dozen things I think I know about working in groups that may help you get more out of group work while you are here. Some of them are things you can do to prepare for group work, some of them are things the group can do together at the outset, and some of them are ongoing habits.
They are:
The principal concern of an individual in a group is to be treated fairly. In order to ensure this, people often affect a kind of bland disinterest that they don't really feel ("I don't really care, you guys. Whatever we decide is fine with me.") Though this is often done to demonstrate flexibility, if everyone is overly amenable, the overall effect can be paralysis.
You are at ITP to do something. So is everyone else. Of course you care what the group decides. Some kinds of work will satisfy your intellectual curiosity. Other kinds of work will bore you to tears.
A critical step in preparing for a group project is to embrace ego. You have things you want to learn, questions you are asking yourself, work you want to get done. Pretending you don't care about group direction helps no one. Admit to yourself that you have interests and goals, then share them with your fellow group members up front.
The flipside of embracing your own ego is to embrace those of the rest of the group as well. They have interests and goals too, and rather than having everyone disavow their goals until the procrastination causes a crisis, getting a list of interests and goals out in the open in the beginning (ideally in the first meeting) will help everyone imagine shared work which could create interesting overlaps.
2. Use the group for having ideas, not just ratifying them.
If your project is just a laundry list of the individual members' preoccupations ("We're working on a kind of 3D video networked physical computing game that explores subcultures in virtual spaces"), then the project isn't really group work, it's a junk drawer.
Groups are fantastic tools for having ideas. An effective half-hour brainstorm (throw out ideas rapid fire, express everything in one sentence, postpone judgment until you have a big list) can produce more ideas and more varied ideas than if you each work alone for several hours.
Groups are also fantastic tools for shaping ideas. Having someone re-express your thoughts and vice-versa exposes ideas to multiple points of view, and the hallmark of a good working environment is when no one can remember who first thought of a particular idea.
If you are simply proposing your own ideas and expecting the group to ratify them, you are missing out on one of the biggest benefits of group dynamics.
3. Beware premature optimization.
As Don Knuth famously said in The Art of Computer Programming, "Premature optimization is the root of all evil." Avoid adopting fully fleshed out ideas too early. Ideas you can understand the moment they are expressed are frequently boring to execute. Big, messy, or imperfect ideas are more frustrating at first, but often make for much more satisfying work. Settling on fully formed ideas too early can short-circuit one of the most creative periods of group work, namely considering a variety of alternate ways of approaching a problem.
You will of course need to come to a clear definition of your work, but it doesn't have to be 15 minutes into your first meeting. Give yourself some time to work together generating lots of ideas before you settle into any one course of action.
4. Structure is not tyranny.
In a marvelous essay called "The Tyranny of Structurelessness", Jo Freeman took apart the idea, then prevalent in the women's movement, that formal structure was inherently oppressive and that groups would function better without it. Freeman argued that on the contrary, groups had to have some sort of structure to get anything done, and that when a group sets no formal structure, it gets governed by a secret structure, usually a star system driven by one or two forceful personalities. And because that structure is officially not supposed to exist, it is difficult to change it if it needs changing. Having an effective group structure in place can help protect the group from two common dangers -- a member who tries to take over the group, and a member who tries to slack off.
Structure is not tyranny. Your group should figure out, at the first meeting, how to coordinate the efforts of the overall group -- how often to meet, how to share notes, and so on. This does not need to be a tome; a simple description of "How we do it around here" is fine.
You should also choose someone responsible for project management, who will be the keeper of those procedures you've agreed on. (It is possible to spread project management functions among the whole group, but you should all be ready to shoulder the additional process overhead this creates.) There is always some risk that the project manager will become the de facto goal-setter as well, but having some explicit organization makes that outcome less likely than if you simply let the structure form secretly. The functions of goal-setting and project management are different, and the role of the project manager is more like a den mother than a dictator.
(I use the term 'den mother' advisedly, as the person best suited for this role in any group is often a woman. Though the reasons for this are (well) beyond the scope of this note, if your group does choose a woman as project manager, make sure she is not just being mommy-tracked. See the note on matching roles and goals below.)
5. Decide how to decide.
In addition to the organizational functions, you should also decide, at the first meeting, how your group will break deadlocks. There are several possible alternatives, each with advantages and disadvantages:
- Consensus: Consensus decisions have a natural appeal, as they maximize agreement. However, they can also minimize possibly fruitful disagreements, and they hand veto power to each individual member. Consensus is probably best as a goal, with a backup plan for making decisions should consensus fail.- Quorum voting: Quorum voting is a more formal alternative, where a majority vote of a majority of the members is enough to settle an issue. However, while voting works well in large groups, it is less effective for small groups, as a group of 5 that persistently splits 3-2 can end up simply overriding the opinions of two of its members with every vote, and even-numbered quorums can split hopelessly, requiring some additional mechanism for tie-breaking.
- Weighted voting: Weighted voting makes sense when chosing among several options. Weighted voting involves having each member rank their preferences, then adding up all the scores to select the highest number. (If there are 6 options, say, your favorite one gets 6 points, your next favorite 5 and so on, down to 1.) Alternatively, you can have every member give each option a score of +1 (I Like It), 0 (Ok, Not Great), or -1 (I Hate It), and then chose the highest ranked option.
- Random choices: One of the groups in my class came up with a novel solution to decision-making. If they reached an impasse, each of them articulated a point of view, and then they used a random number generator to select the group member who would decide that particular issue. This avoids the 3-2 split problems of voting. However, it has the disadvantage of putting considerable power in the hands of the person who first articulates the impasse.
None of these methods are perfect, of course, but in many ways it matters less what method you pick than that you pick some method. In the same way remembering to take an umbrella reduces the chance that it will rain, being prepared to take action against deadlock makes groups more willing to argue to consensus.
Whatever method you pick, care must be taken to include absent members without letting them exercise a pocket veto. Face-to-face meetings with all participants in attendance are ideal, chat rooms with everyone in attendance are a not-bad alternative, but outside of those situations, 24 hour notification by email of an issue that needs to be decided, with forfeiture of voting rights after that, is probably a good compromise.
6. Settle on social software.
No matter how short the project or small the group, if the work is conducted outside class, the members will spend more time apart than together. This makes your use of communications software critical.
A significant amount of group communication will be by email. Email has the advantage of being asynchronous and self-archiving on the members' machines. However, it is often difficult to make decisions in email ("Is Henri not answering because he abstains, or because he hasn't checked mail?"), and discussions that could be solved in 10 minutes in real time can take four days in mail. Email archives are also not publicly accessible, should you need to involve someone else in the group conversation, or use the group conversation as documentation for the project.
Plan on using email to coordinate, but get everyone to agree to check their email regularly, and adopt some formal way of indicating in the subject line when a decision needs to be made ("Subject: VOTE REQUIRED"). If your project is particularly long or involved, you may want additional types of social software. Creating a mailing list for the project on topica.com or groups.yahoo.com will give you a public and searchable archive. Scheduling a short weekly check-in meeting on IM can help accelerate decisions that would take longer in email. Using a wiki (a piece of web software designed to support collaborative groups) can help you gather and organize resources, and so on.
Nothing is better than meeting in person, and there is no perfect piece of software to use when you can't, so you need to make decisions about what social software to use and how to use it. Email is a given, periodic use of group IM adds a useful real-time element, and there are lots of other tools out there. Err on the side of too little software rather than too much -- process overhead can kill small projects -- but agreeing on a core set of tools you use when you are not together will make things much easier.
7. Get it in writing.
When you do settle on a group project, get in writing, the shorter the better. The ideal project statement will express in a few words what the group goal is. This is not a mission statement or documentation for the professor. The closest parallel is something like the Quakers' "sense of the meeting" -- a statement that captures as succinctly as possible what you intend to do together, whether it's a project goal ("We want to build a pair of mating robots") or an educational goal ("We want to explore video handling in Java") or both.
If you cannot express a shared goal in a few words, then your project is too big or diffuse, or you haven't yet come to a group agreement, or both. Once you have it, you don't need to show it to anyone else, but you should revisit it periodically to see if the project has drifted from the stated goals, and if so, whether the project should be brought in line with the original goals or the goals should be restated to reflect the new sense of the group about the project.
Expressing a shared group goal is harder than it seems. In a free-wheeling conversation, its easy for everyone to hear what they want to hear, but trying to get something down in words can expose significant differences of opinion. This may be the most argumentative hour your group spends together. For that reason, this work is worth doing in person with all group members in attendance if at all possible.
8. Match roles and goals.
The individual members of your group will also face a tension between project goals and educational goals. Consider a hypothetical group of ITP students: a programmer interested in user interface, a designer interested in project management, and a project manager who wants to code. The most effective project will have everyone doing what they are best at, while the most educational one will have everyone doing what they are most interested in.
There will always be a tension between what you already know and what you'd like to learn, both at ITP and after, and there is no one good answer for balancing your talents and your interests when they diverge. There are however two distinctly bad answers that should be avoided if at all possible.
First, you should worry if you or any member of your group feels pressured to do only work that bores them. For a project to be worth doing, it should be worth doing for everybody; if you are being slotted in as the interface designer even if you came to ITP to learn something else, speak up. You may have to do some of that work, but you should try to find a way to share the load, and to find work on the project that flexes other muscles.
The other bad outcome is if someone shoulders the lion's share of a particular job and does nothing to explain their work to the group. There are some spookily talented people at ITP, and its easy to treat what they do as a black box ("Well, she just, uh, made this Java server-side thingie that makes it all work...".)
Resist this temptation. If someone offered you a chance to suddenly know what all of the teachers at ITP know, versus knowing what all your fellow students know, you should not hesitate to prefer the latter to the former. No matter what the division of labor, make an effort to explain what you are doing to the rest of the group, and vice-versa. When you describe your own work, you learn it twice, and while listening to someone's brief description of designing a server module won't make you a programmer, it could help you understand how to communicate better with programmers as colleagues in the future.
9. Accept inequality.
No matter how carefully you plan a project, the workload will be unequal. Some parts of the project will go more quickly than expected ("I found existing code that did about 80% of what I wanted.") while other parts will run into unexpected difficulties ("I blew up 3 BX-24 chips.")
Instead of worrying about equality of effort, worry about equality of feeling. Is everyone engaged? Is everyone doing at least some work that interests them? If there are unexpected difficulties, can people call for back-up? Is there enough of a process that if things get badly out of synch the project can be re-arranged?
The one problem that can't be easily solved is having a group with a member who either doesn't have a taste for group work, or is simply slacking. In that case, the best you can do is to avoid giving that person veto power over the work, which usually involves having some agreed-on structure and method for making decisions.
10. Talk about the relationship.
It is unlikely -- impossible, in fact -- that your group will adopt the perfect way of working together at the first meeting. Even if individual members know one another well, it will almost certainly be the first time you have worked in a group of that configuration.
As a result, the first few days of the project will likely have a tentative feel. Once the group begins to cohere, you can drop this tentativeness and be more forceful in your discussions and arguments, a process made easier if you meet to explicitly discuss group process.
Watching one particular group in my class use a wiki was a revelation. In their first week of collaborating online, they were just getting to know one another, and used almost none of the software's native capabilities. In just a few days of work, they became frustrated with one another, the project, the software, the class, and me.
At the end of that week, they met in the lounge, and in less than an hour they worked out a new series of very simple rules, protocols, and agreements. Not only did their productivity explode, but the rules they worked out allowed them to use the wiki the way it was meant to be used, allowed them to coordinate the rest of the project with very few in-person meetings, and made the work considerably more engaging for all of them.
They couldn't have adopted those rules on day one, because they didn't know what they wanted or needed to do yet. No group project can be perfectly specified in advance, so plan on spending some course correcting time as you go, talking about how the group structure might be improved.
11. There is no substitute for time.
This falls in the category of unfortunate inevitabilities. Groups take time to gel, and function better the longer they work together. You have probably had the experience of finishing a group project, and then feeling like you had only just figured out what you needed to know to get started. This is perfectly normal; though there is a common belief that groups get stale, recent research into the way teams work suggests that long periods of working together are beneficial. When there is a risk of staleness, it generally appears only after years of working together.
Some group projects unfold over most of the semester, others in just a week. There is little to be done about changing the amount of time you have to work together other than making some essential decisions immediately (what social software will you use, how will you make decisions, and so on.) The other thing you can do is accept that a group that has been together for a day cannot operate as well as a group that has been together for a semester, and to gauge your expectations of the group to the time you've had to get to know one another in that setting.
12. Have a drink. You've earned it.
Small group work at ITP suffers from what one of my students calls the "one-project stand" problem. Whatever group you are in, it is likely that that group of people will never be assembled in exactly the same way in the future. Since groups work best when they have significant continuity over long periods, this puts project-focused teams at a disadvantage.
There is no perfect way of handling one-project stands, but there are some general principles. First of all, though you may never be in the same group again, you will still be in the same program, so it would be good if you were able to respect each other the morning after the project is due.
More importantly, life is long, ITP is short. While its easy to focus on the hothouse atmosphere the floor can take on while you are here, your fellow students will be an essential part of your professional network long after graduation. This also argues for treating group work not as one-project stands but as ways of deepening your network.
Pick a time when you can all get together off the floor after the project is over. Go to Bowl-Mor, go to Patsy's, go to the park, whatever, but sit down together and talk about the experience of working together. Imagine alternate problems you might have taken on, alternate approaches for the problem you did take on, what a next version of the project might look like, and so on. Talking together after the pressure's off will be useful for understanding the work you did together, and the ways the group dynamic affected that work.
GROUP WORK IS HARD, BUT WORTH DOING
Academic work typically focuses on individual achievement. ITP is unusual in the amount of group work it requires. Though this is in part because in the fabled Real World group work is the norm, group work at ITP is in many ways more complex, because real world teams are usually assembled after the goal has been identified, while here the group must invent both the problem and the solution.
There is a more important reason why group work is critical to ITP: There is a large class of problems that can only be attacked by groups. These are problems that require significant effort, multiple points of view, and overlapping and complementary skills. The attitudes and techniques mentioned here cannot guarantee that every group you participate in will be easy or enjoyable; it is the inevitable difficulties of group work that make techniques like these important in the first place. Trying them (or any set of methods for making group work successful) is well worth the effort, because when a group works well together, there's nothing like it.
-clay
December 6, 2002