Also as a developer, I would apply some programming principles to project management. for example design-by-contract where you create interfaces that define interaction with a group of classes, etc. So you divide groups/people by function, ie UI, back-end, integration, etc. then each group would define what they need from the other groups and what they would be able to produce. you can then develop some process based on those requirements. I think the person doing integration with have the most input into this. he/she has to deal with static pages and at the same time with server side code. so its really an interface himself
Another thing I don't like about large groups is QA. I would not have them at all. perhaps one person that would give demo of the on going project to the clients. if he can give the demo without running to problem and the clients are happy with what they see then you have a QA.
one other note, create a sub group of a select few that really understand and have a good vision of the results. they should meet and review/audit everything and catch design errors before it becomes too late.
and finally don't manage things employees in a company. think in terms of a research project in a univercity. with lead developers as staff and everyone else as students. you can use you imagination as to how this would effect every aspect of your project.
PS: I've also worked on ATG in the past but now I'm working on tomcat and other open source.