Most CIOs and senior IT managers would agree that it is better to buy already-built IT systems rather then design them from scratch. This decision becomes more of an imperative the more complex the system is. Not all business people understand this however. Some of them believe programmers can do anything and managers' refusal to develop 'from scratch' is either due to plain old unwillingness or even worse incompetence.
Over the years I have been involved with the Software Engineering Institute. I standardized the software development groups of a couple of organizations I led on SEI-inspired methods and on automation from Rational Software. While we never followed the CMM to the letter we did adapt it to our organization's size and needs. We also have used principals from another of their process models, EPIC (Evolutionary Process for the Integration of COTS-based Systems) in the IS Business Analyst section I ran for a Canadian Bank. In all of these experiences, with significant emphasis on software quality by design and by testing I have come to the conclusion that the development of quality software is not for the faint of heart. It requires exceptional rigor from all participants (management, architects, developers, and testers). It is expensive to do regardless of whether you build quality in or you pay through post-production failure-fix cycles. Built-in quality being not only the more preferable of the two but also the less expensive. Some general managers are not willing to pay the up-front costs for quality and then gripe after the software causes interruptions to their business. Many IS management are not insistent enough to the resourcing required to build it right as this insistence sometimes means a willingness to resign if necessary - and if you have to threaten this its better to just start looking. There are more than enough of these two cases to account for the numerous failed software projects we've heard about. By the way, the teams I've led have made good quality software. No business has experienced interruptions due to bugs in our code. I say this to assure you that a) good software can be built and b) I'm talking from a position of strength and not weakness. It has always been expensive though and I have often questioned whether we have delivered adequate value for the investment.
There are many examples of failed software. The more complex the more difficult it is to design. In this article we see what happens when a green-field software development project of a complex system goes awry post-production. What was probably very little malfunctioning code resulted in a potential billion-dollar disaster and more importantly the potential loss of ten or more lives. And in this case it is very likely the development team used a disciplined quality process to deliver the system. It's the only way to get something this complex to work at all.
SD is not, nor should be, the core competency of businesses not in the technology business. Business should adopt COTS (Commercial Off-The-Shelf) systems. If you need functionality not found in existing systems, find one that delivers most of what you need and build the small pieces that are missing. Or else integrate multiple systems using an iterative method (RUP, EPIC) where possible. The systems you do build should be either relatively simple or non-mission-critical. If you have to build a larger system, use an iterative process to deliver a smaller system and build on it. There are many solutions. The big-bang approach being the least likely to succeed. Keep in mind though that every time you build a medium-large complex system you take your career into your hands.