There is so much good advice already mentioned...

I can only add my 2 credits worth:

1. Where do I want to end up?

• What does the UI do? In as much detail as I can imagine.
• What management interfaces are needed and their functionality? Including reporting interfaces.
• What is the overall description of functionality (in Reader's Digest English)

2. I believe that this works in gradients of completeness.

• Get some initial results. Core functionality. This is good for my morale, as well as that of the other stakeholders.
• Expand the core functionality towards 'releasable functionality', which may not include all the planned functionality.

This will be a debatable point, but since I tend to think that a good project/product is almost never truly "done", then targeting a release of useful functionality works for many (but certainly not all) projects. We're able to show a product, maybe sell it; involve users, support staff, and others in continuing development as the additional functionality continues to come online, etc.

-----

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?)

</MHO>