Tuesday, January 10, 2006

Open Source Project Management Thoughts Continued.

I realized after my last post that I was getting way ahead of myself with the last post. Before you can ever hope to manage outside contributors to your project, you need to really manage your initial core of developers. That sets the tone for the entire project before you get a ton of outside developers.

Today you have a huge number of potential project management tools to use. There are a number of software packages (such as DotProject, Open Work Bench) and a number web based systems for project management such as Sourceforge. The first thing you do when selecting a web based or downloaded package is to ask your developers what tools they are comfortable using. Making this choices without discussing the issues with your developers is a surefire recipe for disaster. No one likes to be dictated to especially with the tools they will be using. You will need to build consensus on which tool you will be using, especially if there are disagreements.

1. Use a wiki. It's useful for capturing brainstorming sessions. It's especially important that your whiteboard sessions get captured and transferring them to a wiki is the ideal way to keep them alive as living documents and not just slowly fading writing on the wall. The other added benefit is of course that when you add additional developers in seperate geographic region, they will have a handle on the thinking in the initial design decisions. Of course if you are properly using your spec as living document instead of something that sits on a shelf somewhere, they will have this information.

2. Update the project plan and task allocation on a weekly or daily basis. It will help keep you on track, and help create developer momentum as they they see updates.

3. Check the velocity of the project on a monthly basis. Very often it's easy to simply miss the project targets without looking at how things are going.

4. Cut features out - don't add them. This is a much harder temptation to resist It's better to have a greater number of releases than more feature packed yet much slower releases.


I will probably revisit this topic in the future.

BSD