The requirements

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.