When we plan a major site, we start with an extensive discussion of the mission of the site. Talking all day about the how won't get you anywhere if you don't have the what right.
In other words, business requirements documentation should always precede technical requirements documentation.
After we write up a top-level description of the business requirements, we require that the client review and either approve or modify it.
Everything else that we do refers back to that business requirements document. Design, color, content and functionality decisions all are driven by that set of requirements, and not by personal preferences (I like green, you like red), et cetera.
The business requirements session usually is followed by a session of whiteboard brainstorming involving several members of the implementation team.
Choices of technologies actually are way down the road in the process.
(It always amazes me to see a posting on a mailing list to the effect of "we want to develop our site using enterprise foo-foo beans and winkydink servlets running on umptysoft database" when there's been no focus on the mission of the site. Inevitably that leads to bad decisions and failure.)
