I can't count the number of times that I've seen systems that had to be reworked later in the development process because they didn't meet the needs of the project or just plain failed to function. When somethings blows up like this it's usually a result of a lack of planning on the front end of the process. This is why I always like to keep a mental eye on the end result, the actual game sitting in a box somewhere when planning something. It's often useful to have a set of metrics that you use to decide if you've sufficiently thought through a particular problem. One of the most important of these, although not the only one, is whether or not the feature is "Plausibly Shippable". You can ask this question at each stage of the process.For example during the design stage you can use it to make sure the design itself is complete enough. During the implementation phase you can use this metric to determine when a given piece of code is at the minimum level of functionality. Keep in mind that this is about the absolute basics of the feature. Does it mean the performance requirements? Does it fit the control scheme? Do we have resources like art that need to be created? Plausibly shippable won't get you a great game, but it will make sure that things don't fall through the cracks. I've found that all too often people get past themselves and don't really think through the implications of what they are doing with respect to the final game. If you can't explain to me how to get what you are working on into the actual final shipping game that's an indication that you need to nuke it from orbit (it's the only way to be sure).