Never trust someone who speaks in terms of "requirements", "implementation", "functionality" and "engineering" to know his ass from a hole in the wall when it comes to understanding what's fun and what's boring.

For me, I just like to block out time for Prototype, Implement, Polish. The main difference in these time frames is the attitude about what you're doing / resistance to design changes. Whatever we get done in that time is what we get done. It generally results in priorities changing on the fly in a very organic sort of way as certain things become more or less important to the resulting game based on the current circumstances (for example, crash fixes, fixing bad game mechanics, just lost publisher funding and need to find another, etc).

For example, you could have a major feature change in the polish phase that would result in certain things not getting as much polish. However, that was an acceptable consequence when the feature change was decided on.

Planning up front is helpful for making best guess estimates, but it's always ballpark. Trying to lock that schedule down is pointless and ridiculous. I favor a potentially constantly changing list of priorities with an understanding of the costs of change.