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.
Buyer beware
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.
Only connect
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.
What’s next
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.
4 comments
Comment by Marc posted on
This is a great read. The only point I would challenge is the point about not paying for development work on a proprietary product.
Do you not think there are instances when sharing the costs of developing a product with other users and the product owner is a good way of getting features you want/need quicker?
Comment by hmott posted on
Hi Marc - thanks for the feedback. I agree there may be exceptions, it would be absurd to suggest there are no instances where some of the above isn't the most sensible approach. It's all about getting the most value for your investment, right?
However, I do think there is an important point that if you are investing in development on a proprietary product and those additional features make the product more desirable to other customers than the supplier should pay for the development effort. If, however, you want additional features that are bespoke to your niche needs (ie not going to make the product more saleable to other customers) then ideally this development should be decoupled from the proprietary product, so if you decide another product in the market is better value for money in the future you can take those additional features with you.
Like building a portable shed in the garden of a rented house that you can take with you when you move, rather than building an extension on the house.
Comment by Bob Gilbert posted on
If you get to own a share of the iP 🙂
Bob Gilbert
Comment by Andy Parkhouse posted on
If the product is from an SME, some features may simply not be possible unless customers will pay for or co-fund development work. This is because SMEs have limited access to capital (usually debt funding) and have to prioritise product development which will have the most benefit across the whole customer base.
There's an upside to this as well, because it creates discipline around not bloating the product and helps keep SaaS fees lower (smaller debts to service with interest + repayments).
I say 'SMEs', but I'm really speaking about our experience at Delib, where the products have been developed using a mix of founders money, debt, the SaaS fees directly, but also extensive customer co-funding. Other SMEs may vary of course 🙂