This post originated from an RSS feed registered with Agile Buzz by Steven E. Newton. Original Post: Build vs. Buy, Part 5 Feed Title: Crater Moon Buzz Feed URL: http://www.cmdev.com/buzz/blosxom.cgi?flav=rss Feed Description: Views and experiences from the software world. Latest Agile Buzz Posts Latest Agile Buzz Posts by Steven E. Newton Latest Posts From Crater Moon Buzz

Last in a series examining certain arguments for buying commercial software an minimally customizing it versus custom-developed software.

Customer Focus

If there is a single primary theme to the buy vs. build decision, it must be the users' needs as the priority driver. Every automation project will, to be truly successful, entail some realization by the customer of outmoded and wasteful practices that can be changed or eliminated. There is always the danger of "paving the cart path" to look out for. The issue to consider very carefully in a buy vs. build decision is whether implementing the purchased application will cause excessive and wasteful disruption of existing business processes. Some flexibility on the part of staff and management is desirable, in order to accommodate solutions which actually improve the process. In a healthy custom software development process, there is ongoing collaboration between business users and software developers to discover what is possible and desirable, and make the transition gradually. With purchase software, the customer gives up substantial leverage in its negotiating position in exchange for, it hopes, lower costs. But when implementing commercial software entails a radical overhaul of the business process before the benefits can be realized, that cost must be accounted for.

Review

The rule of thumb is "buy for parity, build for advantage". Whether or not there is a competitive edge to be gains through custom software development, there is only competitive equality with purchased COTS.