This is part 2 in our series on business systems for membership and professional associations (you can read part 1 here).
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.
Unique needs and strategic value:
Strategic value in this context refers to processes that differentiate a member organisation. It is not a measure of how important the processes are to the organisation, which would be considered their business value. The requirement for a general ledger with cash book, accounts payable, and accounts receivable can hardly be called unique, yet it is absolutely core to most organisations.
We often see member organisations declare themselves to be different and therefore unique in their needs. Most member organisations are different in the services they provide, otherwise they wouldn’t exist. However the majority of the systems needed to provide those services are common, e.g. membership management, renewals, sale of products to members, and event management. Charities may not have members as such, but they do have supporters and sponsors that regularly donate; functionally this is very similar to inviting a paid member to renew their membership.
Therefore, following a “buy” approach may well deliver a system that meets most of your needs without compromising your ability to be different in provision of services. Your decision should then be based on the proportion of needs that are met, the importance of the gap, and the ability to customise to meet the gap.
Where your needs are genuinely unique and they provide the strategic value to separate you in your market-place then a “build” approach is effectively the only option.
Time to implement:
A comparison of realistic project plans for both approaches will show many tasks to be identical, e.g. acceptance testing, training, and data conversion. The “build” approach by necessity includes many more tasks to be performed around design, development, and unit testing. Therefore you would expect a project based on a “build” approach to take longer than one based on the “buy” approach. Indeed if there isn’t a difference, it’s a clear warning sign that one or both plans are grossly inaccurate.
Internal skill sets:
Successfully implementing a system using a “buy” approach requires a member organisation at the very least to have skills around project management, change management, and data conversion. In addition to these, a “build” approach requires a member organisation to take on the skills to effectively be a software developer.
This is far more than just hiring some developers for a period of time and represents high risk. Things to consider and manage include the development methodology to be adopted, development processes around source control, version control and bug control, software standards and documentation, and maintaining a support desk. These skills and resources are required for the life of the system albeit to a lesser degree once the system is merely being supported.
The risk can be partially mitigated by outsourcing to specialists. In return for taking on the risk, specialists will cost more. Even with outsourcing, strong internal project management skills will be needed to ensure the software development is meeting the challenging objectives of required functionality, on time and on budget.
Domain expertise:
In addition to the skill sets described above, the need for domain expertise should also be considered. For member organisations, domain expertise is required in areas such as:
- Privacy: the legal requirements around managing and using personal information under the Privacy Act and other state and territory legislation.
- Payment Card Industry Data Security Standard (PCI DSS): industry standards for dealing with credit card holder information.
- Telemarketing: the legal requirements imposed under Australian Consumer Laws and the Telemarketing and Research Calls Industry Standard of 2007.
Whilst your organisation needs to be aware of these requirements, it’s another matter to know them well enough to be able to design and maintain systems to be compliant i.e. the “build” approach. Adopting a “buy” approach simplifies this as the systems will already have the features and functions incorporated in them.
Change management:
Change management is a critical component of any project; it’s also a component that is often ignored or otherwise under-managed especially in IT projects.
For member organisations, change management can represent an even bigger challenge. The very nature of these organisations and what they do tends toward embedded and static processes. System changes are not undertaken as willingly or as frequently as commercial businesses.
When they are made, they have a bigger impact on the processes and the resulting change management needs are greater.
A “build” approach may appear to be desirable as the new system can be designed to follow the current processes.
However, the savings may not be realised as the design tasks can be quite lengthy when trying to define and reproduce current processes. Additionally, inefficient processes get reinforced rather than reengineered, thus mitigating some of the streamlining that can occur during an implementation.
A “buy” approach may appear to be undesirable if there is a perception of needing to change to meet the system. The additional change certainly needs managing, however with best practice being embodied in the software, the reduced risk and reduced process design time is significant.
Internal bias:
All organisations have an innate bias towards a “buy” approach or towards a “build” approach. That predisposition should be acknowledged, and the reasons for it understood so that they can be addressed directly. There may be valid reasons for the bias; equally though they may be based on past one-off experiences that are no longer relevant or based on misconceptions. In the worst cases they reflect personal agendas such as perceived career advances. If the organisational bias is not recognised and understood, the decision making process can easily focus on the wrong issues and an unsubstantiated decision made.
Conclusion:
Both approaches and combinations thereof have proved to be successful and with proper management will be successful for you. Deciding which approach is more appropriate for you is a matter for deliberation. As you go through the process of making the decision, you need to ensure that you have all the facts, to be clear about what your organisation is and what makes it unique. Taking an objective view and removing the emotion can do wonders for clarifying the decision.
You can download the whitepaper for this blog series here or learn more about Upbeat and how you can achieve more for your members.
