Awarded to Made Tech Ltd

Start date: Monday 12 March 2018
Value: £676,080
Company size: SME
Government Digital Service, part of Cabinet Office

WP1538: Outcome for a skilled digital team to develop GovWifi from beta to a live service

3 Incomplete applications

2 SME, 1 large

7 Completed applications

5 SME, 2 large

Important dates

Thursday 11 January 2018
Deadline for asking questions
Thursday 18 January 2018 at 11:59pm GMT
Closing date for applications
Thursday 25 January 2018 at 11:59pm GMT


Summary of the work
GDS require a team with good knowledge PHP and Ruby to develop, run and support the GovWifi from public beta to a live service.
Latest start date
Monday 12 March 2018
Expected contract length
12 months
Organisation the work is for
Government Digital Service, part of Cabinet Office
Budget range
Up to £910,000

About the work

Why the work is being done
GovWifi is intended to provide internet access for visitors and Civil Servants to central government and wider public sector buildings across the country, allowing users to sign in once and able to use the service at multiple locations. GovWifi is currently a beta service which is being consumed by a number of public sector organisations across their locations. In order to continue to realise benefits set out in the Common Technology Services business case the service needs to be able to handle increased demand and adoption the service over the 2018/19 financial year.
Problem to be solved
Visitors and Civil Servants have internet access in public sector buildings across the country, having only needing to register once and access the internet in multiple locations.
Who the users are and what they need to do
As a visitor/worker I need:
- to access the internet on my devices to do work
- to work efficiently and connect to the internet when I arrive at a different location
- delegates to get online and receive details before they arrive.

As an organisation I need:
- to provide wifi for my users
- to monitor traffic and the content that is being consumed in my department
- users to be able to work without installing infrastructure
- to access logs in order to diagnose why a user can't connect.
- to have a secure internet connection
Early market engagement
Not applicable
Any work that’s already been done
GovWifi is in public beta being used by over 70 organisations in over 300 locations
Existing team
The existing team consists of a developer, user researcher, tech writer and lead product and delivery managers (which work across the programme)
Current phase

Work setup

Address where the work will take place
Government Digital Service, 7th floor, The White Chapel Building, 10 Whitechapel High Street, London E1 8DX
Working arrangements
The people will keep GovWifi and Common Technology Services Programme team hours in order to maximise knowledge transfer and integrate with team development processes: Monday to Friday based in our office (in Aldgate) starting work by 9.30am, 7.5 hours per day + lunch time.

There will be a requirement for the people working on this outcome to participate in extended hours support rota for GovWifi service they are developing - on average one week in four.
Security clearance
All must have BPSS as a minimum. Preference for contractors to already hold SC clearance, however we would be willing to sponsor the SC clearance process at the supplier's expense. One person in the team must have SC clearance.

Additional information

Additional terms and conditions
All expenses must be pre-agreed with between the parties and must comply with the Cabinet Office (CO) Travel and Subsistence (T&S) Policy.

All vendors are obliged to provide sufficient guarantees to implement appropriate technical and organisational measures so that the processing meets the requirements of GDPR and ensures the protection of the rights of data subjects. For further information please see the Information Commissioner's Office website:

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
  • At least 3 years proven experience working on agile projects as part of a multidisciplinary team, as outlined in the Government Service Design Manual and Digital Service Standard.
  • At least 3 years expertise in iteratively, prototyping, designing and building services which meet both user needs and the GOV.UK guidelines for content design, service design and accessibility.
  • Ability to turn research data into clear findings to inform what you build
  • At least 3 years expertise in architecting and developing scalable services using public cloud technologies, service-oriented architecture, microservices, security and integration.
  • At least 3 years experience in system security risks and how to pragmatically mitigate them
  • At least 3 years experience using languages such as Ruby, Python and PHP within an existing production codebase
  • At least 3 years experience of commodity cloud providers such as AWS (EC2 and RDS) in a production system. Please give examples
  • At least 3 years experience in administering common open source databases like Postgres, MongoDB, Redis etc. in a production environment. Please give examples
  • At least 3 years experience using continuous integration and version control (e.g. using git) to create an application deployment workflow to a production environment
  • At least 3 years experience of a rigorous approach to software development (TDD, code review, pairing)
Nice-to-have skills and experience
  • Familiarity with the process of adding features to open source software and the approach to documentation
  • At least 3 years experience administering common open source databases like Postgres, MongoDB, Redis etc.
  • Experience supporting a production environment and supporting technical customers/users
  • Familiarity with network protocols - TCP/IP, HTTP, TLS, etc
  • A track record in developing and delivering digital products and services to government

How suppliers will be evaluated

How many suppliers to evaluate
Proposal criteria
  • Ability to build a user centric digital service based on user needs
  • Team structure - covering product, infrastructure setup and maintenance, ongoing prototyping and design, software delivery, content and how the the team will adapt according to changing priorities
  • Identify risks and dependencies and offer approaches to managing them while developing a digital service
  • Team members can work with agile backlogs
  • All proposed team members must provide evidence that demonstrates they meet all the cultural fit criteria
  • Experience working in multidisciplinary agile teams using agile methodology
  • Value for money of the proposed solution
  • Please provide Work Histories of all proposed team members. All submitted Work Histories will be scored as a set against both the essential and nice-to-have criteria
