These rules actually favor being "on time", which to me is a terrible goal for a software project. Those who think software can be "on time", tend to also cons

These rules actually favor being "on time", which to me is a terrible goal for a software project. Those who think software can be "on time", tend to also consider the software "done". In reality, any project can be "on time" and still fail miserably if it's hard to debug, hard to modify, hard to support, or implodes when the lead developer quits. You don't want software that's "on time", you want customers who are well-informed so that their dependencies are more specific and flexible than a "release date". You want them to be thinking long-term, so that they understand the true risks of insisting on early delivery (e.g. less testing, review and documentation may have been done, hence more bugs may appear in the future).