The real questions are should you ask, what should you ask, and how you should ask.
I totally agree with Jody, but here are some things I've picked up in regards to involving the client in project planning:
I almost lost a client because I was too technical and he thought that meant the final product would be too technical.
I went 2 months over a deadline with another client, and they told me daily that they trusted me and were confident that it would be worth the wait because I "understand what we're looking for." This confidence was because I asked for feedback on their business model and operations more often than the UI or data model. When I did have techy questions, I could frame them around relevant use-cases of their business.
One of the reasons the aforementioned project went so far past the deadline is because I let their business model and use-cases drive the project after the statement of work was signed and the project had started, leading to significant changes in scope. So definitely review your project plan before starting the project. They will want you to change things with delivered project no matter what, so wait until it's over for feedback.
A fellow engineer once told me "Don't ask them what it should do, tell them what it will do." It sounds very technocratic, but he told me this because I went into kickoff calls with 10 options that I thought were all valid and expected the client to choose one, while he went in and said "As I understand it, you need this, and here's what I have in mind," and then confirmed that it meet requirements.
Long story short: know your audience, read the room, and remember that they will have more confidence in the project if they feel you have listened and understand their needs, but ultimately they hired you for your expertise or else they would do it themselves.