IT Outsourcing: Why We Keep Doing the Same Thing

The outsourcing-insourcing pendulum is one of the most reliable patterns in enterprise IT history. Companies sign big contracts, celebrate the cost savings, discover the problems, unwind the deals at significant expense, rebuild internal capability, and then, a few years later, a new CIO or CFO arrives and the process starts again. I do not think this happens because organizations are stupid. I think it happens because the decision to outsource is almost always made on incomplete information, and the framework used to make it almost guarantees the same mistakes will repeat.

The GM and EDS story is probably the most famous version of this. In 1986, General Motors completed what was widely reported at the time as the largest outsourcing deal in history, transferring most of its IT operations to Electronic Data Systems, the company Ross Perot had built. The logic was straightforward: GM made cars, not software, so why build and manage a massive internal IT organization? By many accounts, the relationship was troubled from early on. GM and EDS had different cultures, different incentive structures, and different ideas about what "good IT service" meant. When GM eventually tried to buy out EDS and disentangle itself, the process reportedly cost billions and took years. The IT capability GM had offloaded did not simply snap back into place. The people, the knowledge, the institutional memory were gone.

JPMorgan Chase signed a ten-year, roughly five-billion-dollar outsourcing deal with IBM in 2002. Two years later, they terminated it. By their own account at the time, they found they could manage the work better and more cheaply internally. That reversal is striking on its own. But what is more interesting to me is that JPMorgan had to rebuild a significant internal IT capability in a very short window. They could do that because they still had enough people and organizational knowledge to reconstitute the function. Most organizations that go through a full outsourcing cycle are not so lucky.

The UK government has provided its own long-running case study. The NHS National Programme for IT, which was the attempt to build a unified electronic records system for England, ran for years, consumed billions of pounds by most public accounts, and was eventually dismantled without delivering the promised system. The programme involved large contracts with major vendors and repeated disputes about scope, delivery, and cost. It is a different kind of outsourcing story from GM or JPMorgan, because it involved government contracting rather than commercial IT, but the underlying dynamics are similar: a complex principal, a vendor with different incentives, a specification that did not capture what the client actually needed, and a contract that could not bridge that gap.

What makes these cases so instructive is not that outsourcing failed. It is why it failed, and why the failure is so predictable from a theoretical standpoint.

Transaction cost economics, developed by Oliver Williamson building on earlier work from the 1970s and 1980s, gives a clean framework for the outsourcing decision. The basic argument is that organizations choose between markets and hierarchies by comparing transaction costs. If you can buy a service in the market more cheaply than you can produce it internally, after accounting for the costs of contracting, monitoring, and enforcement, then you should outsource. If the internal production costs are lower, or if the transaction is complex enough that contracting is too expensive, you keep it in-house. This logic is sound. The problem is that organizations applying it to IT routinely undercount the transaction costs.

The most common things that get ignored in the original business case are: the cost of writing and managing a contract that actually covers what you need, the cost of monitoring whether the vendor is delivering, the difficulty of renegotiating when conditions change (and in IT, conditions always change), and the cost of getting your knowledge back when the relationship ends. That last one is the one that kills organizations. It rarely appears in the spreadsheet that justifies the deal.

Agency theory, laid out by Jensen and Meckling (1976) and extended by Eisenhardt (1989) to organizational contexts, explains the monitoring problem directly. When a principal delegates work to an agent, two things happen almost automatically. First, goal conflict: the vendor's incentives, which center on margin and contract compliance, do not naturally align with the client's incentives, which center on quality and total cost of ownership. Second, information asymmetry: the vendor knows far more about what is actually happening inside the work than the client can observe. The contract tries to close this gap, but it never closes it fully. The vendor always has room to optimize for what the contract measures rather than what the client actually needs.

This shows up in every IT outsourcing relationship eventually. The vendor meets the SLA for system uptime while the usability problems mount. The vendor delivers software on schedule while the technical debt accumulates. The contract specifies response times for incidents but says nothing about the quality of problem resolution. Every metric you can monitor creates an incentive to optimize for that metric and not the unmeasured thing behind it. I wrote about this dynamic in more detail in the context of algorithmic accountability, and the parallel is direct: when control and responsibility are unclear, the agent optimizes for what is measured.

The knowledge problem is the part that makes me most uncomfortable when I think about it carefully. When an organization outsources IT, the people who understand the systems either leave or transfer to the vendor. The institutional knowledge, the informal understanding of why things were built a certain way, what the edge cases are, which integrations are fragile, which parts of the documentation are wrong, goes with them. After three or four years, the internal staff who remain often cannot run the systems without the vendor. They have become dependent in a way that was not visible at the time of the original decision.

This dependency is what gives the vendor its real negotiating power. Not the contract. The contract is what the client thinks gives them power, but it is a document. The real power is that the client cannot leave without a painful and expensive transition, because leaving means rebuilding capability that no longer exists inside the organization. The vendor knows this. The client often does not realize it until they try to renegotiate or terminate.

In the 2010s and through the 2020s, a visible wave of insourcing happened across tech-adjacent industries. Finance firms, major retailers, and media companies began building internal engineering organizations that would have seemed unnecessary or wasteful by the logic of the 1990s outsourcing era. Part of this was driven by the shift to software as a competitive differentiator. If your core business now depends on digital capability, the argument that you are "not a technology company" becomes harder to sustain. But part of it was also the accumulated experience of what full outsourcing actually costs when you add up all the hidden items.

The cycle will repeat, though. It already is in some sectors. New leadership arrives with fresh eyes and a mandate to cut costs. The outsourcing vendors have better pitches now, better analytics, better SLA frameworks. The business case looks cleaner than it did last time. And the organizational memory of why the previous insourcing happened has faded, because the people who lived through it have retired or moved on.

My read is that outsourcing is not a bad decision by definition. There are real cases where it makes sense, where the work is genuinely commodity-like, where the vendor can achieve economies of scale the client never could, where the transaction costs are manageable. The problem is that the decision is almost always framed as a cost question, and cost questions invite cost-accounting answers. Cost accounting is very good at capturing what you spend today. It is very bad at capturing what you will spend in three years to get your knowledge back, or what you will pay in vendor lock-in, or what you will lose in organizational capability that turns out to matter more than it looked like it would. Until the decision framework changes, the pendulum will keep swinging.