The Eight Signs

2. Coding from "spec of the day".
You have to have both a good data model (to map the legacy software systems to the new software and vice versa) and good written documentation of all the business processes that are affected by your software solution. An aggressive schedule didn't allow time to do a model or a process map. As a result new requirements are generated from emails and comments in meetings attended by management. This alone has cost massive changes in existing code and since very few of the suggestions are evaluated for impacts prior to being made into hard requirements.
Lesson: Don't think you are saving time or money on the front end by not modelling both the software and the business processes. You're kidding yourself and dooming your project from the outset.

3. You don't have a project plan.
The author of the article notes that this speaks for itself. I would add that a project plan is only as good as the information that goes into it. Just because it is called a project plan doesn't mean it is a project plan if hard data is ignored for the sake of having a schedule that looks good.
Lesson: A good project plan is essential. It should be based on hard data and emotion should not come into play.

4. You and your software vendor aren't on speaking terms (the author in the linked article used the opposite example, but this is the same thing)
When the software vendor and the client stop communicating effectively there are problems. This is seldom the fault of just one party since it takes two to tango as the saying goes. Software vendors have to know what they are bidding on before they start actually bidding. Customers have to disclose all of their requirements up front so that good bids and proposals will come back.
Lesson: Once the marriage starts to fall apart it is hard to put things back together. There are two lessons here. For software vendors, don't bid a project because you think you understand the requirements even though they are obviously not all documented. You are the expert in whatever software you are selling. Use your expertise and go back to the customer for clarifications BEFORE bidding.
For customers, don't go out for software to solve problems that you think you have. Make sure you understand your business and what specific problems you want to solve before finding somebody to help you solve your problems. Vendors are happy to take your money for no particular reason.

5. The project sponsor lives in a cave
When faced with a large software project at a business it is important (essential) that there is support for the project from the highest levels of management. No project that is implementing new technology will be scoped 100% accurately. There will be times you have to go back to upper management for more money, personnel or time. This is where a good project plan is essential as well. If top management doesn't get fully behind the project and isn't kept in sync with what is really happening on the project, good and bad, the project will eventually flounder and possibly die.
Lesson: Don't even start a large software project if management is not fully behind it. Changing software often times means changing the business culture as well and that kind of change can only come from the top.

6. No change management system
Again, this plays back to schedule. When writing new code there is an old saw that states for every bug removed two new bugs are inserted to take it's place. If you don't put time into your schedule for the software vendor to test their code appropriately followed by you (the customer) testing the code properly against your business processes bad things will happen. This also goes back to requirements definition. Specific requirements are needed to write good code. Don't give the vendor a requirement such as "Software has to do X" when what you mean is "Software has to do X, Y and Z".
In addition, when testing and documenting bugs this should be done formally (tracked back to specific requirements) in a shared bug tracking system. A software project can not succeed if the customer is working to one tracking system with it's own set of data and the vendor is working to a separate bug tracking system with it's own set of data. The room for error and miscommunication is way too vast.
Lesson: Good requirements lead to good code. Bug tracking should be accomplished formally in a shared (by the vendor and customer) bug tracking system so that everybody is talking the same language.

7. There is not a status reporting system.
Nobody likes to be the bearer of bad news, but if you don't have a formal method of reporting and tracking status you are doomed. Project plans and formal status meetings both for upper management and the project team are essential. Without this, your project will tend to drag on indefinitely and nobody will have a clear understanding of why.
Lesson: Establish your status reporting system at the beginning of the project and don't let it die. Management should insist on this and the project manager should as well.

8. Time in meetings is spent playing "buzz word bingo"
Ok, I paraphrased the author on this one. Meetings are an important part of any project. Decisions have to be made, concurrence has to be obtained and status has to be shared. Meetings should have formal agendas and those agendas should be followed. Otherwise you are just wasting valuable time.
Lesson: If the meeting organizer just likes to hear the sound of their own voice you have problems. Meetings can be productive but too often aren't. If people are sleeping or you have to repeat questions then you don't have a good meeting.