"Why projects fail" is always a popular topic with those of us who write about IT. My favorite reason, if one can say that, is poor requirements. Variations on this are: incorrect requirements that are used and not caught until test or implementation; requirements that seem to keep changing, and requirements that were right to start but delivery took too long.
The last one is really a project or product management issue, essentially delivery of results in a timely manner while avoiding risks of a big-bang implementation. As I have said elsewhere, I like releases every three months. In a maintenance project (which a very high percentage of projects are), that works well because the result is a changed existing system, which the organization continues to use. New development projects will not necessarily deliver something every three months that can be implemented and used, especially if a replacing a large current system. One approach is to gather two or three releases and so on until a usable product is complete, but that can lead back to the problem we are trying to avoid.
Another approach is to interface the new system pieces to the parts of the current system that have not been replaced yet. This will never be easy, and the added expense to do it will always be questioned because interfaces will be retired as more of the new system is delivered; 'throwaway' code is seen as a waste, but the benefit of doing it is still what we want, avoiding project failure because of outdated requirements. It also gives the organization a chance to get used to the new system, and any issue that could cause user rejection can be dealt with as they are found.
Next time: the myth of changing requirements...