Discussing failures

Excellent bill by Michael Krigsman arguing that we should discuss failures of IT projects and show them as examples of what not to follow.
If I should sum up, here are the five factors that I saw as the root of failures of IT security projects in organizations (companies + public sector), along the years. The examples are invented.

1. "Political" interests priming over "intelligent" choices. Such as buying a solution from one vendor because the salesperson is Mr Bigboss's friend or the vendor is Mr Bigboss's favorite brand.
2. Bad top-down communication of the goals and objectives, which results in the implementation of a solution that solves problem B instead of problem A. For instance, Mr Bigboss decides that the crucial point is to protect the integrity of the central databases, but doesn't communicate it well and Mr Smallboss implements a solution that protects the confidentiality of the data going out of the central database. (This one seems simple to avoid once explained, but if you look back, I guess you can find a real example pretty easily.)
3. Relying on/Trusting too much service providers, thinking that getting the hands dirty is not necessary. This one results in entire sides of the project being forgotten, because the consultants only do what they are asked to.
4. Bad theory training of the administrators who will use the security solution. They know how to manipulate it but they don't understand the principles and they make bad interpretations of results. They are also not able to react when something goes out of the plan. This is particularly true of "all integrated" products with a shining graphical interface, where some people only retain the location of buttons and screens, and not their actual meaning/behaviour.
5. Allowing exceptions for top executives of the organization. Once a plan has been decided, everyone must follow it, including them.