What I used to tell my clients was: 60% to 70% of my time will be spent preparing and/or planning. This is probably most analogous to the Pareto principle of 80% of the value coming from 20% of input. It's what you do during that planning that makes the difference.
If you are "just sitting around" thinking about it, and plotting a course, there's probably not much being gained. Instead, try to view planning almost as if you were a mad-scientist in a lab.
For example, let's say we are building a website or app (you mentioned coding, which is why I went there). Start thinking of ways to layout the user interface - I use rapid paper prototypes - I sketch them out on index cards, using a medium to broad tip marker. Play with it as if it were real. Keep incrementally upping the sophistication - moving to using your favorite graphics applications to layout wireframes - keep playing with it - reformatting as you go. As you start to build a more concrete concept you can begin to see how the code will have to work to give you the results you want.
Break things down into small components - maybe you have a designed something with a lot of progress bars, for example - write something to create progress bars. When you write it the first time it will not be the best/most elegant solution - accept this. In Test Driven Development terms I've seen this referred to as Red, Green, Refactor. There is a problem with no solution. There is a solution. Refactor the solution to make it better (more readable, simpler, etc.). Then you can move on to the next bit. Eventually, all these tiny pieces will come together to form a complete whole that is/should be relatively elegant, because you spent the time "experimenting" with the implementation - not just sitting around thinking about it.
In conclusion, if you can use the fastest and most low-tech methodology to begin testing your hypotheses regarding various pieces of the project, you can quickly gain a more complete understanding of the desired outcome. Basically, allow yourself to go down the wrong paths a little bit and try to put things in place to minimize the possible negative affects of sweeping changes at the end (automated unit tests, for example).
Hope that helps. If you would like clarification on anything, let me know.