|Perl Monk, Perl Meditation|
There is so much good advice already mentioned...
I can only add my 2 credits worth:
1. Where do I want to end up?
Projects tend to change, sometimes radically, from their initial scope. Nothing new in that thought.
So, I began planning in the unplanned request, the midnight revelation, or the damn business plan changes. My own projects experience the same things. I'll start out in one direction, usually get to the releasable functionality step, only to find new features, functionalities, or even different uses from what I started out to get.
Forever, those seemingly inevitable changes seemed like Evil. Eventually, when I began working with these flexibilities in the initial planning stages, and throughout the actual coding/testing/release stages, things smoothed out remarkably.
However, it is sometimes a tense moment to explain 'releasable functionality' to those that think they know or designed a foolproof plan and scope. And none of this precludes definable milestones, deliverables schedules, signing off on scope, changes, turnovers, etc. But, realizing that "it's going to change" and working to define and quickly arrive at useful milestoned deliverables has saved me/us from many antacid-filled nights.
Sometimes, releasable functionality represents a business plan change as well as a coding release schedule. So, if it's not really my place to make such a suggestion, or if the project has iron-clad scope (rare?), then I forget about that thinking (which hurts, since I tend to think it's a valuable approach, even if the first releasable isn't actually rolled out).
(My favorite post-planning question has turned out to be: Ok, so we've done all this planning, accounted for every possible problem, completed and rolled out the product, and it still fails. What are the top 3 reasons why it will have failed?)