The End of the Big IT Services Contract?

Why AI Demands a Different Technology Delivery Model

For decades, the economics of IT services have been remarkably straightforward. Organisations identified a significant technology requirement, procured a large supplier, assembled sizeable teams of software engineers and other specialists, and paid for those teams over several years to design, build, integrate and maintain a solution. The model created an enormous global IT services industry, but it rested on an important economic assumption: producing software required large quantities of skilled human labour. Artificial intelligence is rapidly undermining that assumption. It does not mean that software engineers are no longer required, nor that AI can autonomously deliver complex enterprise systems. It does mean that an increasing proportion of the repetitive work on which traditional IT services economics depend – generating code, creating tests, producing documentation, refactoring, debugging, migration scripts and routine configuration – can now be substantially accelerated by AI-assisted engineering. If the underlying unit economics of software production are changing this quickly, organisations should question whether buying technology services through large, labour-intensive, multi-year contracts still makes sense.

The productivity evidence is increasingly difficult to ignore. An early controlled experiment by Microsoft Research found that developers using GitHub Copilot completed a defined programming task 55.8% faster. More significantly for enterprise buyers, later randomised field experiments involving 4,867 developers at Microsoft, Accenture and another Fortune 100 company found that developers with access to AI coding assistance completed approximately 26% more tasks. These figures should not be interpreted as universal productivity multipliers: software development differs enormously according to task, environment and developer experience. Nevertheless, they demonstrate that the amount of human engineering effort required for a given quantity of software is beginning to change materially.

BharatRajya shows that domain expertise can now substitute for much of the traditional entry-level engineering barrier. An amateur historian with an idea but no professional coding background built a sophisticated interactive historical platform using generative AI. Similarly, two founders with no coding experience built 3AK, a track and field application in under two weeks for a cost of $500 generating revenue of $70k within 6 months. At the commercial end of the spectrum, non-technical founders are now using tools such as Claude, Cursor and Replit to take functioning applications from idea to market in weeks rather than assembling conventional development teams. The implication for enterprise IT is not that professional engineering has become unnecessary, but that the economic premium is moving away from the production of code towards understanding the problem, designing the product, architecting the system, integrating it safely and assuring its security.

The most revealing evidence may be what happens after the code is written. NBER research published in 2026, based on more than 500,000 developers, found that increasingly autonomous coding tools were associated with a cumulative 240% increase in commits, but the productivity effect diminished substantially as work moved through the delivery system – to around 80% at project level and approximately 30% for releases. That is an important distinction. AI can generate software increasingly quickly; organisations cannot necessarily decide what should be built, integrate it into complicated estates, assure it, secure it and release it at anything like the same speed. The implication is profound: code is becoming cheaper, but coherent technology change is not.

That should fundamentally alter what organisations purchase from technology suppliers. Rather than primarily acquiring engineering capacity, they increasingly need four capabilities around which engineering can be organised: product design, enterprise architecture, integration and security. Product design establishes whether the organisation is solving the right problem and whether the resulting service creates measurable value for users. Enterprise architecture ensures that rapidly produced software fits into the wider technology and data estate rather than becoming tomorrow’s technical debt. Integration becomes more important precisely because creating new applications is becoming easier; an organisation capable of creating dozens of new AI-enabled services but unable to connect them reliably to identity, payments, data, workflow and legacy platforms has merely generated a larger integration problem. Security and assurance similarly need to move upstream because an environment in which software can be generated and changed continuously requires security controls, automated testing, observability and governance capable of operating at comparable speed.

When productivity and the commercial model point in opposite directions

There is another, less discussed problem with the traditional IT services model. Large, long-duration contracts can create a structural tension between technology innovation and supplier economics. Many traditional engagements are priced, explicitly or implicitly, around anticipated volumes of people, effort and delivery activity. Suppliers recruit teams, make utilisation commitments, agree subcontractor arrangements and forecast revenue on that basis. If an innovation suddenly enables the same output to be produced with 30%, 50% or eventually even less engineering effort, adopting it immediately may be unquestionably beneficial to the client while simultaneously reducing the supplier’s revenue or leaving committed resources underutilised.

This is not an accusation that suppliers deliberately suppress innovation. It is a consequence of contract design. A supplier operating rationally against a five-year commercial commitment cannot always behave as though the contract is being competitively awarded again each month. Investments, staffing, margins and delivery obligations have already been established. The incumbent therefore has weaker economic incentives to introduce innovations that cannibalise its own existing revenue than a challenger trying to win the work afresh. Long contracts can consequently lock in not just technologies but the productivity assumptions that existed when the contract was signed.

The National Audit Office’s recent review of government’s approach to technology suppliers provides useful supporting evidence. It found that government contracting mechanisms and pricing structures can constrain suppliers’ ability to apply their expertise and that overly prescriptive commitments can inhibit innovative solutions. It also argued that traditional procurement and business-case processes do not fit digital programmes particularly well, where the eventual technical solution may not be fully understood at the point at which funding and contracts are agreed. The commercial problem becomes particularly acute during periods of very rapid technological change: the buyer wants every productivity breakthrough passed through immediately as lower cost or faster delivery, while the incumbent’s contract may have been constructed around precisely the resources those breakthroughs eliminate.

A technology buyer should therefore be asking a very different question from the one traditionally asked of IT services firms: what is the smallest expert team capable of producing the required outcome using the best technology currently available? The supplier should benefit when it discovers a dramatically better way of delivering the outcome, rather than only when it deploys more people. Outcome-based pricing, gain-sharing and shorter commercial cycles can help align these incentives. Suppliers can still make attractive returns, but those returns increasingly need to come from intellectual leverage, specialist expertise, reusable capability and measurable outcomes rather than simply the scale of the delivery workforce.

