This checklist is intended to help those involved in designing, planning or running products and services to explore the issues that might help them scale beyond short-term or small-scale products.
There are many ways that data – especially open data – and open approaches to design can be used to deliver more efficient and effective products and services.
Our research has shown that innovative approaches are often not being effectively reused across local government or in the wider public, private or third sectors. Solutions remain local and successful innovations don’t benefit as many people as perhaps they could.
There are many barriers that limit the scaling of products and services. Open approaches to sharing data, software, methodologies and learnings can help to remove these barriers.
See the Scaling data innovation project page for more information.
Download the checklist
A4 print-at-home- 'How to design to scale - guide and checklist': English, French and German versions
- English-language version: Download the A4 print-at-home- 'How to design to scale - guide and checklist'
- French-language (français) version: Download the A4 print-at-home- 'How to design to scale - guide and checklist'
- German-language (Deutsche) version: Download the A4 print-at-home- 'How to design to scale - guide and checklist'
Comprehensive 'How to design to scale checklist'
Download the comprehensive 'How to design to scale checklist' [PDF]
How to use this checklist
As someone who is responsible for service design and delivery you could use this checklist when you are designing and planning your project. Or, later in your projects, as a guide to help you produce outputs that will help others to build on and reuse your work.
As a funder of innovative projects, eg in local government, research, or the third sector, you could use this checklist to help project teams think through how to deliver work that is more likely to scale beyond the initial funding period.
Why should you use it?
- To identify barriers to scaling
- To think about collaboration and sharing opportunities
- To help you to work in the open
- To make you think about what to document for others
Barriers to scaling
We have identified a number of barriers which can hinder the ability of a project to scale.
Data
- Data availability: A project may collect and use a dataset that other organisations do not have access to
- Data licensing: Access to non-open data may be costly or difficult for others
- Data quality: The data collected may not be fit for purpose, therefore costs will be incurred in cleaning it or making it suitable for a new area or team
- Different data formats: If data is stored in different ways and using different formats then a project may struggle to be replicated
- Legal issues: The legal landscape may have changed since the original project was run
- Ethical issues: A project may have run as a small pilot where explicit ethical issues could be managed effectively but would be harder to manage at a larger scale
Technical
- Proprietary software: Services developed using proprietary software minimise the scope for sharing, due to a lack of access for others, and increased financial costs
- Closed source: When relevant source code or tools are not openly available, a new team must develop a new version rather than use something that already works
Resource
- Initial funding: The need to secure initial funding – through proposals, grants, or winning competitions – may act as a barrier to organisations replicating work
- Sustainable funding: Projects need sustainable funding for ongoing costs, procuring help, accessing data etc. A sustainable project can grow or be replicated more easily. Interested parties need skills, time and resources to redeploy projects or initiatives
- Skills or resources: Interested parties need skills, time and resources to redeploy projects or initiatives
Knowledge
- Awareness and communication: A project’s successes or failures are often only known to the teams, but not others outside of them
- Different users: Users for one service might be specific to one location or problem, and not exist elsewhere
- Documentation: It may be unclear how to approach replication and the risk might seem too great
- Evidence of impact: Pilots and projects can be short, with little evidence of their success, failures or viability on a larger scale
Collaboration
- Engagement and collaboration: A reluctance for different organisations to work together can mean that risk and reward is not shared