Research suggests that
- 40% of all software errors are caused by pressure on developers to complete quicker (Glass 2004)
- Under extreme schedule pressure, code defects increase by 400% (Jones 2004)
- Projects which aim to have the lowest number of defects also have the shortest schedules (Jones 2000)
This makes sense is you consider that good engineering practises are the first to leave the building under pressure to finish, and most teams will revert to quick & dirty hacks to get things implemented, without complete testing etc.
My personal opinion is that the only way to shorted development cycles is to reduce the feature set. Its pleasing for me to see that the research seems to back this up.
When deciding which features will be dropped; I think its worth revisiting the business requirements that are driving a particular set of features. In many cases a simpler “design” could suffice; for example a fancy calendar widget could be replaced with a simple textbox; a little used settings screen could be retired in favour of manually changing config files; or overly complex but little used workflows could be put on the back burner.
I maintain that a lot of “features” can be dropped, without actually impairing the business functionality of the system.
Just remember, what every you do DON’T consider dropping testing or QA in an effort to meet your deadline; unless you want to guarantee that you will continue to miss all future deadlines until the project gets cancelled!