Tag: public-sector

This article is part of a series about large-scale, collective, public-sector procurement. It is written mainly for the technical and managerial people responsible for these procurements. The overall aim of the series is to describe the obstacles in the way, and show how to overcome them. It uses laptops as an example, but the same ideas could apply to other categories.

A previous article set out the scaffolding of the topic, in six parts. This part is the second: about the broader user needs that apply in a procurement. It comes after we consider the technical requirements; and before we take on the legal constraints, the problems of collective action, the economic case, and the organisational arrangements to make it all come together successfully.

We all know that a requirement should be based on a real user or business need. A requirement might be for a Secured-core PC, but that would be to meet the user need for what the NCSC describes as “enhanced protection”. The Government Digital Service (GDS) way is to be explicit about user needs, to avoid requirements that are only a regurgitation of specifications. In my experience, organisations usually have a good implicit understanding of their user needs. But making those explicit allows them to be challenged and perhaps modified if there is a better way to meet the need.

I use a form to document the user needs:

Index	In my role as	I need	So that
A2	Knowledge worker	A reasonably portable laptop	I can carry it comfortably between home and office, and occasionally elsewhere
A6	Knowledge worker	A device that connects to power and display over a common connector	I do not have to carry a charger, cables and adapters
B2	Cyber security manager	An inventory of all devices and their user	We comply with the NCSC Cyber Assessment Framework
B4	Cyber security manager	Control of all telemetry data	It remains in a known jurisdiction
C1	Digital workplace service owner	A standard device and OS configuration	Support costs are kept down
C3	Digital workplace service owner	A clean OS image from the OEM	I do not have to re-image the device before configuring it
D1	Line manager	A device issued promptly to a new joiner	They can start work immediately
D7	Finance manager	To procure devices in Q4	I can use the remaining budget

We can debate what the correct user need is, but only because we have made it explicit.

When we do this, we raise to the surface some very important considerations that may not be obvious to an outsider looking at the technical specification of the device alone.

In my experience, most end-user computing (or digital workplace) service owners want to achieve a degree of standardisation in the service they provide to staff. This is evident in many ways:

• The same videoconferencing equipment in meeting rooms
• A list of approved software
• A standard configuration of the device, using device configuration profiles
• A single user identity for different services
• Etc.

Another standardisation is in the make and model of devices: laptops, phones, monitors. The service is easier to provide well and cost-effectively when the devices are standardised.

A crude version of this is the mass fleet replacement on a multi-year cycle. The devices start out all the same, and we top up with the same or similar model during this version of the desktop service.

With an evergreen Windows OS (well, almost!) and applications, the mass fleet replacement has become less common, and a rolling programme of replacement more common. But, if we now do that, how do we keep the devices reasonably standard over an extended period? If we use a product-neutral requirement to achieve the best value, the risk is that we will obtain a different device from each contract.

A brave manager might decide that standardisation is overrated; and that the organisation could work perfectly well with a selection of different devices. But I am uncomfortable with this idea of changing the business need to suit the procurement. For the moment, I think the procurement should meet the need, although by all means an organisation could experiment.

Mainstream business-grade laptop models generally have a 12–18 month lifecycle, driven largely by the lifecycle of the processor models they use. During that lifecycle, the OEM generally keeps the chassis and component specification the same. The next-generation model will generally (not always) be an evolution, with a similar chassis and updated components.

To maintain a degree of standardisation, we need to keep the same model, or at least the same type of model, for as long as possible.

But we will not want to buy the whole quantity at once and put them into stock. If we do that, the OS and firmware will be out-of-date by the time we take a device from stock to use it. So we will want them supplied as needed, direct from the manufacturer or distributor.

To meet the user need for standardisation, we will need to:

• Buy early in the model lifecycle
• Commit to buying the same model over an agreed period, rather than holding the whole quantity in stock
• Create a contractual framework for the next-generation upgrade.

This might sound unnecessarily complex, but the alternatives are:

• A spot purchase of a different model at different times
• Abandoning the product-neutral requirements altogether.

So I think we can see that making the user needs explicit helps us to discuss, between the commercial, technical and other interests, how best to meet them and what the resulting procurement looks like. And, in doing so, we discover that we are not really buying laptops at all. We are buying a reliable supply of laptops.

Next: the rules of the game.

