Addendum
6. When you make architectural decisions (creating some function in code instead of sql for example) go ahead and explain your reasoning to the client in some form or fashion. Volunteer this casually at a meeting. It creates a good bond between the two of you, and the client will probably reciprocate by telling you about some more "businessy" trade off or decision they've made. It also allows the two of you to communicate better in the future, and you will both know each other's implicit priorities better. Do this sparingly, but definitely do it. At worst the client will be bored, but at best it's a good force multiplier.
1. I would read "The Secrets of Consulting" by Gerald Weinberg
The biggest lesson (I think it was in that book) was that you're being hired as an expert on a topic. to be a Successful expert you must A) have an expert level of knowledge about the topic and B) LOOK LIKE you have an expert level of knowledge about the topic. Those are two separate, but essential things.
2. Go for 70-30 split of listening to talking.
3. Read Million Dollar Consulting by Alan Weiss
4. Make sure to read a lot in the early days, but don't expect to get more than two or three insights from any particular book (for example the insight in the Weiss book that has proven most useful was "Clients that are difficult in good times will be nightmares in bad times". That has been true in each and every case in 17 years in business)
5. By the time you're in front of someone (physically) your primary job is not to sell them on anything, but to de-risk your offering to them.
We identify bad clients and projects by automatically analyzing time so you can do your best work for your best clients.