Sunday, November 25, 2007

Surviving Group Projects

With few exceptions, at some point in your university life you will have to form a group with others to complete some massive project. If you're in more of the academic subjects -- english and history come to mind -- you may be able to avoid this fate, but for the rest of us, having other random people you don't know from a hole in the ground determining at least in part your success is an unfortunate reality of university. And, it turns out, the working world.

Group projects are easy when you have a solid core of people who all contribute to the project, or when the project is small enough that one or two decent people can do it all even if most of the group is useless. But what do you do when you've got a huge project and some clear underperfomers to contend with?

Read my blog, that's what. I'm here to help. Here's 13 guidelines for surviving a group project when it's all on your head to do a good job.

  1. Exchange contact information. This includes specifying a preferred method of contact (likely email) and an expectation of how soon responses will be given. Make sure there is a penalty (most group projects have a peer evaluation component) for late responses to queries. A good rule of thumb is to forfeit 2% the grade if a group member does not respond within two business days.

  2. Divide up the project by tasks, not pages. Make sure that "writing the report" is its own task, unless the report is so long that each section should be written individually. If you divide up a report by pages, it doesn't flow well and sounds like it was made by many different people writing in many different styles.

  3. Hand in hand with point 2, don't worry about being exactly fair in the division of labour. Maybe someone has to do a bit more, but you'll have a better project if people (or maybe a smaller team of 2 or 3 people) handle a specific area. One area might be more work than the other, but it's better to have a little unfairness and a solid product than a poorer project that had the labour divided exactly equal among group members.

  4. Set up expectations for deadlines, as well as the marks lost if those are missed.

  5. Once you've identified underperfomers, focus them like a laser beam on whatever you hate to do. I hate market research, so I tried to focus my Marketing group on getting that done for me. I still had to do some (after all, they are underperformers) but it took the pressure off where I wanted it off the most.

  6. Set up collaboration tools. Especially Word's "track changes" feature. If multiple people are editing a report (and they should, even if one person wrote it), then you can easily have four or five version of the thing floating around. Compiling that can be a nightmare. So at the minimum, track changes. At best, slap the report (or lab, or database, or whatever) on a server like Google docs and allow for multi-person edits to the same document.

  7. Don't get mad; shame people. I find it more effective to go to someone who hasn't been pulling their weight with some of their work already done and a request that they finish it.

  8. Unless someone is a total slacker, it's best to not fight very much about lost marks due to work quality. If it's measurable (such as not responding to e-mails or missing deadlines), then by all means dock them marks, but even then it's better not to get into a war over it. All you'll do is gain an enemy, and you won't have what you really want: sleep, and that person's part of the project done.

  9. Don't be afraid to take a leadership position, especially if you're doing all the work anyways. Some people aren't really underperformers, they just need someone to tell them exactly what to do. If they are legitimately a bunch of slackers, then you're probably going to be up until 2 am finishing the stupid project anyways, and that makes your word law.

  10. If you do take a leadership position, always explain why you think your ideas are best. Accept criticism. Just because someone is an underperformer doesn't mean they don't have good ideas. If any arise, don't be too prideful to use them.

  11. For the love of God, don't do everything yourself. Just because you're surrounded by slackers doesn't mean you can't use their stuff. Keep it as a base, and shore it up with the grammer/research/wording/effort it requires to shine.

  12. Have face-to-face meetings as often as you need. If it has to be at 6 pm on a Saturday, do it. You often can't replicate that input over email.

  13. Make sure meetings are on task. Establish a rotating chair for the meeting, and make it that persons job to set the agenda and keep things on task. Everyone has better things to do than meetings, so keep them short, sweet and to the point.

Finally, I should stress that you should still be a team player throughout all of this. Never criticize people, just their actions (i.e. do not say "you're an idiot". Instead say "I don't think this section has been properly cited/researched/whatever", and then say why you think that.) Remember, the goal here is not to do everything yourself, but to get as much out of your underperforming group so you don't have to kill yourself doing everything to make the deadline. And finally, remember that not all groups are populated by slackers, and that people do have other things going on in their lives than the project -- so take that into consideration before you give into the urge to blow up at them.

Saturday, November 24, 2007

Here on the other side of November...

Wow, it's been awhile since my last post. November is project month at university, and since I'm taking business and that means almost every class has a group project. Most of them, naturally enough, are due sometime in November. However, the biggest of them, my Marketing project, has been mostly retired and this has given me something akin to breathing room.

Which is why I'm going to take the opportunity to blog about technology.

Has anyone here seen IBM's Lotus Symphony? My opinion is best summed up by: high hopes. Based on Open Office, the premier office suite available for the Linux desktop, Symphony gives the office suite on Linux more developers, and God willing, a better interface and functionality.

Open Office is a fine product, especially given it's price. But it's not nearly as good as MS Office, especially the 2007 version. This is more of a problem than with other apps, since the fact is people were not typing out documents on Wordpad before switching to Linux. For example, most people have not bought Adobe Illustrator, and therefore an equivalent if less feature-full program being available for free on Linux (Inkscape) is a selling point. But most people have been using some version of MS Office before switching, and therefore the higher cost of that program is considered sunk. So having a less feature-full program available for free becomes a liability, not an asset.

Just looking at the screenshots for Symphony though, it's looking like the interface is improving, and more importantly, moving away from being a simple MS Office clone. Spreadsheets needs some attention: optimization, anyone? Or how's about reminding me about formula syntax as I write them? Also, presentations needs some serious love. The key here it a) make more templates and b) hire decent graphics designers so they're slick. Oh, and would it kill anyone to make a "handouts" layout that includes lines for notes?

More than Symphony, though, I'm looking forward to KDE 4 making an appearance on the Linux desktop. Eventually.

I tried out what they're calling "Release Candidate 1", though the system is clearly not ready for production use. Having said that, I see enormous potential for KDE 4. The widgets, the smooth animations that are scattered throughout the system, the icon theme -- all look very slick and very professional. Assuming some non-KDE technologies can be easily integrated into the system, or ported over for KDE equivalents, I think that the Linux desktop will begin to match or surpass the offerings from private companies, though we'll still lack in 3rd party apps.

The non-KDE technologies I'm thinking of here are PulseAudio, Avant Window Navigator and Compiz Fusion: the most exciting Gnome-based technologies out there. I know Kwin now does compositing, but I'd like the zoom, desktop cube and tab windows features from Compiz (some of the visual flash would be nice too, but not necessary) as I find those rather handy for windows management. As far as AWN goes, it's the best damn dock going. Period. With some KDE-specific plugins, I think it could feel right at home. Finally, I don't know much about PulseAudio, but being able to control sound on an app-by-app basis sounds very, very cool.

Saturday, November 3, 2007


It's that time of year again!

Yes, it's officially National Novel Writing Month, so naturally that means I'm already 2 days behind in my writing. Still, this year is my year: 50 000 words by November 30th or bust baby!

(And in true Geek fashion, I'm gonna craft the thing entirely in FOSS -- most likely KWord, since I'm a bit of a KDE fanboy. For awhile I was contemplating writing the thing in Vim using Dvorak, but then I realized even I have my limits.)