=== Schedule versus Features versus Quality   Now for a few words on project management.   Sooner or later, almost any project faces a trade-off between schedule, features, and quality.  Consider a student writing a term paper on the last night.  He has three unpalatable choices: he can turn it in late (miss the schedule).  He can turn in a shorter paper that doesn’t cover everything (reduce the features).  Or he can churn out gibberish (lower the quality).   Similarly in a software project, one often has a choice between making the release date, or dropping features, or shipping everything on time and hoping that it works (it usually doesn’t).   The most important thing to realize about this decision is that it IS a decision.  One can’t get out of it by hoping that some miracle will occur. If you don’t react consciously, then external circumstances will drive the decision.   Ok, so suppose you are faced with the trade-off and go for a schedule slip. Don’t take a small slip … take a big impressive slip.  If you say ‘I’ll just fix this one problem and finish ASAP’, then likely you will wish you had taken just a little more time later.  If you say ‘I think I need another day, so I’ll slip by a week’, then it’s much more likely that what you’ll have at the end of the week will do the job.  It’s better to slip a large block of time once then to slip day-by-day or hour-by-hour repeatedly.   If you go for dropping features, again, carve off a big hunk.  Don’t be timid and pretend that you’re going to do that work ‘if you just get a little spare time.’  That feature of your project is GONE, exploit the lessened requirements for all the savings you can!   I can’t offer much advise on how to reduce quality, because that’s always my last choice for what to drop on a project.