As one of Australia’s leading providers of IT products and services, we are regularly approached by organisations who are initiating the process of deciding whether to “buy” or whether to “build” the business systems they will be dependent upon. The system would be used to manage their membership recruitment, retention, and financials.
In reality, what they are deciding is which approach to adopt. It is rare that the approach is to only “buy” or to only “build” the future system. Instead the approach is based on a weighted mix; for example, weighted towards “buy” with customisation of commercial software or “build” with custom development based on pre-existing libraries. The addition of variables such as outsourcing and the choice of cloud based offerings make it even harder to compare apples with apples and thus increases the risk of not making an informed decision.
This two part blog series outlines what our experience has demonstrated to be the most important considerations for organisations such as Professional Memberships, Associations, and Charities (“Member Organisations”) to make that decision.
If your answer is no to any of the following questions, then we suggest you should be adopting an approach weighted towards “buy”.
- Do you want your organisation to be a software development business?
- Do you have the skills, processes, and management to be a software development organisation?
- Are your needs truly unique?
On what basis do we make such a suggestion?
Firstly, the questions above are not intended to be exhaustive, but rather leading indicators as to whether a “buy” weighted approach is better suited than a “build” weighted approach for your organisation’s needs.
A general wisdom built up over the years is that you buy for generic processes and build for processes that differentiate. It’s the distinction between generic and differentiated that reveals what you really need, and only then are you able to evaluate the true cost-benefit of the alternative approaches.
Important factors for member organisations to consider are:
- Total cost to implement and support.
- Unique needs and strategic value.
- Time to implement.
- Internal skill sets.
- Domain expertise.
- Change management.
- Internal bias.
Total cost to implement and support:
When comparing the costs between the two approaches, it is important to include all costs over the life of the system. For member organisations, a system life of 7 years or more is not unusual.
All other things being equal, you would expect the costs of the build approach to be higher than that of a buy approach, given that for pre-built software the overall effort is shared between multiple users of the system. Indeed it has been our experience that the external costs and the design stage alone for a “build” approach have been substantially greater than the full implementation costs of a bought system. The typical justification of this additional cost is based on perceived unique needs and strategic value.
As a word of caution, we recommend that when quantifying the costs above, you ensure the basis of the costs and related assumptions is clear. We have seen project cost estimates used for decision making, that are grossly incorrect for reasons such as:
- Inconsistent assumptions being applied for tasks that are common across both approaches, leading to a bias to one or other approach.
- Materially underestimating the effort involved especially for design and development, through a lack of understanding of what is required.
- Relying on experience that is not relevant and/or relying on vendor assertions about how easy it is.
Read the second part of the blog, or learn more about Upbeat and how you can achieve more for your members.
