Why ICT Procurement Always Arrives Too Late

Introduction

In ICT procurement, timing is everything — yet it is rarely managed deliberately. In most enterprise deals, procurement gets involved after the vendor has already been informally selected, sometimes weeks or months earlier. By the time procurement is called in, the project has been scoped, the technology validated, and the working relationship already established. Procurement is brought in to finalise the contract. Not to shape it. To close it.

The commercial boundary has already been set. Pricing has been discussed informally. The vendor knows the deal is effectively done. Procurement arrives with one real lever: price. And often, not even that.

The Problem Is Not Speed

The most common explanation is organisational: procurement is slow, bureaucratic, out of step with IT’s pace. It is a convenient narrative — and almost always wrong. Procurement does not arrive late because it works poorly. It arrives late because the process is designed to bring it in late.

In many organisations, ICT procurement is activated at the final stage of the decision cycle. IT selects the technology. Finance manages the budget. A business owner holds the vendor relationship. By the time procurement is involved, all parties have already reached an informal agreement — and procurement’s role is to ratify, not to decide. The variables it could influence most — contract scope, exit clauses, long-term cost structure — have already been implicitly defined before it reaches the table.

This dynamic is most visible in multi-year renewals. In a typical case, procurement may secure an immediate saving on the annual fee by intervening at the final stage — but without being able to touch minimum commitments, price escalation mechanisms or exit clauses. Over the following 12 to 24 months, rising operational volumes and vendor dependency costs tend to absorb that initial saving entirely.

What Gets Lost by Arriving Late

The point at which procurement enters determines what it can negotiate. Arriving late does not just mean less bargaining power — it means the most consequential variables are already out of reach. Exit clauses are negotiated before signing, not after. Price revision mechanisms are built into the initial contract structure. Data portability, lock-in penalties, minimum commitments — all of these are defined when the vendor still has an incentive to close the deal. Once signed, any change requires a renegotiation in which the starting position is already one of disadvantage.

As shown in the analysis on ICT TCO procurement, the declared cost perimeter at signing covers on average less than half the real lifecycle cost of the contract. The remainder — governance, exit costs, operational dependency — solidifies in the months that follow, when procurement no longer has a seat at the table.

In complex cloud contracts, the costs that escape governance rarely surface at signing. They emerge in subsequent quarters, once architectural and operational decisions have hardened and changing them carries a real price. This is precisely why Total Cost of Ownership frameworks increasingly focus not on initial price but on lifecycle costs, governance burden and operational evolution — as documented in Gartner’s analysis on TCO principles in enterprise cost models.

The Cost of Structural Lateness

There is a second problem, less visible than the first. When procurement systematically arrives late, it stops accumulating the knowledge it would need to arrive earlier next time. Those absent from the technology evaluation phase never fully understand why certain choices were made, which technical constraints drove the selection, or which alternatives were ruled out and why. Their contribution remains confined to the final negotiation — and a final negotiation without context produces limited results.

This follows the same logic explored in the article on the assumptions behind ICT decisions: the problem is not that the assumptions are wrong. It is that the people who should challenge them are not in the room when they are made.

When Procurement Can Still Change Something

The useful window is not at renewal — by then lock-in has matured and alternatives are expensive. The useful window is in the 60 to 90 days before the technology evaluation is finalised. At that point, the vendor does not yet hold a consolidated position, options are still real, and contract clauses can still be shaped without contextual cost. Opening that window requires just one thing: knowing when it opens.

This is not a technical problem — it is a visibility problem. Procurement teams with access to IT’s technology roadmap, even in summary form, can anticipate the right moment to engage. Those without it wait to be called. The Contract Renewal Planner was built precisely for this: not to manage renewals as they arrive, but to structure contract timelines in advance — with visibility on contracts expiring within 90 days, the rigidity cost of each, and the saving potential available before the window closes. Procurement working with this tool does not wait to be called. It knows when to sit down at the table.

How to Change the Entry Point

There is no single organisational fix — it depends on the company’s structure and the relationship between procurement and IT. But two levers work regardless of context. The first is early visibility. ICT procurement needs access — even informally — to technology conversations before they become purchase requests. A quarterly meeting with IT to review the roadmap for the next six to twelve months is enough to identify when to open contract files. The real value of those meetings is not reviewing active contracts, but picking up early signals: workloads in migration, new SaaS projects, anticipated licence increases, infrastructure renewals, or planned architectural changes. Even a high-level roadmap is enough to know which files to open before the negotiation is already implicitly closed.

The second lever is assumption documentation. Every technology evaluation rests on implicit assumptions — adoption rates, volumes, effective duration. As explored in the vendor lock-in analysis, dependency consolidates well before signing. When procurement helps make those assumptions explicit and verifiable from the outset, its role shifts from bureaucratic to analytical — a distinction the CFO notices, and one that changes procurement’s weight in the decision-making process.

Procurement Arrives Late for as Long as the Process Allows It

Late ICT procurement is not a skills problem or a speed problem. It is a process architecture problem. As long as technology is selected by one party and purchased by another, procurement will always operate downstream of the variables that matter most. Changing this requires one thing: getting in earlier. Not to control technology decisions — that is not procurement’s role — but to be present when the economic conditions of the contract are still being shaped by the buyer, not the seller.

Written by

Domenico Monteleone

ICT & Cloud Buyer

I connect data, contracts and operations to make decisions clearer.

See how I work LinkedIn