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>

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.