I'm rather shocked at how rarely I see one phase of software development that I was taught: Needs analysis. If I'm working on an important project, I don't just take a spec that is handed to me; I study the needs of the client / customer and analyse them. The needs often start out as a spec. But, in my experience, if the client is savvy enough to get the spec right, then they don't usually go contracting the work out.

Most of the mistakes I've made in contracts is when I've let the client dictate what was to be done without analysing whether that really made sense and pushing back quite hard with what my analysis says should be done. If the client disagrees, then I need to work to find out whether I'm missing part of the picture or the client is.

There can be differences of opinion as to how to do something, and often the client gets to dictate those since they are paying (but sometimes I get to dictate them since I'm the expert being hired and so should know what I'm doing). But if there is a disconnect as to what is needed, then the project is going to go quite badly.

And the most common way I've seen for the needs analysis to be done wrong (other than "not at all") is for the person doing the design to not talk to the ultimate consumers of the proposed work. Talking to the boss who is going to pay you is just the first step. You need to talk to the peons doing the work and see how they really do things and discuss how they'd use what you are considering writing.

So, yes, I usually know what the client needs better than any one of them does once I've taken on a project. I may not know what they want better than they do, but I don't care as much about that so long as the paperwork is clear -- since I've experienced giving them what they want but didn't need and found that to be much worse for all involved than giving them what they need but didn't think they wanted that was also what was spelled out in the contract (which prevents them from easily dismissing the work which gives them time to realize that they did need it -- usually soon after they give it to their peons).

Of course, I make an effort to understand what they want and to explain what they'll be getting. Proper expectations make things go so much more smoothly. But wants are harder to pin down than needs and specifications, so I try harder to make sure the latter line up. You can do a lot to verify needs and specifications but for "wants" you are stuck with how well they can communicate what is in their head.

If I ever ask a client "Is this what you meant?" that's a red flag that I'm nearly driving blind.