Cultural fit criteria
  • Work as a team with our organisation and other suppliers
  • Transparent and collaborative when making decisions
  • Have a no-blame culture and encourage people to learn from their mistakes
  • Collaborating closely with colleagues in order to meet users’ needs
  • Has experience of and likes pairing and knowledge sharing
  • Delivering consistently within an agile environment
Payment approach
Capped time and materials
Assessment methods
  • Written proposal
  • Work history
  • Presentation
Evaluation weighting

Technical competence


Cultural fit




Questions asked by suppliers

1. Are the existing team govt employees or contractors? If contractors are they individual consultants or from one organisation?
The lead delivery and product managers as well as the user researcher and tech writer roles are current permanent government employees. The existing developer is a contractor provided through CL1 contract.
2. Can the Authority provide a description of, and architecture diagrams for, the BETA solution?
High-level technical diagrams for the GovWifi service will be provided to potential delivery partners who have been shortlisted for the next stage.
3. Can the Authority confirm the current number of daily users of the Beta solution and the estimated daily use of the Live solution on Day 1 Live and then moving forward?
Statistic around the current usage of the GovWifi service can be found on the service's performance platform. It is expected that the average user usage of the service would grow around 10% each month, depending on the adoption by organisations and their roll out plans across their locations.
4. Could the Authority please confirm how the pricing should be presented? Is it as a day rate per consultant?
We require an estimated cost for the project. This should be broken down into day rates and number of days per resource.
5. Does the Authority have a view as to the size of the anticipated team?
The team should comprise of a full multi discipline team as outlined in the service manual on
6. Could the Authority confirm how they would like the pricing model structured? As a day rate per consultant?
We require an estimated cost for the project. This should be broken down into day rates and number of days per resource.
7. What other parts of GDS have a RACI role on the project, and how frequently do there need to be update sessions with them (eg - GDPR team, Data Controller, IA team, GDS Engagement, Consulting Security Architects, SMT, User Research etc.)?
The GovWifi team will be expected to work with other parts of GDS and will be supported by the lead product and delivery managers for the Common Technology Service Programme to ensure appropriate engagement with internal stakeholders.
8. What other parts of Government have a RACI role on the project, and how frequently do there need to be update sessions with them (eg - NCSC, Crown Commercial, Steering Group of customer departments.)?
There are a number of external stakeholders (mainly organisations that consume GovWifi as a service), the GovWifi team will be supported by the lead product and delivery managers for the Common Technology Services Programme as well as the programme's engagement lead to ensure external stakeholders are provided with the right level of engagement.
9. Does the GovWifi team need to include an engagement function, or will this be fully done by GDS Engagement?
Although the team will need to engage with external organisations, this work will mainly be conducted, directed or supported by the Common Technology Services Programme's engagement lead and the wider GDS engagement function.
10. What level of support does the team need to provide - to GDS helpdesk only, or also to customer networks teams, or also to customer support teams, or to end users? If there are multiple groups, what are the service hours and SLAs for each group? Does RFP imply a Service Desk function to be provided by supplier?
The GovWifi team are expected to provide 3rd line support for the service. Current support model requires 3rd line support to both GDS helpdesk and to organisations (who have adopted GovWifi) network teams. The current support hours are extended business hours (8 till 7). It is not expected that the supplier will supply a service desk function, but the supplier will be expected to support the Common Technology Programme to shape a support model for the Service.
11. Does the team need to include User Research and Technical Author specialists, or will it be possible to use these, without cross-charge, from the existing GDS communities when needed?
The Common Technology Services Programme does have User Research and Technical writing capabilities, it would be expected that the proposed team would need to include user research capabilities, but will be able to draw on the cross programme technical writing capability.
12. The request talks about Ruby, Python and PHP languages in the “skills required” (but leaves Python out of the summary) Is there an expectation that the code should be migrated onto a single platform, and if so, which one?
The current service is written in PHP, the development languages that GDS services support are Ruby and Python. It is expected that the service should migrate to a development language that GDS will be able to support the service in BAU. Further information will be provided to suppliers who are shortlisted.
13. Is it possible to see the panel assessment from the Beta service assessment? This is showing as "not published yet" from 27th April 2017. []
The Beta assessment report will be provided to shortlisted suppliers.
14. What is the anticipated date for the service to transition to Live?
It is expected that the service should transition to a live service in around 9 to 12 months.
15. What, if any, internal or external suppliers are involved with the current hosting, development, running and support of GovWifi?
Further information will be provided to shortlisted suppliers.
16. Is the service available to members of the general public?
The service is available to visitors or staff working in public sector organisations which have adopted GovWifi.
17. Is the service available outside of the United Kingdom or European Economic Area (EEA)?
The service is only available in the United Kingdom.
18. What are the specific requirements for knowledge transfer both at the start and end of this engagement i.e. between what persons/roles does knowledge need to flow and in what direction?
Further information will be provided to shortlisted suppliers.
19. What team development process are currently in place? Is there a desire to change them during the engagement?
Further information will be provided to shortlisted suppliers.
20. For the purposes of GDPR does GovWifi collect, process and store PII data? Has/Will GDPR gap analysis be completed prior to engagement? If not complete who takes responsibility for gap analysis and remediation in the current data store?
A gap analysis around GDPR on GovWifi has been completed, any remediation work that is required will be prioritised on the backlog of work and agreed with the lead product and delivery managers on Common Technology Services Programme. Further information around PII data will be provided to suppliers who have been short listed.