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 third: about the legal constraints that apply to a public sector procurement. This is after we consider the technical requirements and the broader user needs; and before we take on the problems of collective action, the economic case, and the organisational arrangements to make it all come together successfully.
A procurement is a competition between sellers to win a contract to supply something. Competitions usually take place under a set of rules. In our case, unlike a private-sector procurement, the rules are set by legislation. This has a powerful effect. When you are preparing the requirements, you need to think, not “will I be able to explain this to my team?”, but “will I be able to justify this in court?”, and what are the consequences if I get it wrong.
The rules of the game are in three places:
- Primary legislation in the Procurement Act 2023
- Secondary legislation contained in the Procurement Regulations 2024
- Guidance from the Cabinet Office.
This article is not going to cover the ins and outs of the legislation. Instead, it will focus on the main elements that affect the way we develop the requirements for this type of large-scale procurement.
You might assume the rules are set up to protect the interests of the organiser of the competition (the public-sector body as buyer or “contracting authority”). But that is not the case. In many ways, the rules are set up to protect suppliers. The legal framework places additional obligations on the buyer, not the supplier.
We already determined that, to achieve the best value, we should express our requirements in as open, or product-neutral, a way as possible. We want to try to get behind the marketing terms, or the different technologies a manufacturer may use to achieve a performance or functional characteristic. But the obligation goes considerably further than this:
- Firstly, we must allow all suppliers to compete fairly
- Secondly, we must express requirements in a certain way, and may not express them in others.
These two factors lead us to a way of working that I will come on to at the end.
Fairness
Section 12.1(c) ” In carrying out a covered procurement, a contracting authority must have regard to the importance of….sharing information for the purpose of allowing suppliers and others to understand the authority’s procurement policies and decisions”.
This creates a duty towards suppliers. But I wonder how far we are expected to go in allowing a supplier to understand something. That seems quite open-ended. Suppose they don’t want to understand it because it is to their advantage not to.
Section 12.2 “In carrying out a covered procurement, a contracting authority must treat suppliers the same unless a difference between the suppliers justifies different treatment.”, and 12.3 “If a contracting authority considers that different treatment is justified in a particular case, the authority must take all reasonable steps to ensure it does not put a supplier at an unfair advantage or disadvantage.”
So we need to treat all suppliers the same; but we may not yet know who they all are. How can we then treat them all the same? We would need either to engage with all of them, or with none of them. I can see the sense of this once a formal procurement has opened, but it seems very difficult to do before that.
The Act says that we may carry out a “preliminary market engagement” with suppliers.
Section 16.1 “Before publishing a tender notice in respect of a public contract, a contracting authority may engage with suppliers and other persons for the purpose of—
(a) developing the authority’s requirements and approach to the procurement;
(b) designing a procedure, conditions of participation or award criteria;
(c) preparing the tender notice and associated tender documents;
(d) identifying suppliers that may be able to supply the goods, services or works required;
(e) identifying likely contractual terms;
(f) building capacity among suppliers in relation to the contract being awarded.”
This makes obvious sense if we decide to buy something out of the blue. We investigate the market, identify suppliers, and open a competition. But an organisation buys laptops year in and year out. It has established relationships with existing and potential suppliers. The relationship may include, for example:
- Attending new product launch events
- Evaluating new products
- Asking questions about new product features
- Discussing different procurement models.
How are we to do this with all potential suppliers equally? If we cannot, how are we to balance it up to make sure that there is no unfair advantage to the suppliers we engage the most with? And why should they engage with us, if the advantage they gain by doing so must be removed in the procurement?
This all sounds as though it should be a code of practice, “as far as is practical and proportionate”. But it is not. It is a legal obligation.
And what does “unfair advantage or disadvantage” even mean? Suppose I learn that one manufacturer can embed a certificate in a device to verify that the components of the laptop have not been altered since manufacture. Suppose I think that is a very good idea, to combat the heightened risk of tampering, and I add it to my requirements. Suppose then that another manufacturer tells me they don’t do that, and for a good reason. Are they unfairly disadvantaged? They might say: you have been listening to Supplier X but you have no evidence this is an effective solution. Instead we use another mechanism to ensure there is no tampering. What then?
Technical specifications
Section 56 Technical Specifications covers the terms we may use to define our requirements.
Section 56.2 says: “The procurement documents may not refer to design, a particular licensing model or a description of characteristics in circumstances where they could appropriately refer to performance or functional requirements.”
Section 56.7 adds: “Unless the contracting authority considers it necessary in order to make its requirements understood, the procurement documents may not refer to a particular—(a) trademark, trade name, patent, design or type, (b) place of origin, or (c) producer or supplier.”
Section 57.8 adds: “If the matters mentioned in subsection (7) are referred to, the procurement documents must also provide that tenders, proposals or applications demonstrating equivalent quality or performance will not be disadvantaged.”
This sounds reasonable enough if it were a code of practice. It corresponds to our earlier conclusion that we should express requirements in as product-neutral a way as possible. But this is a legal requirement, not guidance.
So let’s list some of the properties used by manufacturers to describe a laptop:
- Laptop
- Clamshell
- Processor make and model (e.g. Intel Core 5)
- Thunderbolt
- Touchpad
- TPM
- WUXGA, PixelSense or Liquid Retina
- LCD panel
- Touch screen
- Anti-glare
- Low blue light
- HDMI
- DisplayPort
- SSD
- DDR5
- Wi-Fi 7
- HDR camera
- Long life battery
- Fingerprint reader
- Backlit and spill-resistant keyboard
- MIL-STD-810H.
We know what these are, but would you like to try to express them as performance or functional requirements, as the Statute says we should? It is quite a challenge. So, as the contracting authority, we have a problem. We may not use terms that everyone understands, if they could instead be given as performance or functional requirements. We must also accept an “equivalent” product. But, unless we can define the performance or functional characteristic, how can we know if it is equivalent or not?
Subsections 3-6, and 9, cover the use of standards. They refer to:
- UK standards
- Internationally-recognised standards
- Equivalent standards from another state.
For standards set by national and international standards bodies, such as ANSI, ISO and IEC, or the International Bureau of Weights and Measures, the meaning is clear. But, at least for technology, many standards are set either by industry associations, independent third parties, or government agencies. There are often several organisations covering similar ground. Is a specification developed by a U.S. not-for-profit organisation like the Trusted Computing Group (TCG) an “internationally-recognised” standard, or not?
The solution is to unbundle each of these terms into what we actually require, in performance or functional terms, and what we can verify. We saw this in the previous article about requirements. This is an example for the display: first the manufacturer’s description; then the product-neutral requirement.
Specification
| Item | Specification |
| Size | 14″ diagonal |
| Aspect ratio | 16:10 |
| Resolution | WUXGA (1920×1200) |
| Touch | On-cell touch |
| Type | LCD |
| Brightness | 400 nits |
| Contrast | 800:1 |
| Colour gamut | 100% sRGB |
| Viewing angle | Ultra-wide |
| Coating | Anti-glare |
| Hardness | [not given] |
| Blue light | Low blue light |
| Privacy | Privacy Guard |
Requirements
| Item | Requirement |
| Size | 13.50″ to 14.49″ |
| Aspect ratio | [not necessary] |
| Resolution (native hardware) | Physical grid of 1920 horizontal and 1200 vertical pixels [minima] |
| Touch | Must respond to touch contact at three or more points simultaneously |
| Type | [not necessary] |
| Brightness | 400 cd/m2 |
| Contrast (static ratio) | 800:1 in white luminance to black luminance |
| Colour gamut | 100% sRGB |
| Viewing angle | Plus or minus 80% from the perpendicular with contrast ratio > 10:1 in horizontal and vertical angle |
| Reflection | Reflected luminance < 30 cd/m2 at 500 lux ambient illumination |
| Hardness | 3H under ISO 15184 test conditions |
| Blue light | [not required] |
| Privacy | Device has a user-selectable option in hardware to reduce the viewing angle |
Rather than go into the details of each item, here are a few general pointers:
- Viewing the product specifications of different manufacturers, we can see differences that we need to accommodate. For example, 14″ is a common screen size, but Microsoft makes a laptop with a 13.8″ screen, and Apple one with a 14.2″ screen. We would be excluding them unnecessarily unless we had a specific reason why only a screen of exactly 14″ would do.
- Some of these requirements may seem overly pedantic. But the manufacturers themselves have to deal with these criteria when they design the device and select components. So a close working relationship with manufacturers can help us define our requirement. We don’t need to depend only on their published specifications. We can also look at the component datasheets themselves, and we may use those as a source for verification that a requirement is met.
- Elsewhere in the requirements we will state that a device much achieve Windows Hardware Compatibility Programme (WHCP) certification. The WHCP specification defines in detail what a device must do to support the relevant features of Windows. For example, it has an extensive System specification for a touch digitizer, which then extends into a Component specification. We do not need to define exactly how a screen responds to touch, because the WHCP does it, provided that the screen responds to touch at all.
Conclusions
This might all seem a bit much. We know roughly what laptops are suitable. We know their specifications. We want to say: “give me a price for one like that”. But I look at it another way. First, this is a very large procurement, with a value in the £ hundreds of millions and potential benefits of £ tens of millions. We might not be used to doing it this way, but that doesn’t mean it is wrong or unnecessary. Second, we are doing a public-sector procurement, and the legal framework exists to provide wider public benefits and not only value for money.
In later parts of this series we will take a look at the economic case, and how to organise ourselves to carry out the procurement effectively.