In-House Developed Software

Overview

A significant amount of in-house developed software is often created by the in-house IT area.  A key symptom is a proliferation of Microsoft Access databases. 

Although the positive results can be significant from developing in-house software, and this approach often removes the need to purchase very expensive software (and software in some cases that does not exist), several issues should be taken into account before developing in-house software.

Technical Issues

The use of Access databases may not always be technically appropriate. In particular, it becomes difficult to integrate Access databases and maintain software application versions across a network without affecting network speeds .

Stepping Outside the Budgeting Process

Often, the systems developed appear to be undertaken as requests from end users for software that cannot be funded from the budget. Software may be developed that address the required business functionality, meet the users’ needs, and save significant up-front investment costs. However, the application of resources (i.e. a staff member’s time) is not allocated according to a business need – the IT area spends its own resource (time) for another department to save resources (budget).

It is often difficult (but not impossible) for an internal application development team to consider the issues objectively and to act in accordance with the enterprise’s best interests. As part of the same enterprise, they can face internal pressures to develop information systems that would not be developed were the arrangement at arms’ length (as would be the case with a third-party software developer that must charge fees to be economically viable).

Uncertainty of Outcomes

When software is built in-house, the cost of doing so may initially appear to be less, as there is no profit component included and any overheads are considered to be ‘sunk’ costs.

However, the likelihood of achieving the benefits is less certain. Therefore, the benefits should be reduced by this risk factor when considering in-house systems for development (or alternatively, the costs of the project can be increased by the risk factor) in order to consider properly the business case of the application development. It is not appropriate to say “this database will save $10,000 on the cost of a new off-the-shelf system”. The potential benefit needs to be discounted by the risk factor that applies.

Additionally, the long-term support and maintenance of the developed information system is often not given proper consideration in the business case. Once the application is developed, there is a need to provide support and maintenance for that system in the long term and, without an extended user base (i.e. other businesses to share the costs with – as is the case with a packaged solution), the costs can be considerable.

Staff Retention

Linked with the issue of support and maintenance is the difficulty of attracting and retaining in-house application development staff. Application development staff generally prefer to develop new information systems rather than maintain existing systems. Retaining that corporate experience with the information system over the life of that information system with an in-house application development team can be difficult if the ability to challenge and extend the skills of the internal staff is limited.

In this case, a single person has created a significant number of database software applications. Although the software development environment chosen may be relatively mainstream (e.g. Java, Microsoft Access, Microsoft.Net), the risk exposure remains that future maintenance and development will fail due to staff turnover, or at least of the limits on that staff member’s available time.

Software Development Lifecycle

When a packaged application is purchased, it is expected that the software developer will carry out future research and development such that new technologies will over time be integrated into the product. With an in-house application, this is unlikely to occur – rather the system will tend to be redeveloped or have new technologies integrated only when the functionality loss is too much to bear, or at crisis points in the system’s lifecycle (e.g. when it suddenly stops working).

Risk-Adjusted Cost/Benefit Analysis

For all of the preceding reasons, there should be reservations that the benefits of in-house application development can be achieved.

Accordingly, it is suggested that any consideration of an in-house application development project take the approach of a Risk-Adjusted Cost/Benefit Analysis. Here, the business case for the development of a new in-house application solution for member management needs to incorporate a risk-adjustment factor in consideration of the costs and benefits, and provide a range of costs/benefits for consideration. That is, the uncertainty of actual costs and the uncertainty of actual benefits being realised is factored into any consideration of an in-house application development project.

Strategic Grid

Consideration of the following strategic grid in evaluating new information systems for external purchase or internal development may be of assistance:

Important questions for consideration include:

• Identifying existing in-house applications;
• Identifying existing applications that are appropriate (and developing technical documentation for these applications); &
• Migrating from existing applications that are not appropriate to new solutions.

It is often valuable for a business to develop a policy for the development of in-house application development of software solutions that takes into account the strategic grid outlined, and the risk-adjusted cost/benefit analysis.