The UK government technology paradox: Shorter technology cycles v longer contracts

The issue is particularly important for UK central government as it faces challenging economic and fiscal situation. There is an interesting tension between a decade-old policy instinct towards smaller technology contracts and the scale of today’s largest technology programmes. In 2014, government procurement policy explicitly stated that an IT contract should not exceed £100 million except in exceptional circumstances, explaining that smaller contracts allowed competition from the widest possible range of suppliers. The logic was partly about competition and SME participation, but in the AI era there is an equally powerful argument around adaptability.

The historic direction was visible in organisations such as HMRC and DVLA. HMRC reported replacing its large, outsourced IT arrangements with a series of smaller, more flexible contracts, saying that the approach generated more than £100 million of savings in 2017-18. DVLA similarly moved away from a large-scale outsourcing arrangement and subsequently cited reduced consultancy and technology costs among its savings. These examples are significant because they demonstrated that disaggregation need not simply mean fragmentation; with sufficient internal capability, government can retain control of architecture and integration while sourcing specialist components externally.

Recent major-project figures, however, point in another direction at the top end of the market. In the 2023-24 Government Major Projects Portfolio, there were 26 ICT projects with total whole-life costs of approximately £26 billion, equivalent to an average of around £1.0 billion per project, with an average duration of 8.5 years. In 2024-25, 24 ICT projects carried a combined whole-life cost of £36 billion, approximately £1.5 billion per project. By 2025-26, the portfolio contained only 22 ICT projects, yet their combined whole-life cost had reached £42.5 billion – approximately £1.93 billion per project – and average expected duration had increased to 10.7 years.

These are projects rather than individual supplier contracts, and the composition of the portfolio changes each year, so the figures should not be presented as evidence that the price of an equivalent IT contract has doubled. Nonetheless, they expose an important structural question. Government’s largest technology undertakings are becoming extraordinarily large and long-lived at precisely the moment when the technologies and engineering economics underpinning them are changing faster than at any point in recent memory. A technology programme expected to operate for more than three years, let alone five, will almost certainly encounter capabilities that could not realistically have been specified when its commercial arrangements were first designed.

The longer historical picture is not a straight line. In 2016-17 the major-project portfolio contained 39 ICT projects worth £18.6 billion, an average of roughly £477 million, while in 2020-21 there were 25 projects worth £14 billion, averaging about £560 million. By 2025-26, the average had risen to around £1.93 billion. This does not prove that comparable IT contracts have simply quadrupled in price; the portfolio changes over time. But it does underline the growing scale of the government’s largest technology commitments at a time when the economic life of technology assumptions is shortening.

The Home Office provides a useful contemporary illustration of the scale issue. It has described centralised digital contracts of approximately £80 million for software engineering, £40 million for DevOps, £40 million for technical architecture and £5 million for user-centred design, within centralised arrangements totalling around £200 million. The department itself acknowledged that contracts of this size can be difficult for SMEs because they lack the staffing numbers required to compete. This matters because some of the organisations most capable of exploiting technological discontinuity may be specialist firms rather than large incumbent suppliers.

Why smaller contracts matter more when technology changes faster

Large technology contracts have traditionally been justified through economies of scale, simplified accountability and reduced integration complexity. Those advantages are genuine. But large commitments also create an increasingly significant form of technology-option risk. A five- or ten-year contract crystallises assumptions about technology, delivery models, staffing levels, skills and costs. During that period foundation models will improve, AI agents will mature, development platforms will change, cloud pricing will move and entire categories of engineering activity may become commoditised.

Smaller and shorter contracts preserve options. They reduce the amount of technical and commercial risk committed at each decision point, expose suppliers repeatedly to competitive pressure, allow new specialists to enter the supply chain and provide regular opportunities to incorporate productivity improvements into pricing. If AI makes a class of software development twice as efficient three years after a ten-year contract has been signed, the buyer should ideally capture that gain. A shorter commercial cycle makes that much more likely.

There is, however, an important qualification. Breaking a large contract into twenty smaller contracts does not automatically create a better technology estate. The National Audit Office has warned that government has sometimes struggled to integrate multiple disaggregated contracts into coherent services and that doing so requires strong specialist integration capability. That is precisely why the capabilities retained by the organisation become so important. Disaggregate execution, but do not outsource coherence.

Government and large enterprises therefore need to own the product strategy, enterprise architecture, security model, data architecture, integration standards and technology roadmap. Specialist suppliers can then compete to deliver bounded outcomes within that architecture. The organisation owns the blueprint and the interfaces; suppliers build, operate and improve components of it. That is very different from outsourcing the problem, architecture, engineering capability and institutional knowledge to a single prime contractor.

The next generation of technology delivery should consequently look less like traditional outsourcing and more like a managed ecosystem. A relatively small internal capability owns product direction, architecture, integration and security. Specialist suppliers contribute expertise through shorter, modular engagements. AI-enabled engineering teams build software with dramatically greater leverage. Platforms, APIs, automated testing and security controls enable multiple teams to operate safely, while commercial arrangements are regularly refreshed so that falling technology costs flow through to the buyer.

The biggest mistake organisations could make in the AI era is simply to insert AI into the existing consultancy model and declare victory. The larger opportunity is to redesign the commercial model itself. If software production is becoming cheaper and faster, buyers should not continue procuring technology as though engineering capacity were permanently scarce and code permanently expensive. They should spend less on armies of people producing software and more on the judgment required to decide what should be built, how it fits together, how it connects, and how it remains secure. The winning technology organisation will not be the one with the largest delivery programme. It will be the one that can absorb technological change quickly, change direction economically and convert rapidly improving engineering productivity into organisational value.

References