There Is No Best IT Strategy

There is a consulting pitch I keep hearing about enterprise software. The vendor explains that their platform encodes decades of industry best practices. Every process, every workflow, every approval hierarchy has been refined by thousands of implementations across hundreds of companies. All you have to do is adopt the system, and you inherit all that accumulated wisdom. It sounds reasonable. The problem is that best practices are always someone else's best practices, built for someone else's context.

Contingency theory, as broadly developed in organizational management research from the 1960s onward (Lawrence and Lorsch are among the widely cited figures in this tradition), starts from a simple and uncomfortable premise: there is no single best way to organize or manage. The optimal structure, strategy, or approach depends on the situation. Specifically, it depends on how well the chosen approach fits the organization's environment, size, technology, and task. When the fit is good, performance tends to be better. When the fit is poor, even a technically superior approach can produce worse outcomes than a simpler approach that actually matches the context.

My reading of this literature suggests that fit, not quality, is the central variable. Two organizations can adopt the same software, apply the same implementation methodology, even hire the same consulting firm, and end up with completely different results. The explanation is not that one organization is better or smarter. It is that the approach fit one context and did not fit the other.

Applied to IS, this reframes some questions I think researchers and practitioners get wrong. The question is not "which ERP system is best?" The question is "which ERP system fits this organization's size, industry, process complexity, degree of customization need, and internal IT capability?" Those are different questions. The first one sounds answerable. The second one reveals that the answer depends on information that most best-practice frameworks never ask for.

I want to be honest that the specific empirical work applying contingency theory to IT strategy is broad and spans many decades of IS research. The core argument, as widely cited in management and IS research, is that fit between technology characteristics and organizational characteristics determines outcomes. This has been applied to questions like whether centralized or decentralized IT governance fits better in different organizational types, whether certain software architectures suit stable versus dynamic environments, and whether the same digital strategy works differently depending on firm size and market position.

The SAP case is probably the clearest industry illustration. SAP's best practices modules are, by their own account, built from decades of process knowledge accumulated across thousands of implementations. The promise is compelling. You are not just buying software. You are buying the distilled wisdom of a global consulting and implementation ecosystem. But the model assumes that a manufacturing firm in Germany and a services firm in Texas have enough structural similarity that the same process design works for both. That is a contingency claim, and it often fails. When it fails, the standard remedies are customization (which SAP historically discouraged because it breaks upgrade paths) or organizational redesign (which means reshaping the company around the software rather than the other way around). Both responses confirm the contingency point: best practices required a specific context to be best, and when the context differed, something had to change.

The deeper issue is that "best practice" language smuggles in an assumption that context does not matter, or that the relevant contextual variables have already been averaged away across thousands of implementations. But averaging produces a practice that is optimal for no one in particular. The average patient weight is not the right dosage for any specific patient.

I think about this when I see IT strategy recommendations that treat industry, size, and structure as incidental details rather than central inputs. Cloud-first? Depends on data sovereignty requirements, legacy system complexity, and whether the organization's work is latency-sensitive. Microservices architecture? Depends on team size, deployment cadence, and organizational bandwidth to manage distributed systems. Centralize the data team? Depends on how embedded analytics needs to be in operational decisions and whether the business units have enough domain knowledge to self-serve. Every one of these is a contingency claim dressed up as a universal prescription.

This also applies to how organizations evaluate technology investments. The RBV-influenced IS literature (Bharadwaj 2000 is a frequently cited example in this territory) argues that IT capability, as a combination of infrastructure, human skills, and intangible assets, is what generates performance advantages. But even capability-based arguments have a contingency component. An organization that builds excellent data infrastructure in a stable environment may find that its carefully optimized system is a liability when the environment shifts rapidly and the infrastructure cannot flex. The value of a capability depends on the competitive landscape it operates in.

What the contingency lens adds, that I think gets undervalued in IS research, is a reason why technology implementations that look identical on paper produce such variable outcomes. The research design problem is that we often measure whether organizations adopted a technology and whether performance improved, but we do not always measure whether the technology fit the organization's specific structural and environmental characteristics. Without fit as a measured construct, we cannot separate "this worked because it was well-executed" from "this worked because it fit."

This is also what makes IT strategy genuinely difficult. It requires enough knowledge of your own organization's context to evaluate which practices, from which reference group, with what degree of modification, actually apply to you. The shortcut of importing a best practice from an admired firm is appealing precisely because doing that evaluation is hard. But the shortcut produces its own costs, usually discovered eighteen months into an implementation.