Awarded to Methods Business and Digital Technology Limited

Start date: Monday 23 January 2017
Value: £207,522
Company size: SME
Cabinet Office

Race disparity data across the public sector - alpha

0 Incomplete applications

16 Completed applications

13 SME, 3 large

Important dates

Tuesday 6 December 2016
Deadline for asking questions
Tuesday 13 December 2016 at 11:59pm GMT
Closing date for applications
Tuesday 20 December 2016 at 11:59pm GMT


Summary of the work
This No.10 initiative will investigate the disparity in how people from different races experience public sector services. We want to understand and publicly present the levels of disparity, to help inform policy and future service development. Prototyping, technical architecture decisions, data architecture, analysis and modelling expertise will be essential.
Latest start date
Expected contract length
3-4 months
Organisation the work is for
Cabinet Office
Budget range

About the work

Why the work is being done
The Race Disparity Audit team at Cabinet Office is delivering a key No.10 initiative. We will take data sets from government departments and produce a digital service for publicly analysing and presenting race diversity in public services. Ideal alpha start date is w/c 16 January 2017, and we need to start demonstrating prototypes to key stakeholders by mid February 2017.
Problem to be solved
Race disparity is an issue that affects people across the UK. This project will investigate the disparity in how different groups experience public sector services. We want to understand and publicly present the levels of disparity and to help inform policy and future service development.
Who the users are and what they need to do
We need to: understand all race data that we hold across public sector services; visualise and present the data in ways that meet user needs.

NGOs and advocacy groups need to: understand the extent of race disparity across public services; access intelligence and information; investigate raw data and information; identify issues around their focus area; use the data to influence change.

Government users need to: openly and transparently share their data; identify gaps in their data; have confidence their data is accurate and not open to misrepresentation; prioritise key areas of change in policy and services based on the data.
Early market engagement
Any work that’s already been done
25 ministerial departments have already provided feedback on the datasets identified and formats that they have. A discovery is underway, learning more about the users of the digital service and their differing user needs and problems that they experience.

As the discovery progresses, we will update our insights on the aforementioned user groups and their needs.
Existing team
Policy team (4 people), Data team (3 people - Deputy Director, 2 analysts, more expected), Digital team (3 people - GDS service manager, user researcher, technical architect). The alpha team will work with the Digital team, analysts and there will be support from other GDS subject matter experts eg data scientists.
Current phase

Work setup

Address where the work will take place
London, either co-located with the Race Disparity Unit in Cabinet Office, or with GDS. A combination of on-site and off-site may be possible.
Working arrangements
Our team will be based across Horseguards and Holborn / Aldgate. Off-site working may be accepted, depending on the supplier proposal but must be London-based and incorporate the GDS service manager, architect and user researcher into the core team. We work Mon-Fri with usual office hours. Frequent travel to other London sites is likely for user research and testing. Our agile working methodology includes daily stand-ups, fortnightly demos, weekly user labs, fortnightly retrospectives and we would expect the proposed team to integrate with this way of working and attend at the relevant location.
Security clearance
Baseline Personnel Security Standard as a minimum.

Additional information

Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Essential skills and experience
  • Expertise in iterative prototyping and testing with users and stakeholders
  • Experience of designing and delivering user experiences that meet user needs and comply with GOV.UK guidelines for design, interaction and accessibility
  • Proven experience of complex user journey mapping across ranges of users and stakeholders
  • Demonstrable experience in using metrics, analytics, data and user feedback to prioritise key content and features
  • Proven track record of working with large, heterogeneous data sets and presenting data and insights to users in a clear, meaningful way
  • Experience of how users access, find and interact with online government services
  • Knowledge of data visualisation, including geospatial and statistical data, for query, grouping/matching and visualisation
  • Extensive working knowledge and actual experience of government digital standards, including GDS service design manual, GDS style guide, and accessibility standards, and wider industry standards around open data
  • Experience of developing information architectures for new websites and services
  • Have proven experience of agile working environments as part of a multidisciplinary team as outlined in the Government Service Design Manual
  • Technical expertise of front-end, UI web development and responsive web design (HTML5/CSS/JS)
  • Expertise in delivering services that meet, at least, AA of the W3C WCAG2.0 accessibility standards. This includes the development of accessible data visualisation components
  • Proven experience delivering professional data expertise - specifically in data architecture design, analysis and modelling - that underpins successful digital services
  • Experience working with data standards and validation of metadata schemas, with extract-transform-load (ETL) technologies and with challenges of heterogeneous dataset federation and transformation into common delimited and linked formats
  • Demonstrable knowledge of security, compliance and legal issues around working with and presenting public data (e.g. Data Protection Act)
  • Expertise in solutions that utilise service-orientated architecture and micro services
  • Awareness of existing open source or proprietary solutions and platforms to efficiently federate, store, link and present heterogeneous datasets
  • Expertise in public cloud technologies, including design, planning, security and integration
  • Be able to architect robust systems and display knowledge about system security risks and how to pragmatically mitigate them
Nice-to-have skills and experience
  • Knowledge of statistics, at least to a knowledge of basic sampling theory, statistical tests
  • Knowledge of ONS and websites

How suppliers will be evaluated

