Steven E. Newton
Crater Moon Development
Last in a series examining certain arguments for buying commercial software an minimally customizing it versus custom-developed software.
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.
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.<-Documentation has a Cost and a Value Build vs. Buy, Part 4 ->