This article is part of a series about large-scale, collective, public-sector procurement. It is written mainly for the technical and managerial people responsible for these procurements. The overall aim of the series is to describe the obstacles in the way, and show how to overcome them. It uses laptops as an example, but the same ideas could apply to other categories.

A previous article set out the scaffolding of the topic, in six parts. This part is the first: how to express the technical requirements for any large, competitive procurement. This is before we bring in other considerations, including broader organisational needs, the constraints of public-sector procurement and the added complexity of collective action.

Why do we even need an article about requirements? Surely organisations are well-practiced in buying laptops. They must know what their requirements are. And indeed they do: organisations already make statements of requirements and use them to conduct procurements. But these requirements may not be as open and competitive as they could be. The reason is that expressing a requirement in a way that permits the widest possible competition is a considerably more difficult task than it first appears.

I start with the assumption that we want to achieve the best possible value, and that this is most likely to be achieved by making the procurement open to as many sellers as possible, with as wide a range of products as possible, provided they meet our requirements. So this article is about how to express the requirements for this competition.

Let’s imagine as a starting point that I have a selection of laptops, with different specifications, for evaluation. From these I have selected one that is the best fit for the organisation. I have the full specification for it, and a rough idea of the price, which I think is acceptable. I am hoping to be offered a substantial discount for contracting to buy a large quantity. I could just look for tenders from different resellers for this specific model, but I think I may get even better value if I open the competition to similar models from different manufacturers. So the next step is to remove the manufacturer and model from my requirements, and consider only the important properties of the model.

With this in mind, I might come up with something like:

• Laptop form factor
• Intel Core 5 320 processor
• 14″ screen size
• WUXGA display
• 16 GB RAM
• 512 GB SSD
• Windows Pro Edition.

I need to use a specific example here, but this article is not about choosing a good laptop. It is about the logical development of a set of requirements for whatever laptop we think we want to buy.

But if I issue these as the requirements for an open procurement, I am saying in effect that I will accept the lowest possible specification meeting these, and only these, requirements. Any manufacturer, including those I know less well, could offer any product provided it meets only these criteria, and I would be obliged (though perhaps not legally contracted) to accept it.

When I look at the model specification, I can see that there are many more variables. Am I really saying I care about none of them: battery life; hard drive speed; Wi-Fi performance; physical connectors; camera quality? Manufacturers have spent a great deal of time and money offering customers options. On what basis would I decide they are all irrelevant and that I will accept the lowest possible offering except for the few I have specified?

So Rule No. 1 is that the statement of requirements must be complete. It must include everything we care about, and not just the things we care about the most. This is a matter of logic. The requirements do not only need to include what we want. They need to exclude anything that we do not want, even if we do not know what it might be.

If we take a single model, from a single manufacturer, there may be, conservatively, more than 45,000 technical configurations. This may seem like a high number, but these exist because different buyers want different things, and each of these represents a difference in price. As a result, if we want to achieve the best value for a given requirement, we need to state the minimum requirement for each of the variables, which may include:

• Operating system edition
• Processor manufacturer
• Processor variant
• Display properties
• Storage capacity
• Memory type
• Memory capacity
• WLAN version
• WWAN capability
• NFC capability
• Camera features
• Fingerprint capability
• Keyboard type
• Smartcard capability
• Power supply capability
• Battery capacity.

But this is for one specific manufacturer and model. If we want to extend this to other manufacturers and models, we need to accommodate the differences in their design choices. This is Rule No. 2. We need the requirements to be generic, or product neutral.

The most obvious example is the processor. In our initial requirements we gave Intel as the manufacturer and Core 5 320 as the model. But AMD and Qualcomm also make processors for Windows laptops. If we want the most open competition, we should allow these too. The most obvious way to do this is to say “or equivalent”. That seems reasonable. But equivalent in what respect: cores; frequency; efficiency (power consumption); features? Intel, AMD and Qualcomm make processors to compete, not to compare. There is no single measure of equivalence. They have different manufacturing economics, and different competitive positioning. They even run different Windows binaries, compiled for x64 (Intel and AMD) or Arm64 (Qualcomm).

