1. The deliverables were not clearly defined and maintained. How can you deliver something if you don't know what it is? In many cases there is either not a clearly defined and understood deliverable. This leads to every project officer having a different idea as to what they had to deliver leading to disagreements and conflicts and allowing external manipulation and scope creep.
2. People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project.
How many times have you seen a project team employed to deliver "the new product", only to then have it handed over to the operational support team, who then have to try to work out what this monster is that they have been given and how they are every going to get it to work in the way it was originally specified. You see this a lot when you have a system replacement being designed and developed by an external team, then handed to the people who supported the old system.
Who best knows the task the old system was designed to complete, who knows the edge cases and peculiarities that system had to handle, and in most cases, who came up with the work arounds that kept the old system working. If you are going to replace a system, and you are going to maintain your current team to support the new system, then get them working on the development of the new system. Not only will they be invaluable in identifying edge cases that the project architects may not be aware of, but as they are going to be the ones who will have to live with the new system, they will do their bests to make bloody sure that it's going to do what is's supposed to. Oh and make sure they are in a position to call out things that just won't work.