Following examples of a successful IS implementation, the Bankers Trust of Australia, and an on-going failure with the example of the UK's Universal Credit project, it is opportune to consider a subset of IS that is common to both projects and determine whether there is a general rule that can be applied. In particular, attention is drawn to the fact that the IT contract for the IS projects in the two cases was either largely developed in-house for the successful project and fully outsourced in the failed project. Common-sense should dictate that this cannot be universalised; surely not every introduction of an IS system must have the IT component developed in-house? One wonders whether there are any thorough studies with practical implementations to explore when it in-house or outsourced development is appropriate?

Traylor (2006) looks at this very issue, arguing "Decades of trial, error, and egghead analysis have yielded a consensus conclusion: Buy when you need to automate commodity business processes; build when you're dealing with the core processes that differentiate your company", however immediately pointing out that such a theoretical model (doubtless built on numerous empirical examples), may encounter problems with reality, such as in-house software for standard processes may come with very high transition costs, whereas external commercial packages may actually be a very good fit for strategic plans. Traylor continues: "'Buy to standardize, build to compete' may be terrific as an ideology, but the choices that real companies face are a lot messier ... and more interesting."

Following the arguments of several senior executives from companies with significant IT investments, some variation is noted. The former CIO of Pricewaterhouse Coopers argues that "[E]verybody knows" that standardised and off-the-shelf purchases are more cost-effective for implementation and maintenance, whereas the IT chief architect at MCI argues for in-house development where one can get incremental revenue or a competitive advantage, whilst at the same time encouraging code re-use. Whilst decisions metrics (cost, skill-sets, strategic value etc) remain the same in either approach, and most firms have a combination of both, Traylor also points out - almost fifteen years ago now - that open source software offers the best of both, providing standards-compliance and bespoke elements. Emphasis is also made towards the software lifecycle with the stated claim that 70 percent of software costs occur after implementation.

Even large and security-conscious companies, such as Visa, who have an enormous amount of in-house development will purchase commercial solutions when there is no competitive advantage to be achieved and costs would be greater to follow the in-house method. Nevertheless, when it comes to commercial software a clear warning is expressed about developing components outside that commercial package which are nevertheless dependent on it. The result of such an approach will be to generate in-house software with critical dependencies which is outside of the control of the organisation, which is both wasteful and dangerous. In many cases, commercial applications offer their own extensions which can fit existing varied business processes.

This is not to say that in-house development should not occur alongside or even with commercial offerings. It should just not be for the same business process (e.g., an accounting package with an in-house accounting extension). An example is given of the District of Columbia city government which has migrated from a myriad of in-house applications to commercial applications, yet still has specific business processes (such as Business Intelligence) which are developed in-house, because commercial applications did not meet the needs of the organisation. Sometimes opportunities even exist for commercialisation with existing vendors to develop new applications, such as the work between the University of Pittsburgh Medical Center and Stentor for a picture-archiving communications system.

Traylor argues the IT Planning Software is taking into account these decisions, and helping managers determine whether to build or buy, and gives an example of the questions confronting MCI on a system to track third-party services inventory. It comes across as being a lot less detailed or sophisticated as one would hope for in a for a purchase of such importance. One is interested about the series of posed questions is that they are almost entirely in reference to an IT business approach, rather than an IS approach - there is little evidence that the question of existing business processes, staff involvement etc are included in such software packages. Whilst does suggest that whilst they provide some contribution to the decision, it is also evidence that an IS decision must be of broader scope than an IT decision.

Reference

Traylor, Polly (2006). To build or to buy IT applications?, InfoWorld, 13 Feb, 2006