IT Procurement in the Public Sector: Where Projects Die Before They Start

The contract was signed. The project was already in trouble.

I have sat in enough kick-off meetings to recognise the pattern. The room is optimistic. The Gantt chart looks clean. And somewhere in the stack of documents on the table is a contract that was negotiated by people who will never attend a single sprint review, signed six months ago, and built on assumptions that no longer match reality.

Public sector IT procurement is one of the least discussed and most consequential parts of digital transformation. Budgets are lost here. Timelines are set in stone here. Vendor lock-in begins here. And yet most project management training treats procurement as someone else's problem — something legal and finance handle before the real work starts.

It is not someone else's problem. If you are leading a public sector IT project, you need to understand how the procurement process shapes everything that comes after it, and where the structural traps are buried.

Why public sector IT tenders are structurally biased against good outcomes

Public procurement exists for legitimate reasons: transparency, equal access, accountability for public money. I am not arguing against it. But the way IT tenders are typically structured creates incentives that actively work against successful delivery.

The first problem is the specification trap. Contracting authorities are required to define what they are buying before they buy it. For a physical good — office chairs, vehicles, paper — this is sensible. For a complex IT system, it means writing detailed functional specifications eighteen months before go-live, for a domain that will have changed by the time the ink is dry. Vendors respond to what is written, not to what was meant. Scope disputes begin before the first line of code is written.

The second problem is price as a proxy for value. Most public tenders use a weighted scoring model that includes quality criteria, but in practice, price weight is high enough that the lowest compliant bid often wins. This selects for vendors who are skilled at writing winning proposals, not necessarily at delivering working software. I have seen proposals that promised outcomes no sane engineering team could deliver in the timeframe, written beautifully, scored well, and then quietly renegotiated after contract award.

The third problem is risk transfer that does not actually transfer risk. Contracts are written to push delivery risk onto the vendor. Penalty clauses, milestone payments, acceptance criteria — all designed to protect the public body. But when a large IT programme fails, the public body absorbs the operational consequences regardless of what the contract says. Litigation takes years. The system still does not work. Citizens still cannot access the service. Legal recourse is not a delivery strategy.

What the frameworks say versus what happens in practice

The European Commission's procurement framework, and national implementations of EU directives on public procurement, do include provisions for more flexible approaches. Competitive dialogue and innovation partnerships exist precisely to allow contracting authorities to engage with the market before locking down specifications. Framework agreements allow faster call-off contracts for repeat needs. Prior market consultations are explicitly permitted.

In practice, these mechanisms are underused. Competitive dialogue is seen as administratively complex. Prior market consultations are skipped because legal teams worry about fairness challenges. Framework agreements are used, but often for the wrong things — commoditised services where price competition makes sense, rather than complex delivery where relationship and capability matter more.

The PM² methodology, which I have written about separately, sits downstream of procurement. It assumes a contract exists and a team is in place. But PM² also emphasises the importance of the Business Case and the Project Initiation phase — documents that, if written properly, force clarity on scope, assumptions, and constraints before commitment. The problem is that in many public sector projects, the Business Case is written to justify a decision already made, and the procurement specification is written to match the Business Case. The feedback loop between planning and procurement is broken.

The result is what I call inherited scope debt: a set of obligations baked into a contract that the delivery team must now manage around, rather than a set of outcomes they are genuinely empowered to achieve.

Practical things project leaders can actually do

I want to be concrete here, because the structural problems are real but they are not entirely outside your control.

Get involved before the contract is signed. If you are going to lead the delivery, push to be involved in the specification process. Review the draft tender documents. Flag requirements that are untestable, timelines that are unrealistic, and acceptance criteria that are ambiguous. You will not win every argument, but you will reduce the number of surprises you inherit.

Read the contract as a risk register. When the contract lands, do not treat it as a legal document to file away. Read it as a list of things that can go wrong. Every milestone payment clause is a potential dispute. Every deliverable definition is a potential scope argument. Map these to your risk log on day one.

Establish change management governance early. Public sector contracts rarely anticipate change well. Build a change control process with the vendor in the first month, before you need it. Agree on how scope changes are logged, assessed, and priced. The conversation is much easier before there is money on the table.

Do not let the contract define your relationship with the vendor. The contract is the floor, not the ceiling. The best public sector delivery I have been involved in happened when the client and vendor teams operated as a single delivery unit, with shared visibility on blockers, honest conversations about risk, and a shared interest in making the thing work. That does not happen automatically — it has to be built deliberately, often in the face of procurement rules that encourage arms-length relationships.

Use pilot or proof-of-concept phases wherever the framework allows. Some procurement routes, particularly for innovation or research-adjacent work, allow for phased engagement. If you can structure a small discovery or prototype phase before full commitment, do it. The information you gain is worth more than the time it costs.

The AI dimension is making this more urgent, not less

Everything I have described above applies to any IT procurement. But the arrival of AI systems in public sector projects adds a layer of complexity that most current procurement frameworks are not equipped to handle.

AI systems are not static deliverables. A language model fine-tuned on a dataset today will behave differently as the underlying model is updated, as the data drifts, as usage patterns change. Writing acceptance criteria for an AI system is genuinely hard. Defining what it means for an AI-powered document processing system to be accurate enough, fair enough, and explainable enough — in contractual language, in advance — requires a level of technical specificity that most tender processes do not support.

The EU AI Act adds regulatory requirements on top of this. High-risk AI systems used in public administration — and many will qualify — require conformity assessments, technical documentation, human oversight mechanisms, and ongoing monitoring. These are not one-time deliverables. They are operational obligations. Contracts need to reflect this, and most current public sector AI contracts do not.

I am not saying avoid AI procurement. I am saying that if you are procuring an AI system for a public body, you need procurement language that addresses model versioning, performance monitoring, explainability obligations, and regulatory compliance as ongoing responsibilities — not just features to be delivered and forgotten.

The practical takeaway

Procurement is not a gate you pass through before the project starts. It is the first phase of the project, and the decisions made in it constrain everything that follows. If you lead public sector IT delivery and you are not engaged in the procurement process, you are inheriting other people's assumptions and calling it a project plan.

The structural problems are real and not easily fixed from inside a single project. But within those constraints, there is more room to act than most project leaders use. Get in early, read the contract as risk, build the vendor relationship deliberately, and — especially for AI — make sure the contract reflects what you are actually operating, not just what you are buying.

The projects I have seen fail in procurement did not fail because the technology was wrong. They failed because the wrong questions were asked before anyone wrote a line of code. Ask the right questions earlier.