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.
One thought on “User Needs”