In terms of documenting your system design this should all be done prior to the start of system build if you are working by the book. My preferred method is SSADM.
I'm not aware of any websites giving advice on working as a team of developers (although I'm sure they exist) however I have worked in small teams of developers on a few occasions in the past and have learnt the following through trial and error (a *lot* of error!):
Excellent communication is vital. The project will suffer significantly if your team contains even one developer who is prone to go off and do their own thing without regard to others. The best way of communicating is, in my experience, verbally with written records to cover you in case of unforseen absences.
Version control *everything*. Be *extremely* strict about this. Visual Sourcesafe works with MS Access (although not as effectively as with VB, C, etc). It may be worth considering the use of an application like this.
Have a nominated lead developer. This developer is responsible for releasing code for development and updating the master copy of the system.
Use classes and OO programming techniques as much as possible, without harming the design of the system. Agree the objects/classes and their interfaces in advance. Assign a single developer to develop each class. Do not deviate from the agreed interface design unless agreed with all other developers so that they can assess the impacts on their code. The one drawback to this is that SSADM doesn't really fit with OO design and development.
All code should be peer-reviewed before being updated into the master copy of the system. This ensures quality and a broader understanding of the system. You should never be in a situation where only one developer understands part of a system.
Code comments!
Good luck with your project. Working as part of a team of developers is very different from working on your own. You'll learn a lot, although it will be frustrating at times.
Ed Metcalfe.
Please do not feed the trolls.....