How many suppliers to evaluate
Proposal criteria
  • Technical solution
  • Approach and methodology
  • How the approach or solution meets user needs
  • How the approach or solution meets the Race Disparity Unit's goals
  • Estimated timeframes for the work
  • Team structure
  • Value for money
Cultural fit criteria
  • Experience of successful collaborative working as part of a mixed supplier-client delivery team sharing knowledge within the team
  • Demonstrate a working culture of openness and transparency
  • Demonstrate rapport with senior stakeholders and ability to manage their expectations
  • Demonstrate political awareness and cultural sensitivity in managing and presenting complex data around race
  • Have a no-blame culture and encourage people to learn from their mistakes
  • Can work with clients with low technical expertise
  • Be transparent and collaborative when making decisions
  • Can work with clients with low technical expertise
  • Demonstrate simplicity (e.g. explaining complex issues in a clear, simple way, do less but better, break down and prioritise complex issues)
  • Demonstrate flexibility (e.g. the ability to shift tasks to meet changing priorities)
  • Bring agile mindset and principles into a developing organisation
Payment approach
Fixed price
Assessment methods
  • Written proposal
  • Case study
  • Reference
  • Presentation
Evaluation weighting

Technical competence


Cultural fit




Questions asked by suppliers

1. Has Cabinet Office got a specific resource profile you would like suppliers to provide?
Assuming you are asking if we have a specific team structure in mind: no, we are looking for suppliers to propose this. However, we anticipate that successful suppliers will have the capabilities to plan and carry out user research, design/build and test prototypes, plan and coordinate activities (delivery management), and make relevant technology plans and recommendations that meet the aims of the project and user needs.
2. Are there any outputs from the current Discovery phase that can be shared? In particular, any information with respect 1) candidate technical architecture thinking 2) characterisation of data sources
We will share discovery findings with shortlisted suppliers - as discovery is still underway, there is limited information to share right now. We expect the alpha to shape the technical architecture thinking. We can characterise the data sources as being a mix of admin and survey data sets collected by government departments. Some, but not all, will already have been published on GOV.UK or
3. Please characterise the number and type of data sets from other government departments that will be ingested? i.e. Are there near real-time data feeds, or reasonably static data sets.
We expect that the majority of data sets will be reasonably static. The team has identified over 300 sources across 25 central government departments containing relevant data sets. This work is still underway, and more information will be available by the time suppliers are shortlisted.
4. We note that the GDS Service Manager, Architect and User Researcher must be incorporated in the core Alpha team. Does this specifically imply that other roles currently involved within Discovery will not form full-time members of the Alpha team, and specifically the Data Team (Deputy Director and 2+ analysts)?
No, that isn't the implication. The other roles will also form full-time members of the Alpha team. However, we expect the GDS service manager and user researcher will be working on a daily basis with the successful supplier. Our architect isn't full-time - he's there in an advisory capacity and to ensure that technical decisions are in line with the Technology Code of Practice and the Service Standard. Our lead user researcher works 3.5 days per week and we expect suppliers also to have their own user research capability, given the scale and importance of user insights to the project.
5. Please clarify the role responsibilities of the GDS Service Manager? i.e. Does the Service Manager take lead responsibility for Delivery Management for Alpha, or is this a Product Owner role?
The service manager has overall responsibility ( provides a role description). During discovery, there is no need for both a service manager and product manager. However, it is likely that suppliers will want a dedicated product manager/owner and a delivery manager during alpha. Whilst the GDS service manager will attend stand ups etc. and work with the team to provide steer and guidance as needed, there will be other increasing demands on their time which means it would be advisable to have an experienced product manager in place.
6. Do you have any preferred technologies already in use by the existing team i.e. R and Shiny and Tableau?
No. At the end of alpha, we expect to have learned which technologies exist to implement our plan, in a viable and cost-effective manner. In line with the service standard, we expect to use open standards and common government platforms where available.
7. We have found that fixed price commercial models inhibit effective Agile delivery, especially at Alpha stage where prototyping is required and detailed requirements and acceptance criteria can not be known up front. Is it possible to propose time and materials, within a set budget limit instead?
A fixed price model has been specified because the spend for this piece of work needs to be agreed and allocated and cannot rise above the agreed amount.
8. Has Discovery identified the security threat model applicable to this project?
No, security will be addressed in alpha and beta phases.
9. Will all four assessments be deployed (proposal, case study, reference and presentation)?
We will ask for written proposals from all shortlisted suppliers, and will provide a template. Presentations will take place on the 9th or 10th January in central London. If a supplier is successful at this point, then we may not use further assessment methods.
10. Is there an indicative budget Cabinet Office can provide for this Alpha?
No, Cabinet Office has not provided an indicative budget with the view that suppliers propose the approaches that they think best meet the need, rather than a budget.
11. Given the Christmas break, will there be a pause in procurement?
Due to the break, suppliers will have from 21 December until 3rd January to provide evidence that they meet the requirements. Shortlisted suppliers will then be invited to submit a written proposal and to a face to face presentation.
12. Does the statement "Additional terms and conditions" mean that there are additional terms, if so what are these?
Standard Cabinet Office Terms and Conditions - these will be shared with all suppliers who register an interest.