I always get a kick out of reading Raymond Chen's blog, The Old New Thing. So many of his posts hit home way too often :). One of his latest posts simply highlights one thing I always try to do and get folks to do when they ask for support or help with such-and-such. I've caught myself doing this same thing many times. Don't ask how to implement your grandiose solution, simple present the problem you're trying to solve and then present your proposed solution.
Why present the problem? You've already thought about it (I presume) up one side and down the other. I should not have to bother this person with my problems; they're mine to solve, dag-nabit! First of all, why are you even asking for help? If you're suppose to be "God's gift to programming," why are you seeking advice? Your not? You're a fallible, imperfect human? Me, too! Good, now that we're all on the same level here, back to why should you present the problem? When you present and frame the question in terms of the problem you're attempting to solve, you have the highest chance of getting the information you want. In fact, in cases too numerous to count, I've gotten better solutions to my original problem than my own "awe-inspiring" solution.
I see this same thing all too often in the peer-support forums and newsgroups. A person will pop in and asking for help with how to implement their solution, only to be disappointed by the responses due to a lack of common information. Too much inference is going on. The same is also true of QualityCentral reports. Rather than simply stating that such-and-such is broken, a detailed explanation along with detailed steps go a long way to getting your point across. My parents always used to tell me, "To be terrific, you must be specific."