It's not necessary to have small groups to have cohesion. Similar ideals and beliefs tend to be enough. If that were not true, political parties would not exist, and neither would grassroots campaigns.

Aspergers syndrome for one. There are many ways to explain the odd clicks and petty drama that seems to surround this community.

Project management is a big one. First off, most people who use organizing software at all use their own project organizing software. I have seen the one at RPGone when I had access at one time. I can tell you it wasn't much and there was more to come for a long time. However, then the founder died and with him the page for a long time. So most people just seem to not use organizing software at all. Also, there are really not many good ones around.

Secondly, usually people will work on binary files. While this is easy to oversee for a project with two or three guys, it can become quite challenging when one has multiple people working on the same file, then having to sort out differences, keep everybody up-to-date and also traditionally having to keep patching stuff till it works in a patch order from hell. I've been there, done that. Nothing too big came of it. However, parts of this could have been handled more wisely if everybody would actually inform themselves.

This is where the third points comes in: People. As silly as it sounds, but even high-cost big-money firm projects fall apart because of the people involved. Be it distance, language, mentality ― everything can hinder a project to be carried out successfully and in the set time frame. Usually, first and foremost, one has different opinion that draw the project towards many directions. Somebody as to settle differences and somebody has to make sure everybody gets the big picture.
Usually, there will be people present who expect everything to be explained to them, every piece of info to be handed to them. These are the people I am most displeased with, because I myself don't work that way and despise that way of thinking. But one has to manage. As I just said, obviously there are the hard-working kind that manage to read some lines of code and inform themselves, find and actually read documentation (!). Generally this kind of person will not be a good team-player and rather do things alone.
Then there are obviously the unskilled. They pretty much hinder everybody, sometimes fall into the first category (unable and unwilling; ought to be removed) and one has to find proper work for them to do ― work that is expendable, doesn't require set dates and in general is very low-profile low-tech low-knowledge low-low stuff: drawing pictures, writing documentation, taking screen shots, having cutesy ideas, that sort of thing.

Fourthly, one will often face consequences from poor yet rationally at that time taken decisions and planning. One will find that minuscule errors in planning can have severe consequences later on. Even more so, if one's client isn't quite sure what he wants in the first place. So one has to find a settlement of interests. One will design a basic framework, only to have it distorted and twisted by diverse requirements from within the team and outside of it. Usually, this ends up with the tech-guys creating possibilities the clients didn't even think of, whilst dismissing basic claims made from the client side that they think would be most-easy to accomplish.
One might not think that way, but this is especially true when one is one-self's client. One will often find oneself in a situation where one will bend one-self's own expectation to meet the technically easier, implement it, find it warped from the general idea that was there first, yet acceptable. So one can redo the work, or decide that it is almost befitting the idea and move on. This only gets worse when there are more people with differing visions on the team that all want to implement them.

So you see, it is pretty much a melting pot of ideas that have to be combined. Some people need to be motivated, some people need to be restrained. Some people will take on extra work while the other will delegate as much work as possible. Then there is the need of having a good base to work with. One starts with no knowledge, no platform to organize and then usually disbands and fails.

We had a production environment to organize stuff for our latest project at uni. Enough to say that some features were barely used, while many were misused. Commenting where nobody would be automatically informed of comments. Discussions inside of issues where nobody could track the outcome. Decisions based on email outside of the system because some people don't recognize the possibilities and reject a central discussion platform and try to cut deals with people in the know. And the worst part about it: Even knowing this, people will do their fair share in furthering this bad decision-making and bad style of dealing with a project ― just to move along and get it over with.

cYa,

Tauwasser

EDIT: I added the underlined content for DarknessSavior's benefit. It was around 4 am, so sue me ;P.

The project management aspect does fall under goal 1 (documentation of such) and goal 4 (utilities to reduce difficulty of problems).  In fact, the guide I was working on was planned to cover this.  But to be honest, I've never used project management -software- (like MS Project) myself.  So I wouldn't know how to couple software with this problem.

Another problem that is difficult is working on the same binary file simultaneously.  A CVS repository works well for PSX games with lots of subfiles, but not so great with a single file SNES game.  The people-based solution would be to use a management strategy to split the game into tasks that can be done simultaneously (ie. a programmer could design utilities while the main hacker gathers info / performs asm hacks).  The utility-based solution to this would probably be to use/create patchchains.

A patchchain would be a file (could be a .bat file) that looks like this:
First: Expand the ROM, if necessary.
Second: Do all data moves.  (moving pointer tables, text banks, etc)
Third: Apply graphic edit patches.  Each graphic edit would be a patch. (like a font patch and various gfx trans patches)
Fourth: Run assembler to apply each assembly hack.
Fifth: Run script inserter to insert script and adjust pointers.

The above is just an example, but does anybody have a process that automates a project build from scratch?

Merging raw binaries has always been hell due to offsets and other odd problems. This won't change without either merge utilities smart enough to understand the file layout [good luck] or finding a way to breaking it down with a good disassembly or the like [good luck, again].

Modern patching/merging require the file structure to allow for data to just change or for the diff to be human-readable to some extent. Machine code in particular allows none of this. This is more a rant more about current RCS systems sucking at binary files than anything specific to Romhacking.