There are many ways to tackle this program, but whatever you do, don't begin without having a clear idea of where you are going. In your response to my comment, you say that
we have started doing all the requirements and documentation including various diagrams. I know what the program should do but I am not sure how to separate that into classes, methods, etc.
I would not worry too much about that. What you need to do as a first step is be really certain of the "flow" of your site. Think in terms of usability first, then sketch the background processes as if you were engineering a machine. Don't let classes and coding practices stop you at that stage.
When that part is over, you should be able, with the help of a few papers, to explain to coders and novices alike how it all works, both from the front-end and the algorithmic point of view. If you can't, then it's not clear enough. Get back to it.
When that part is done, 50% of the code design is done. From there on, there are many ways to go. For example, you could list all the functionalities (features) needed, all the data storages (database, filesystem, xml...), and all the front-end modules, and see what links with what the more naturally possible. From there, see what are the common features, and create mother classes and see what functions have to be added in subclasses. Pay special attention to what data enters a function and what data leaves it, and make sure related functions work well together.
I am personally a fan of getting real by 37 signals (it is an absolute must-read if you don't know it). What they do is design the interface first and then go from there. It helps to concentrate on what really matters, and check at each step that the flow is good.
My personal variation on that technique is: I write my end-code first. This helps me understand what I would want my classes to do. If my code gets too complex, then I change it on the fly (it doesn't do anything anyway, I haven't created a single class yet), and begin implementing features.
This is somewhat akin to test-driven development, albeit simpler to kick-start, because it needs 0 preparation.
And lastly, although good coding practices are a must, and I totally agree that they should be used at all costs, but don't make the beginner's mistake of being hindered by them. What matters is that the code works, above all. So keep in mind all the good stuff you learned, but don't stress too much and just dive in. Iterative design is the best pattern (at least for small groups). Build something that works, and optimize later (try to keep a minimal level of cleanliness though or you won't be able to optimize at all).
Hope it helps.
I forgot to mention: if you aren't already, using a subversion system can save a lot of headaches on the long run. Bitbucket offers private repositories, and it's fairly easy to set up mercurial on linux & windows (I don't know about apple, but I suppose it's just as easy).