Imagine you don't have the problem of feature creep, you have a motivated and stable team, clear defined problems to solve, AND you know the domain/language/tools related to your project.
How do you stick to a schedule and accomplish that 1.0 milestone?
What is your approach to an iterative shipping?
I'd like recommendations specially for a small team, where there are few or almost none communication problems.
That's probably an Utopian scenario ;-). But anyways, if there is no feature creep, very good team and clearly defined requirements with absolutely no communication problems then probably the best way to deliver the product on time would be
End of the day, it boils down to how passionate a person is towards their work.
Just my 2 paise's ;-)
Question: How does a large software project get to be one year late? Answer: One day at a time!
That doesn't provide an answer to your question, but I think it does point to the need to stick to your schedule -- if you even get one day behind, you need to catch it up somehow. (Unfortunately, the rest of The Mythical Man Month is all about how in most projects there is no "somehow"...)
Also, have a look at the Evidence Based Scheduling in products such as FogBugz. This will give you an up-to-date estimate of when the product is likely to ship -- in fact, it gives a range of dates, with probabilities for each date. If you see your likely release date slipping past the deadline, this will let you know that you need to do something about it -- and hopefully with enough time to have an effect.
There is one small point missed by previous posters. To meet the deadline first of all realistic schedule should defined. The project should be split down to small task it's depend on the project size, but in my world with projects taking about 3-4 months, we trying to split them into maximum 2-3 days task. This way the time estimation are mostly realistic and risks are calculated in advance and added to the proposed schedule.
There's a lot of good advice in this thread. The only thing that I have to add is to adopt a regular timetable for releases. My company switched to this a few years back and it was painful at first, but it does have a lot of benefits, the biggest of which is to allow people to easily defer features.
It becomes okay to defer features because you know that your feature can make it into the next release and you know when that release will be. This means that rather than rushing to get your half-baked feature in at the last minute, you can spend a little longer and have it in at the beginning of the next release.
Barring unreasonable timelines from sales/marketing/management, you've pretty much ruled out all the reasons that a projects don't ship on time. The history of software development methodologies is a collection of methods to work around, reduce the impact of and/or avoid:
Stage periodic (monthly? weekly?) product walkthroughs using the current accepted build, for the benefit of the Product Team. Begin these as early as possible. Demo every feature, regardless of their current usability; don't skip over the ones which are lagging behind.
The point is to give the stakeholders a clear idea of the current state of the product over the course of the project. This way decisionmakers are more likely to tackle schedule risks promptly, rather than jeopardize the ship date.
Know what the mission-critical features are for the client. Protect the progress on them. It is often very true that 80% of the success comes from 20% of the work.