InfoWorld has a fascinating story on a build vs. buy scenario at a railroad:

Around this time we sent a few IT troopers down to KS to see what was going on. It was the last point the project could have been killed or redirected, so I checked in with my friend Michael, a savvy project-management contractor. He did an analysis comparing the functionality and cost of reinventing the system in house with modifying the business processes involved in the KS model; KS's business processes were very different from ours. Michael calculated that if we continued with the collaboration as planned the price would not be $30 million or even $60 million. It would be closer to $70 million. The cost of developing a new system from scratch -- one that would perform the same functions as the KS system and be properly designed for our business groups -- would only run about $45 million.

Of course, management refused to budge from the existing project, even as costs escalated. Once the numbers get "too big", politics comes into play - no one wants to be identified with a failure on a large scale, so an "all is well" attitude takes over.

The basic problem is the premise - that "buy" is always better than "build".Often it is - especially with commodity software. The trouble is spotting which parts of your businesses can't easily be handled by commodity software, and dealing with those. Many companies have wasted millions on ERP installations over this. Why? Because a pre-built ERP system will impose a set of rules on how operations will run. Those rules may well be fine, in the abstract. What they don't account for is the peculiar culture of your company. Ask yourself - as hard as it is to change software, is it actually easier to change corporate culture?