The solution to this conundrum is that we need to use a generic, or product-neutral, measurement of processor performance. Now the pool of complexity gets deeper. How do we measure performance? Surely there must be some sort of industry standard? There is not. There is a range of different types of benchmarking software. Some run synthetic tests designed to stress individual components. Others run real applications with a simulated test workload. But getting repeatable results depends on using very carefully controlled test conditions. To use a benchmark score in a competitive procurement, we would need to specify what benchmarking software to use, under precise test conditions. Both the buyer and the seller would need to be able to run the same test: the seller to know what to offer, and the buyer to verify that what is offered meets the requirement.

So finally we might come to the conclusion that we should use application benchmarking software, for example SYSmark from BAPCo or Procyon from UL Solutions. We will also need to set up our own bench so that we can produce the scores that we set as a requirement, and verify the performance of the products we are offered.

This is a topic all on its own, and it covers only the processor. We also need to consider battery choices. Battery life (the runtime between charges) is a combination of many factors: the capacity of the battery itself, in Watt-hours; the workload, such as browsing, or playing video, or performing calculations; the efficiency of the overall platform; and software optimisation, to reduce performance or screen brightness when there is less charge. We need a benchmark for this too. And this is only battery life. We also need to consider the charging rate and the longevity, both of which may be described by manufacturers in different terms. And the weight of the battery will be a significant part of the overall weight, so better battery performance may tip the device over an acceptable weight limit. So we need our bench again to test the overall weight of models with different options.

Next, manufacturers are not obliged to follow the same conventions. Many typical laptop displays, for example, follow a WUXGA convention with 1920 x 1200 pixels. But they don’t need to do that. Microsoft and Apple both use a different display format. Can we honestly say that only WUXGA meets our requirement? Displays also come with different levels of brightness and contrast. Do we want the lowest specification; or something better?

And then we have more variation. IPS is In-Plane Switching, which achieves a wide viewing angle with accurate colour rendition. But IPS is only one of several technologies that may be used to achieve this. Really we want to specify the viewing characteristics, not the technology. How do we do that? We might specify the viewing angle over which contrast is greater than 10%. Some displays are described as “low blue light” while others have “Eyesafe” or “Eye Comfort” certifications. But neither Apple nor Microsoft use these terms, so do we really need them at all? Yet another characteristic is viewing privacy. A narrow field of view for security purposes can be achieved in hardware or in software. Is one better than the other? How can we describe it? And so on. For every property, we need to consider what our requirement is, and how to express it in a generic or product neutral way.

Then we come to Rule No. 3. Requirements are only useful if we can verify whether they are met. We have to imagine a seller who simply says “yes” to every requirement. How do we check? We already saw, above, that “equivalent” is not a verifiable property of a processor. Another good example of this is what we might call a business or enterprise laptop. We know what we mean: not the same as the laptop we might buy in a shop. But what exactly is the difference? We might think it is more durable. But how would we define that? We might specify a metal rather than plastic chassis. But most chassis are not pure metal. They are a combination of metal skin with reinforcements. And some are made of high-tech resin and fibre composites. In the end, we cannot use business or enterprise as a requirement, because we cannot verify it. Instead we may choose to use measurable and verifiable properties, such as:

• Battery longevity
• SSD longevity
• Scratch and dent resistance
• Drop, shock and spill resistance.

Back to the completeness rule. It may not even be possible to define everything we think we require, and therefore rule out any possible offer that we had not expected. We cannot know every configuration of every model from every manufacturer. We might choose to use some characteristics as a proxy for other attributes. But the bigger the procurement, the more important it is to control the outcome.

I hope I have done enough to show that what starts out as a simple enough requirement – “I’d like something like this” – needs to become as complete, product-neutral and verifiable as possible. We can never achieve this perfectly, because we cannot know every possible product. But the larger and more competitive the procurement, the harder we need to try.

Next: user needs.

This article is about large-scale, collective, public-sector procurement. It is written mainly for the technical and managerial people responsible for these procurements. The aim is to describe the obstacles in the way, and show how to overcome them. It uses laptops as an example, but the same ideas could apply to other categories.

We start with the proposition that a buyer should be able to achieve better value with a larger volume of goods procured. Most people would think that self-evident. It is how a supermarket works. In the public sector, organisations vary greatly in size. We might assume that the larger organisations achieve, or could achieve, better value than smaller ones. Therefore we might assume that smaller organisations might also achieve better value if they procured goods collectively. And we can go on from there to assume that a collective of smaller organisations might achieve even better value if it joined forces with larger organisations.

