Monday, September 8, 2008

How to work on a Project

This comes from a conversation I was having with my friend Chris the other day
about how you can keep yourself and friends working on a project.

So this is what worked for me... Something that has allowed my project to not die after a day of working on it -- what usually happens to projects that i start.

First and foremost: Get everyone to set aside a specific time each week to work on the project. Ideally it would be everyone at the same time at the same place, but thats not likely to be possible. At the very least you should have pairs of people.  Most of my friends are already highly motivated but having someone to bounce ideas off of is invaluable. If you have to wait until the next time someone is online that idea will probably bounce away instead of back. There are other reasons for this that I will come to shortly.

Because you're working on a personal project, the only initial rewards are going to be the feeling of satisfaction of having produced a good idea or from helping another person on your team.

Make sure everyone shares their ideas, and document those ideas. You'll need some reference material later when you thing "Well, why didn't we do this in the first place?" This is the second reason for having pairs or groups of people working at the same time. At the end of each session you can suggest people show their work with an example or through some documentation. This not only keeps people concentrating on goals but it establishes that each person on the team is working for someone else -- the most important part of this plan is to make sure people are vested in the work everyone is doing. It is vital that each member of the team takes as much or more pride in the work each of their teammates than their own.

Next, spend some time planning what the team is going to focus on. Even if you don't have a clear idea of what the project will be, give people focus area to lead. Have someone investigate javascript frameworks while you have someone else analyze some patterns for the client-server interaction. Or have someone start writing up use cases for how they expect the project to be used. If you immediately jump into writing code you might leave your teammates who have less a clear idea of waht to do in the lurch. Know that each person has some series of talents that nobody else does so be sure to spend the time upfront to realize what those are.

Do not expect the same quantity of work from each person, but do expect each person to make progress, even if that progress is a discussion about how they had to re-write some system for a third time. If someone is not completing any work you can expect that attitude to be more influential than that of the other people completing some tasks. Even if someone's time is spent researching, a short summary to another teammate or in a document will help spread some knowledge and capture some progress.

As the project moves along, the tasks people will be doing will tend to be more tightly coupled with the work from different people. By this point your team is probably working well together and because you've already encouraged people to help each other being a dependency or or dependent on someone else is not a new feeling.

Finally and most importantly, make sure everyone is having fun. The best way to kill a personal project it to treat your teammates poorly. The second best way is to make the work people are doing boring so be sure that people find something they enjoy to work on.