The disadvantages of in-house custom software development: A story of “captured” software

When purchasing nonprofit management software, it can be hard to decide whether to develop custom software solutions or to choose an off-the-self software product.

Charities and NGOs will sometimes opt to build a custom software solution in-house that is designed for the specific problems that they face, and the specific tasks they need to accomplish – rather than purchase out-of-the-box software that will be naturally limited.

It is easy for Not-for-profit organizations (NFPs), like many other small organizations, to fall into traps when they first acquire software systems for managing their operations.

NFPs are usually strapped for cash and software costs are not easy to justify for funding. In general, the effectiveness of the organization is measured by service level not profitability. So NFPs are often slower than their for-profit counterparts to implement comprehensive nonprofit management software that tracks every aspect of their organization.

The move to computerize processes is sometimes driven by one person in the organization who has technical skills, and offers to develop a custom system very cheaply. It will only cost the salary of the developer.

The benefits of developing software in-house this way are that it is completely configurable (designed with the individual organization in mind) and can be very cheap (it only costs the salary of the developer). However, this approach has many hidden pitfalls that are not always obvious at the outset. In my experience of auditing computer systems it can occur in large organizations too but in a slightly different guise.

The problem that arises is that the system gets “captured” by the dominant user. The profile of captured software is:

  • The user/staff-member offers to develop an appropriate system, provided they can do it in work hours. This distracts them from delivering the organization’s outputs.
  • The nonprofit software that is developed is not properly tested and frequently throws up errors. It is not always trusted by other staff members.
  • The software is usually quite inflexible. It is difficult to expand and upgrade to meet the changing role of the organization.
  • The software is not quite finished, it has rough edges, input is tricky and the reports are hard to understand.
  • When a bug is found in the software or it needs upgrading you find that the developer has moved on or does not have time to modify it.
  • If it is a staff member that developed and uses the software, frequently he/she is the only one who knows how the system works. They have “captured” it.

There are easy ways to avoid ending up with a captured software system in your nonprofit organization. You can ensure that the staff member developing your system frequently consults with and trains other staff members. You could engage external custom software development services, with clear deliverables in terms of software specifications and ongoing support. Or you could purchase externally developed software that is ready to use off-the-shelf. You can either choose an option that your nonprofit organization hosts, or software as a service (SaaS) that is hosted elsewhere for you.

In future posts we’ll be discussing the positives and negatives of these various options. In the meantime, if you’ve had experience with a “captured” software system or you’d like to learn more about how to avoid ending up with one in your organization we’d like to hear from you – comment below!

2018-02-06T23:24:50+00:00 February 6th, 2018|

Leave a Reply

Discover more from Granity

Subscribe now to keep reading and get access to the full archive.

Continue reading