When an organization is trying to develop customized tools to manage its business, there is always a critical decision: build vs buy. The wrong answer can cost millions of dollars, months of time, and lead to software development failure. Here are some rules of thumb and basic factors to consider when making a build vs buy decision for customized software.
Define CAREFULLY exactly what you need the application to do. If you miss 10% of what is required, you may miss critical functionality that could either cost more to develop or which may be impossible to achieve with a buy decision.
Generally, if it’s simple and easy and you have the right staff or a good developer: Build
If it’s complex: expertise, maturity, and economies of scale CAN come from acquired packages, but you have to ensure you can customize the application to do exactly what you need
Build will typically take longer.
Buy allows you to start deployment faster, unless significant customization is necessary or unless significant work process changes and training is necessary
You have to consider the capabilities that current staff have, for example:
- Staff is adroit with Microsoft Access
- Can easily create and support a medium-sized database to meet their needs
- OR, Staff has little technical experience, and no database skills
- Any solution would need external support.
Build allows for managing risks related to the solution not ideally fitting the organization, and allowing for modification.
Buy puts risks such as development problems and time slips on the vendor so you have to ensure that the vendor is responsive and has the capabilities and experience to execute on the project.
Buy allow an organization to rely on professional support structures and/or open source communities
- Risk: non-responsive or costly to get exactly what you need
Build requires building that capacity in-house.
- Risk: costly, time-consuming
Evaluate Total Costs!
According to Mark Lutchen, former global CIO of PricewaterhouseCoopers, “When evaluating whether to buy or build, it’s critical to thoroughly understand total costs during the software lifecycle — typically seven or eight years. This step is important because 70 percent of software costs occur after implementation. A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers often tips the balance in favor of buying.”
Here is a matrix that will help with the decision:
