From all that has been said most fail to apply the Six-P Rule: Proper Planning Prevents P**s Poor Performance. Then there is the mission creep problem.

What needs to happen is you need to plan that this is the core functionality that is needed at x point. An example:

We need to be able to input all the information and print the documents for a adjustable rate and fixed rate mortgage in six months. That is all that needs to be done. But then someone pops up with "We need to import credit reports." The answer to that needs to be "No, that isn't in the current plan. We will see if we can spare a person to work on it, but it is not a priority."

In the above scenario if the answer was yes, (and more than once) then it is likely the project will fail.

We had one vendor cough up a huge program that was slow, balky, needed patching frequently and skipped QA. We used it for 2 years and then found a new vendor that took the approach of saying no. We now have a smaller faster core, with multiple bolt-ons that is upgraded every 6 months on a schedule. We are a beta tester, and 99% of the beta is workable and only needs minor work before going to production. It's a whole different world.

Just my $0.02.