Organizations face the buy vs. build decision for software frequently. The breadth and depth of software packages available to license or use via a Software-as-a-Service (SaaS) are astonishing.
Software is readily available for every sector of our economy and every business function. 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 significant buy vs. build decision criteria with my recommendations.
Business best practices
When you develop custom software, you rely on your end-users to ensure best practices are incorporated into the business requirements. By contrast, software packages often contain business best practices from a sizeable end-user community.
 |
|||||
| Related Stories | |||||
| Dearth of software savvy people bad news for the economy
|
|||||
| How anyone can get a job in tech
|
|||||
| Are your apps duds?
|
|||||
|
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 associated with the software package for several years?
Development cost
When you develop custom software, you pay for the development team and 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 high incremental cost for custom software 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 implementing 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 example. The failure case studies would be hilariously funny if the situation weren’t so tragic.
Can you really offset the added risk through significant tangible, irrefutable business benefits?
Development expertise
To develop custom software, you must operate a software development team with sufficient expertise to produce and maintain the software. Assembling and keeping this development team in place is not as simple as it sounds. You’re 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, to name a few.
By contrast, when you acquire the software package, you outsource this expertise problem to the 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 instead of sharing these costs with a community of organizations?
Integration issues
The functionality scope must include smooth integration with your existing applications when you develop custom software. Since you’re in total control, this integration goal should be achievable. Sadly, integration may revert to simple Excel-based data exchanges under budget and schedule pressure.
Similarly, a software package must be integrated with your existing applications. Ideally, the software package is designed for integration and includes pre-built configurations.
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 existing 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 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?
Yogi Schulz has over 40 years of information technology experience in various industries. Yogi works extensively in the petroleum industry. He manages projects that arise from changes in business requirements, the need to leverage technology opportunities, and mergers. His specialties include IT strategy, web strategy and project management.
For interview requests, click here.
The opinions expressed by our columnists and contributors are theirs alone and do not inherently or expressly reflect the views of our publication.
© Troy Media
Troy Media is an editorial content provider to media outlets and its own hosted community news outlets across Canada.
