A systematic challenge to software development is feature creep or what we like to call "creature feep". Creeper featch is a threat to the conclusion of any project. The basic idea is simple: once you have a working product there is an irresistable urge to add new features and other wing-dings to it. This tendency is natural but if it gets in the way of release times it can delay the production schedule and be a distraction to the overall purpose of the development which is to get the product to the users.
One solution is to write up a set of desired features up front and prioritize them. You should have a set of features which are indispensable to the product and another set of desired features that are secondary. Now the problem with this is that as development progresses it may turn out that some features are much more difficult to develop than was originally anticipated. Conversely other features that might be really cool and are easy to write may be discovered along the way. As you work there are features that are very easy to add and there are other features that you want to add later because you just didn't think of them and it was not until the program actually exists that it becomes clear something extra is really needed. So new features tend to get added on in a number of different ways.
The protection you can provide to avoid feature creep is to disassociate the state of the product with the release times. Once you have a fundamentally sound product it is a mistake to base your release schedule on the functionality of the product. In other words to say, "Well, we're not going to release it until we have feature X or feature Y." It's much better to have a policy that releases come out say every six months. If a feature is not there by that time then fine it will be in the next release. If you separate your business schedule from your design schedule you will not have a problem with the feeping creature.
