I am a big fan of Steven McConnell's body of work. I came across an interesting piece which deserves sharing promptly for practioners of Software Engineering.

Some of the outlined Descriptions of Mistakes make for an interesting read and it evokes a feeling of Deja Vu for those who have been through it.

Abandonment of planning under pressure
Projects make plans and then routinely abandon them when they run into schedule trouble. This would not be a problem if the plans were updated to account for the schedule difficulties. The problem arises when the plans are abandoned with no substitute, which tends to make the project slide into code-and-fix mode.

Adding people to a late project ( This may sound like a lift off of the famous Mythical Man Month but unfortunately people are yet to learn their lessons)
When a project is behind, adding people can take more productivity away from existing team members than it adds through new ones. Adding people to a late project has been likened to pouring gasoline on a fire.

Assuming global development has a negligible impact on total effort
Multi-site development increases communication and coordination effort between sites. The greater the differences among the sites in terms of time zones, company cultures, and national cultures, the more the total project effort will increase. Some companies naively assume that changing from single-site development to multi-site development will have a
negligible impact on effort, but studies have shown that international development will typically increase effort by about 40% compared to single-site development.

Code-like-hell programming
Some organizations think that fast, loose, all-as-you-go coding is a route to rapid development. If the developers are sufficiently motivated, they reason, they can overcome any obstacles. This is far from the truth. The entrepreneurial model is often a cover for the old code-and-fix paradigm combined with an ambitious schedule, and that combination almost never works.

Confusing estimates with targets
Some organizations set schedules based purely on the desirability of business targets without also creating analytically-derived cost or schedule estimates. While target setting is not bad in and of itself, some organizations actually refer to the target as the ‘estimate,’ which lends
it an unwarranted and misleading authenticity as a foundation for creating plans, schedules, and commitments.

Developer goldplating
Developers are fascinated by new technology and are sometimes anxious to try out new capabilities of their language or environment or to create their own implementation of a slick feature they saw in another product— whether or not it’s required in their product. The effort required to design, implement, test, document, and support features that are not
required adds cost and lengthens the schedule.

But hey !!! Who is rectifying them. This cycle goes on and on in the churn of a typical IT Services Business where it ultimate objective is Margin with a capital M. Add to it some Office Politics and you have a sure shot recipe for what can be termed as "Setting up for Failure".

The big question still remains - Who will bell the cat ?