Procurement Strategies for Information Systems

TLDR

Company‑specific, high‑uncertainty systems are best developed internally, whereas standard or routine systems are more efficiently procured through consultants or off‑the‑shelf packages. The study introduces a general procurement‑strategy framework to help managers evaluate their project portfolios and select more effective uses of internal and market resources in information‑systems development. The framework applies transaction‑cost economics criteria—system specificity and requirement‑uncertainty—to determine which procurement strategy is appropriate, and it guides managers in reviewing portfolio options. Empirical tests with Finnish firms partially confirm the principle, yet some projects still prefer in‑house development even for routine systems.

Abstract

:A general framework of different procurement strategies is introduced to help managers review their project portfolio to find more effective ways of using both internal and market resources in information systems development. Major decision criteria—the specificity of system design and the uncertainty involved in requirements specification—are adopted from transaction cost economics to determine what procurement strategies should be used in different situations. According to our Procurement Principle, systems that are company-specific and involve high uncertainty have to be internally developed because they require both the specific knowledge and intensive interaction between developers and users. More standard requirements indicate the use of outside consultants or software contractors who have experience and knowledge about a similar type of systems. For routine systems common in many organizations, acquisition and tailoring of a software package provides the most efficient procurement strategy. The Procurement Principle is also empirically tested with data from recent system development projects in major Finnish companies. Partial support was gained for the framework, but some interesting deviations were also detected, such as a tendency to rely on in-house development of even routine systems.