Organizations face the buy vs. build decision for software frequently. The breadth and depth of software packages that are available to buy, or more typically license, for almost every sector of our economy and for every business function is astonishing. The number of websites that list software packages is so large that I’m providing only one link as an example.
As a result of this rich availability of software packages, a decision to build software rather than buy should be supported by a long list of compelling reasons or be quickly reversed. Here are the major buy vs. build decision criteria with my recommendations.
Business best practices
When you develop custom software, you are relying on just your end-users to ensure best practices are incorporated into the business requirements. By contrast, software packages often incorporate business best practices contributed by a large community of end-users.
Is it likely that your in-house end-users can articulate a superior set of business best practices? How does their expertise compare to a large community of end-users from multiple organizations that have been associated with the software package for a number of years?
Development cost
When you develop custom software, you are paying for the development team and for the end-user effort to participate in the development project. By contrast, the license fee for the software package will always be materially less than the development cost. Sometimes the license fee for an open source software package is zero.
Can you really justify the significant incremental cost in terms of tangible, irrefutable business benefits?
Time to Value
When you develop custom software, your elapsed time to the start of business value is longer, often years longer, than your elapsed time for the implementation of a software package.
Can you really justify the deferral of the start of business value?
Development risk
When you develop custom software, your risk of significant disappointment, cost overrun or failure is much higher than the risk of failing to implement a software package. The web houses many articles that expand on the reasons for this risk. Here’s one recent example. Some of the failure case studies are hilariously funny if the situation weren’t so tragic.
Can you really offset the added risk through significant tangible, irrefutable business benefits?
Development expertise
When you develop custom software, you must operate a software development team with sufficient development expertise to actually produce the software and maintain it. Assembling and keeping this development team in place is not as simple as it sounds. You are competing against giant Internet companies like Apple, Facebook, Google, and Microsoft for talent. You are also competing against financial services companies, Amazon, IBM, software package vendors and video game developers just to name a few.
By contrast, when you acquire the software package you are outsourcing this expertise problem to the software package vendor.
Can you really justify the acquisition, management and cost of a software development team for your organization?
Operating cost
When you operate custom software, you are paying for a development team to:
- Address software defects.
- Develop functionality enhancements.
- Respond to the impact of technology advancements.
By contrast, the annual maintenance fee for the software package is your share of these operating costs for the community of organizations that have licensed the same software package.
Can you really justify paying the entire software operating cost as opposed to sharing these operating costs with a community of organizations?
Integration issues
When you develop custom software, the functionality scope must include smooth integration with your existing applications. Since you’re in total control, this integration goal should be achievable. Sadly integration may revert to simple Excel-based data exchanges under the pressure of budget and schedule.
Similarly, a software package must be integrated with your existing applications. Ideally, the software package is designed for integration and includes pre-built configurations for this purpose.
Can you really justify developing all the custom software based on a possible integration advantage that can be solved cost-effectively for a software package, sometimes with ETL software?
Unique business process
Sometimes organizations convince themselves that their current business processes are so unique that they constitute a source of competitive advantage. More likely, their current business processes are the product of many historical decisions that actually:
- Add operational cost.
- Impede customer service.
- Reduce end-user effectiveness.
Can you really demonstrate convincingly that your unique business processes:
- Deliver significant competitive advantage?
- Cannot be revised to conform to the widely-accepted best practices that are incorporated into the best-fit software package available for your industry?
Do you still want to build software rather than buy it? What is your experience with software buy vs. build decisions at your organization?