During the Concept and Planning phase, work closely with the client to determine site requirements, business goals, and the types of new functionality needed. In order to develop a feature set that will make the client happy, clarify the client's desired audience, visual design style, message, tone of content, technical requirements, server software and hardware, system architecture, and security and administration needs. Concept and Planning is also a time to review the current site, document what you think works and what doesn't, then craft your recommendations accordingly.
Problem: The Puppet Client
You need a single sign-off person, someone who "owns" the project. Without such a point person, you're in for a whole host of troubles associated with mob-mentality decision making and dicey company politics.
Solution
In every kickoff meeting, I make it a point to establish a single client as the sign-off person. I try to divine the identity of the key decision maker and the person who has final say by simply asking, "Who is the final decision maker?" In my experience, the person who is quick to answer "Me!" should be taken with a grain of salt until you find out whether "me" has a boss, a partner, or is delusional. Often I double-check by asking, "Is there anyone else who needs to sign off and review? Can we count on you to be the mouthpiece for your entire team? Is there a VP in, say, Detroit who might want last-minute approval?" If you've ever had three different clients leaving conflicting messages on your voicemail (and on the voicemail of the designer and engineer), the value of this exercise should be crystal clear.
Once you get the feeling that multiple people have a stake in final decisions, it's important to pad your schedule accordingly. Add time to the review periods (which may mean a reduction of the feature set) and establish clear time, cash, or functionality penalties for any decision-making delays that push back your deliverables. So if someone's boss, whom you've never met before, up and decides he wants to be part of the process, make sure everyone knows the cost of such 11th-hour changes.
Problem: Client Team Change
Sometimes projects change client teams midstream. In the case of a redesign, often the client team had no part in the initial, phase-one design, so they're unaware of the reasons behind existing design decisions. Often new teams feel compelled to leave their own mark on the site, even if it means the wasteful sacrifice of the work that's gone before.
On the other hand, an old client team may be resistant to change. Maybe their technical lead took on this Web project two years ago, back when no one cared. But it's no longer his pet project. "Corporate" is involved, and higher-ups are forcing him to make changes he isn't ready for (or able to do on his own). Possibly he and his team are wedded to the existing process in some way.
Solution
You need to figure out how to respect and incorporate the input of individuals on the client team. This may mean planning work sessions that include the team or tech lead. Or make sure that the sign-off person on the client side runs final decisions by the guy who has lovingly owned the site for the past two years so he can contribute - and doesn't try to sabotage your efforts.
Problem: Memory Loss
When the client team is shuffled mid-redesign, people sometimes lose track of what has been said. The same client you talked extensively with about the limitations of the cheap search engine he purchased claims he has no recollection of that discussion a month later. And suddenly it's your fault that he can't have the super hot-rod search capabilities he saw elsewhere.
Solution
You can't really plan for this, but you can prepare yourself by documenting every decision and discussion. Save your emails and keep notes after every discussion, and send them around to all involved parties. You may never need them, but at least they're there to give you confidence when you have to "remind" someone about their previous decisions.