Someone on GameDev.net asked for input about project management, so I decided to write this brief overview on it. I could definitely go more into depth, should people want me to. Here it is:

Well, the answer of your question really depends on the scope of your project, its demographics, and how serious/committed you are to it. For the sake of this response, however, I will assume that you are very serious and dedicated about the project in question and that, like many other projects, you plan to utilize people from all over the world to act professionally to create a top-notch game/product .

I've commented on this subject in particular a number of times, but rather than quote myself, I'll just write this from the top of my head, for selfish reasons (I'd like to see how my opinions/methods have changed over the last 3+ years of managing a large project, so I'll compare my current response to my past responses myself ... No need to drag you into it ).

There are really a number of things you are looking at here, so lets break them down.

• Public website - Used to post news, blogs, screenshots, and anything about your game to the public.
• Private website - Used to discuss development in an area that can be viewed across time zones
• Development Wiki - A repository for design, documentation, guidelines, etc for your project staff. Possibly public depending on your goals.
• Source Control - A repository for code and its revisions.
• Task Management - Depending again on your level of professionalism, you will want to keep track of assignments, progress, etc.
• Bug tracking - Depending on the size of your project, and assuming you have a team larger than one or two, and they work in different time zones.
• File Repository - A place for the non-code assets, other project-related files, and media.
• COMMUNICATION - A place to discuss the project in realtime (or as close to real-time as possible).

Now, let's go over these things and why they are needed.

A public website will create a "face" for the game. This will serve more purposes than just to create hype and display news. This is also what prospective team members will be seeing. In my opinion, slacking here has the potential to kill your project, no matter what is under the hood. Possiblities: Make your own, pay for one, or use a Content Management System (CMS) (check out www.opensourcecms.com), or a hybrid (forum/cms solution via an addon to Invision Powerboard or vBulletin, or even free ones like phpBB, SMF, etc).

A private website will be a good tool to help manage teams who span the globe, across various time-zones. Realtime communication does no good when some of your team is asleep when you are awake. This can also serve as a great place to conduct interviews with little effort, across the same time zone issues. Possibilities: Same as above.

A development wiki is going to be crucial if you plan to actually document. Documentation, from code to a design document, should be incredibly important to any serious project. This can also be used as a repository for works-in-progress, and often changing work. This is usually limited to text, but there are some exceptions. For example, I use Freemind to outline some of my designs, and I can embed the accompanying .mm files into my wiki and view them from there using a flash or java applet. This also keeps historical versions of things, so its VERY nice for history-keeping purposes. Possibilities: DokuWiki, MediaWiki, DekiWiki, Trac and MANY more.

Source Control should definitely be used if you have more than 1 programmer. SVN is not your only alternative. There is CVS and others to choose from. The important thing to remember here is that if you rent a web server, make sure you get one that supports your version control. Possibilities: SVN, Trac with SVN, CVS, Perforce, Sourceforge, more.

Task Management is important unless you have one person (or more) who wants to spend all his/her time trying to give assignments, keep track of them, motivate, etc. This type of tool is definitely better suited to a programmer-heavy team, and creative team members will not be that enthusiastic about it. Possibilities: AgileTrack, Trac, Trackit, XPWeb, many more.

Bug tracking is important when you get many people working on the same code. If each developer is working on his own thing, this might not become important until much later in the project. Possibilities: Bugzilla, Trac, and many others.

A File repository will become important as you gather assets that aren't really part of the code or documentation. This is most likely going to be your art and sound assets. Some people use their Source Control for this, but that starts to get big real fast. If your Source Control has a size limit, you will want to use a place that has cheaper space. There are all-in-one repository tools, but most are expensive. Possibilites: Perforce (free if you are GPL), FTP server, SVN, CVS, wiki

Communication is going to be absolutely crucial unless you go to school with the people you are working with. Since most projects aren't lucky enough to find enough local people, there needs to be a way to keep better tabs on people. It helps if you can become friends, and that is hard to do on a forum. IRC is your simplest bet, but MSN Messenger can also work. Some people also will go to voice chat, via Ventrilo or Teamspeak, but this is really only icing on the cake. What is important is that there is a place you can all "hang out" while you work. It will act as a virtual office space as you chat and share things in realtime. Forums and email also work for this, although can be very slow and are definitely not the prefered way of keeping up. Possibilities: IRC (host your own, or use a free server like Freenode), any IM client (MSN, Yahoo, ICQ, GTalk, etc), voice chat (Ventrilo, Teamspeak, Skype)

The majority of the items here can be handled with two things, a good forum/CMS and Trac. A CMS will take care of all your news, and good ones also have blogs, galleries, and forums. You can try them out for free on the site I listed above. The downside is the customization that needs to go into them to make them look good. If you have, or can recruit, a good web developer, then skinning them is fairly simple, depending on the one you choose. In my experience, the commercial ones (like vBulletin and IPB) are MUCH harder to skin than free ones.

That brings us to Trac. Trac is an integrated wiki, ticket/bug system, and SVN system. It can become very powerful, should you decide to go with it. That being said, if you choose to go with Trac, you will already be ready for the future needs of your project as you grow. The downside is that it is harder to learn than some of the other wiki systems for the non-programmers. The easiest wiki that I have seen is DekiWiki for non-technical users. The most popular is MediaWiki. I personally have used all 3. They each fill different (yet overlapping) needs.

The last thing I will mention is communication. As you can see, I bolded it above. I believe this is going to be one of the most crucial things to a large project spread all over. Realtime communication is a great motivator as well. As some of your team work on things, and share them in real time, it helps others to be motivated and see the growth of the project. As they see progress, they will be more likely to want to pitch in more time. For my project, if we had not setup IRC long ago, we probably wouldn't still be around. IRC has been the lifeblood of PW and has served many purposes. We hold meetings in there, hang out, do some interviewing, answer questions, and many other things.

I could go on and on, but hopefully that gives you a good overview of what is needed to make a truly great project that will stand the test of time. Feel free to ask me to clarify anything.