Clients generally don’t like to pay for paper documentation that they feel will be useless once the site is online and the code written, but overall having everything spelled out BEFORE any coding is done ensures that hours aren’t wasted doing something other than what is needed or desired, and it’s WAY cheaper and faster to change the text of a few paragraphs to describe how a content management system works than it is to build the thing and then change it after the fact.

In general, communication keeps all parties from being surprised about the outcome of the project. So it’s really really easy for me to walk away from a project where the client throws up his hands and says “Don’t bore me with the details, just build me a web site.” because unless you have a contract that states that whatever I give them is acceptable (and these same people won’t sign off on something like that) there are going to be problems later when you deliver and they say “Oh. I didn’t want it to be like that.”

These same 10 items fit pretty well to any sort of contracted personal service. I’ve had analogous experiences when I was practicing law to most of the things mentioned. It amazing that the people who pay you the least expect the most. However, I think you do a good job in how you handle things with a written proposal and contract. Anything that helps clarify expectations on both sides is useful. Unfortunately despite everything you do, sometimes clients are determined to misunderstand, misinterpret or overexpect.

I think that some of those “warning signs” are going to be there with ANY client. It’s just a matter of how many can or will pile up before you have to just walk away.

Anyway, I try to mitigate the possibility of a project being “bad” from the get-go by specifying what will be done, for how much (roughly), and in what timeframe. That way things can’t spiral out of control (too much). It’s a bit of give and take.