You should spend time exploring your options before buying or building a service, and always make sure you can change it in the future.
In the past, government bought proprietary software and systems from suppliers on long, locked-in and costly contracts.
This probably made sense at the time, but it no longer allows us to meet evolving needs. Making changes has often been very slow and expensive, resulting in poor services for users.
We now make sure we fully understand our users and their needs before we decide to build or buy a product. And we factor in the fact we’ll need to change the product in the future.
This is how we go about spending on technology and software at the Ministry of Justice (drawing on existing government policies).
Start with a ‘discovery’
Always start with a discovery phase to understand the users, their needs and how they try to use current services, in order to scope out the best solution.
This phase can take anything from a few days to 6 weeks, depending on the complexity of the area you’re looking at.
You’ll also have to examine the technical landscape and the security level of any data, as well as the standards for new services (eg open standards, security classification, the service standard, etc).
All this will help you explore the pros and cons of doing something new.
Weigh up your options
Explore different options, and don’t limit yourself to the same old supplier.
For instance, you could:
- build a bespoke solution in-house
- commission a bespoke solution from a supplier (via the Digital Marketplace)
- use another department’s open source product
- buy an off-the-shelf product
- a combination of the above
- do nothing
Weigh up the risks, benefits and total costs for each option. Include costs for support, ongoing licences and ending the contract.
You may be able to divide your proposed solution into parts to get the best deal, choosing a combination of a couple of options. You could use an off-the-shelf solution for the basic requirements but build something more bespoke for the more niche needs.
Remember that a discovery phase won’t always result in a new product or service. You may decide that you don’t need to buy or build anything new.
Find an owner
You’ll need to agree who in your organisation will own the product – now and in the future.
This will usually be the person responsible for the budget, or signing it off.
Their ownership shouldn’t end when the product is launched. The owner will also have to:
- maintain the product
- manage the contract
- plan the next procurement process well in advance
This is all part of planning for the future, so the product carries on meeting the needs of your users as they evolve over time. The same goes if you're building a new piece of software or buying some computers.
Tread carefully if you decide to buy an off-the-shelf product.
Check that it’s genuinely ‘off-the-shelf’. It won’t be if you’re the only customer, or it needs a lot of customisation beforehand.
Make it clear to the owner that this is a compromise which you’ve made in favour of a cheaper solution. It probably won’t meet all your users’ needs now, still less in the future, as technology and your customers change.
Have an exit strategy
Check you can easily get out of a contract and move to a new supplier if needed.
You should be able to get out of a contract within 30 days if you need to.
Keep contracts as short as possible – up to 2 years max – to give yourself wiggle room.
Don’t agree to software licence deals unless they will definitely help your users. And don't assume you have to stick with these licences, which will tie you down to a particular supplier.
There may be cheaper and better solutions.
Who pays the piper...
Don’t pay for development work on a proprietary product owned by your supplier.
If this is done it should be paid for by them. This shouldn’t affect the length of the contract or the notice period for ending it.
Make sure that they don’t charge you a lot for configuration – essentially getting the product to work with your systems. A non-technical person should be able to do this.
Don't spend more than you're willing to lose at the end of the contract. Think of it in terms of painting the walls of a house you're renting from a landlord.
Check that the product will work with your other systems – ideally using Application Programming Interfaces (APIs).
You’ll also need to ensure that you’ll own the data, and you can get to it easily in a usable format at no extra cost.
Products should ideally be hosted in the public cloud and be available via a browser. If this isn’t possible you could look at using your existing hosting contracts or Crown Hosting.
We’re going to be going through each of these steps with all new tech spend in the department.
We’ll refine our approach over time based on what works best in practice.
If you’re involved in buying or building services for the government then we’d love to know what you think.
Don't miss out on future blog posts: sign up for email alerts.