It is obvious that this might apply, for example, to schools, NHS Trusts, local authorities and police forces. By extension the same approach might also apply to universities and charities. If it were adopted across the whole of the public sector, and across a range of product categories, then we might expect to achieve better value worth hundreds of millions of pounds a year.

But, if it is so obvious, why do we not already do it? Could it be, for example, that public-sector organisations value their autonomy more highly than the potential savings from a collective procurement? Or perhaps they have tried and it didn’t work. Or perhaps the assumption is wrong and larger organisations are not paying appreciably less than smaller and more nimble ones.

This article proposes that none of those is a sufficient explanation. Organisations do collaborate, for example through the Government Property Agency. They have tried collective procurement, successfully, in Scotland. And larger organisations do, by and large, obtain lower prices than smaller ones. Instead, the article sets out a case that achieving better value through collective public-sector procurement is much more demanding than it might first seem. It concludes that better value is achievable, but only by recognising and overcoming the obstacles.

The article only erects the scaffolding of the case. I have found that each part explodes into hidden complexity, so I have chosen to cover each part of the argument as a separate topic. Does it need to be so complex? The tidy mind dislikes complexity and tries to reduce it to simple propositions. But simple propositions can hide immense complexity. Each topic starts with a simple proposition and develops it into the necessarily more complex solution.

The first topic is the expression of the requirement. It seems simple enough to buy a laptop. Most of us have done it. Can’t we just scale that up a bit? That is, in fact, mostly what happens. Many organisations currently express their technical requirement in a few lines. Even large ones may use a spreadsheet with only 10-20 lines (although the full tender document is much larger, of course). But these are not open procurements. For the most competitive procurement, open to any seller, we need to be able to accept any solution that meets the requirements, even a solution we do not yet know of, and exclude only those that do not. This makes expressing the requirements accurately a considerably more demanding task.

The second topic is user needs. As a private individual, I can assert my requirement to be whatever I please. But a commercial buyer is trying to provide goods that will meet the overall needs of the organisation. Usually these needs are implicit, but I find it a good discipline to express them explicitly. When doing that, it becomes apparent that there are requirements beyond the technical specification of the laptop alone. Most organisations want to achieve not just a delivery of laptops, but a supply of laptops into a provisioning and support service. They might, for example, want to buy a model of laptop early in its 12-18 month lifecycle, so that the same model can be supplied for the longest period of time. These user needs also need to be expressed as requirements.

Next are the rules of the game. A public-sector buyer is constrained by statute: the Procurement Act 2023, supplemented by the Procurement Regulations 2024, and elaborated in guidance from the Cabinet Office. This is well known, but nevertheless stranger than it first appears. The State has created a legal regime such that a seller may sue a public body if the rules are not followed. In some cases the procurement may need to be run again. In others, the organisation might find itself paying damages and subject to public criticism. So the procurement needs to take account of the additional constraints imposed on it by law.

Next is the question of collective buying. If specifying the requirements of an organisation is not straightforward, then doing it collectively adds a further degree of difficulty. Even when organisations want to cooperate, they may have different requirements. Those differences may be necessary, or they may be historic. It might take time for an organisation to adapt to a new type of procurement. But, if a collective cannot demonstrate that it achieves better value at the outset, why should people join it? So there is a collective action problem, and we need a plan to deal with it.

Then there is the economic case. The question is: does it really follow that significantly better value would be achieved by collective procurement? If we knew that the margins of the industry were low, where would the better value come from? Conversely, unless there is a significant advantage for the seller, why would they sell for less? There are further more complicated arguments about security of supply, innovation, and market behaviour. In brief, we need to be able to demonstrate that there is an economic case for collective procurement, rather than assume that economies of scale will produce better value.

These are the substantive topics. Beyond this is a question about the nature of large-scale, collective, public-sector action and its limitations. If the problem is difficult but solvable, why do organisations, from health trusts to police forces, find it so difficult to do? The individual organisations may understand their own requirements very well. The difficulty may instead lie at the centre: how does an organisation recognise and make use of knowledge that it does not itself possess? This leads to a consideration of the organisational structures needed to make collective procurement work.

Next: the expression of the requirements.