Buying a government system in a small state: what to ask before you sign

Most procurement advice is written for administrations with a project office, a test team, and an IT department. Very few small states have any of the three.

A revenue authority with sixty staff replacing its tax system is doing something structurally different from a national agency with six thousand, and the questions that protect the decision are different too.

This article sets out what to ask a supplier when the buyer is a small jurisdiction. Some of it rests on published evidence and is footnoted. The rest comes from practice, and is offered on that basis.

Why small-state procurement is a different problem

Three conditions shape it, and none of them are about budget.

The administration is small in absolute terms. An IMF review of tax administration across the Caribbean found that eight of the twenty administrations examined operated with fewer than one hundred staff in total, across every tax, every function and every process.[1] 

The IMF’s own evaluation of its work with small developing states notes that fifteen of them are microstates with populations below two hundred thousand, and that most are concentrated in the Caribbean and the Pacific, with remoteness itself affecting how support can be delivered.[2]

At that scale there is no separate implementation team. The people configuring the system are the people running the current one.

The economy moves further and faster than the project timeline. Tourism-dependent Commonwealth Caribbean countries contracted by an average of 15.4 per cent in 2020, against an emerging market average of 1.9 per cent. Small states as a group regained their 2019 level of activity only in 2023, two years after other emerging economies.[3] 

The same UK government assessment reports that around 40 per cent of small island developing states are at high risk of debt distress, a lower share than low-income countries but high relative to their income levels.[3]

A five-year commitment signed in a strong year has to survive a weak one.

Disruption is scheduled, not hypothetical. The Caribbean Catastrophe Risk Insurance Facility has made around seventy-five payouts since 2007.[4] Hurricane season is a fixed feature of the implementation calendar rather than a risk to be noted in an annex.

Against that, the general evidence on large system projects still applies. Research by McKinsey with the University of Oxford covering more than 5,400 IT projects found average overruns of 45 per cent on budget and delivery of 56 per cent less value than predicted.[5]

The questions below are the ones that address the small-state conditions specifically.

Questions about scale

Have you delivered this in a jurisdiction our size?

A reference from an administration of forty million tells you almost nothing about how a system behaves with thirty thousand registered taxpayers and sixty staff. 

The differences are not proportional. Products designed for large administrations often assume specialist roles that a small authority combines into one person, and workflows that assume volume the jurisdiction will never generate.

Ask for named implementations at comparable scale. If there are none, that is not disqualifying, but it should be priced as risk rather than treated as neutral.

Does your implementation model assume an IT department we do not have?

Many products assume the buyer can host, integrate, and provide first-line support internally. 

Ask explicitly what the supplier expects the administration to provide during implementation and afterwards, expressed in people and roles rather than in general terms.

Then compare that list against who actually exists. A gap here tends to surface as a timeline that slips before implementation properly starts.

Who trains our people, and what happens when those people leave?

In an administration of sixty, losing two staff who understand the system is a materially different event than in one of six hundred. Ask how knowledge is transferred, whether training materials remain available and current, and what retraining costs when it is needed again in three years.

Questions about conditions

What happens to the contract if implementation is interrupted by a disaster?

Ask what happens to the timeline, to milestone payments, and to any penalty regime if the country is hit during the implementation window. A supplier who has worked in the region will have an answer ready. One who has not may not have considered it.

Where does our data physically live, and under whose law?

Where a jurisdiction has no domestic facility capable of hosting a national system, this becomes a constitutional and political question rather than a technical one. The OECD lists data ownership and sovereignty among the issues digital procurement now requires governments to manage directly.[6]

Ask where data is held, which jurisdiction’s law governs it, who can compel access, and what happens if the hosting arrangement changes.

What happens when the administration changes?

An implementation of this kind will often span an electoral cycle. Ask how the supplier has handled a change of government or of departmental leadership mid-project elsewhere, and what contractual provisions exist for a pause or a change of scope.

This is a question about the supplier’s experience, not about your politics, and it should be asked in that register.

Questions about the relationship

Will we be your smallest client, and what does that mean in practice?

Worth asking plainly. What follows is a practical observation rather than a finding. It affects position in the support queue, influence over the roadmap, and whether a defect that affects only your jurisdiction is fixed at all.

A large supplier brings resilience and depth. It may also set priorities in larger markets. A smaller specialist is more likely to treat the account as significant and carries more concentration risk of its own. Neither is the safe answer, and the point is to know which risk you are accepting.

Can our legislation be configured, or does every change require you?

This matters everywhere and it matters more here, because there is no internal development capacity to fall back on. If rules live in configuration, the administration can implement a rate change itself. If they live in code, every budget cycle produces a change request, a quote, and a wait.

Ask to be shown where a rate, a threshold or an exemption is held, and who can change it.

What is the total cost across the full term, and what happens if our fiscal position deteriorates?

Not the licence. Licence, implementation, support, hosting, and the cost of a typical legislative change, across the realistic life of the system.

Given the volatility and debt exposure described above, also ask what flexibility exists if revenue falls sharply. A supplier that has worked in small states will have handled this before. The answer tells you something about the relationship you are entering.

May we speak to your clients in comparable jurisdictions, without you present?

A reference document is written by the supplier. A conversation is not. Ask specifically for small-state clients rather than the largest names on the list, and ask to speak with them unaccompanied.

The same questions apply to building it yourself

An internal build is a procurement with an internal supplier, and most of the questions survive the substitution.

Who maintains the system after the original team disperses. Whether rules are configured or coded. What happens when the two people who understand it leave. What the ten-year cost is, including maintenance, rather than the build estimate.

The IMF has noted that capacity constraints in public investment management are a serious challenge in small developing states generally.[7] That constraint does not disappear when the supplier is internal. It becomes harder to see.

What this means for a small-state procurement team

Three things follow.

Weight scale-relevant experience above scale of supplier. A supplier that has delivered three times in jurisdictions your size knows things that a larger supplier with no small-state record does not, whatever the balance sheet says.

Score what the supplier expects from you, not only what they will provide. The obligations placed on the administration are where small-state implementations most often fail, and they are usually described in a paragraph rather than scored.

Ask about interruption before you need to. Disaster, fiscal shock and change of government are ordinary features of the environment. A contract that has no answer for them has been written for somewhere else.

None of this makes a system project safe. The failure data says nothing is. It moves the difficult conversations to the point where the administration still has options, which in a small jurisdiction is a narrower window than most guidance assumes.