Awarded to Softwire Technology Limited

Start date: Tuesday 22 May 2018
Value: £1,294,000
Company size: SME
The Office for Product Safety and Standards (The Office), part of BEIS

UK SBS IT18065 BEIS Market Surveillance and Product Safety Database (Alpha and Beta)

7 Incomplete applications

4 SME, 3 large

16 Completed applications

11 SME, 5 large

Important dates

Published
Tuesday 20 March 2018
Deadline for asking questions
Tuesday 27 March 2018 at 11:59pm GMT
Closing date for applications
Tuesday 3 April 2018 at 11:59pm GMT

Overview

Summary of the work
The Office requires a team to deliver alpha and beta phase outcomes for an MVP1.0 release of a market surveillance product safety data hub. This will exchange data with external sources to drive services and improve intelligence capability. It will enable case management and notifications on product safety issues.
Latest start date
Tuesday 8 May 2018
Expected contract length
We anticipate alpha will last 14 weeks and beta six months.
Location
London
Organisation the work is for
The Office for Product Safety and Standards (The Office), part of BEIS
Budget range
The contract covers alpha and beta development of the MVP 1.0 service.

The budget for alpha is between £320-372k excluding VAT.

The budget for beta is between £900-£988k excluding VAT, however there is no commitment to spend up to this amount.

An alpha service assessment is required at completion of alpha. The outcome will determine the start of beta.

Allowing for a month’s interval between alpha and beta, we estimate the contract will be completed by end January 2019.

About the work

Why the work is being done
EU exit provides an opportunity for the UK to consider future operating models that expand upon capability currently provided by EU market surveillance systems, ICSMS And Rapex.

The UK uses these systems to conduct market surveillance and share intelligence and alerts on non-food products that pose a potential consumer risk across the EU.

The UK needs a service to maintain this capability and to strengthen and develop the UK’s national capacity for product safety and the work of The Office.

An MVP1.0 service needs to be in place by 29 March 2019. This will focus on case management and notifications.
Problem to be solved
The UK needs to collect and manage data on product safety and market surveillance from multiple sources and make that data available to UK regulators, enforcement bodies, businesses and consumers through appropriate channels. The UK also needs to manage product safety cases through initial submission to resolution and reporting and keep parties notified of progress.

The long-term vision includes exchanging data with international partners, including the EU.
Who the users are and what they need to do
Users of the service will include: various UK government bodies, consumers, and manufacturers.

As a UK government official I need to:
•Report dangerous non-food products and actions taken to mitigate against risks
•Share information about market surveillance, enforcement, and recalls
•Raise notifications
•Search for case information
•Manage workflow and refer cases

These needs and notifications will be in scope for MVP1.0 (We anticipate multiple user types with varying levels of permission depending on role)

As a Consumer I need to:
•Search previous product recalls
•Receive notifications
•Register products

As a Manufacturer I need to:
•Share information about our products
Early market engagement
Any work that’s already been done
A Discovery phase has been completed. Outcomes of the Discovery phase will be shared with suppliers at the assessment stage.
Existing team
This project is being led by The Office’s Digital and Technology team as well as subject matter experts. Specifically The Office will provide:

• Service Manager
• Product Owner
• Delivery Manager(s)

In addition, there will be access to local business analyst, user research, content design and developer resource to provide support to the project.

Subject matter experts will be available to help the supplier understand the policies and business processes that underpin the service.
Current phase
Alpha

Work setup

Address where the work will take place
The primary site will be 1 Victoria Street, London SW1H 0EH. However, The Office has other sites including Birmingham and Teddington and the team may be required to work there on occasion to engage with colleagues and stakeholders.

There may be a requirement for travel to other sites to conduct user research and testing.
Working arrangements
The team must be co-located at 1 Victoria Street, London and adhere to BEIS normal working hours (09:00 - 17:00). Suppliers must comply with the BEIS travel and subsistence policy.

Travel within the UK may be required for user research and testing purposes. BEIS will meet any additional travel costs incurred away from the London office for the purposes of user research or attendance at other BEIS sites.

Travel to Birmingham and Teddington offices should be expected occasionally.

Individual remote working arrangements are acceptable but must be agreed ahead with The Office.
Security clearance
Baseline Personnel Security Standard (BPSS) clearance required.

Additional information

Additional terms and conditions
There will be a pause at the end of alpha to enable a full progress review against the alpha deliverables (to be specified in the contract). Beta development will commence if the alpha deliverables have been met to the required standard and the cost remains in line with the specified budget.

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
  • Demonstrate how you will apply your skills and expertise to:
  • Deliver digital services that meet the GDS Digital Service Standard criteria and pass GDS service assessments and how this ensures the successful delivery of this project
  • Develop case management and notification capability that has the potential to be integrated with other data sources and how this will ensure the successful delivery of this project
  • Assess and implement API integration opportunities with existing relevant external sources and how this will ensure the successful delivery of this project
  • Design and develop a data driven service and how this will ensure the successful delivery of this project
  • Design service architecture enabling future iteration beyond MVP1.0 and how this will ensure the successful delivery of this project
  • Implement continuous integration, delivery and deployment and how will ensure the successful delivery of this project
  • Conduct user research remotely and how this will ensure the successful delivery of this project
  • Develop prototypes iteratively via user testing/research and how this will ensure the successful delivery of this project
  • Prioritise key content and features using metrics/analytics and how this will ensure the successful delivery of this service
  • Carry out user acceptance testing and how this will ensure the successful delivery of this project
  • Demonstrate how you will prioritise backlog development based on user research and how this will ensure the successful delivery of this project
  • Demonstrate how you will develop production ready code for private/public beta releases from Discovery findings and how this will ensure the successful delivery of this project
Nice-to-have skills and experience
  • Carry out an accessibility audit and how this will ensure the successful delivery of this project
  • Research and implement Government as a Platform services relevant to the service and how this will ensure the successful delivery of this project

How suppliers will be evaluated

How many suppliers to evaluate
3
Proposal criteria
  • Approach and methodology
  • Technical solution
  • How the approach or solution meets user needs
  • Estimated timeframes to complete the work
  • Team structure (with roles and responsibilities)
  • How risks and dependencies are identified and approaches to manage them
  • Approach to maintaining control, transparency and quality
Cultural fit criteria
  • Demonstrate how you will work transparently and collaboratively with The Office when making decisions throughout this project
  • Demonstrate how you will engage and work with suppliers developing existing services to inform The Office’s approach
Payment approach
Time and materials
Assessment methods
  • Written proposal
  • Presentation
Evaluation weighting

Technical competence

70%

Cultural fit

10%

Price

20%

Questions asked by suppliers

1. Although the Digital Marketplace requests that all questions are responded to in the form of a single "situation, work, outcome" case study, the way the questions in this particular tender are posed indicates that it might be more useful to respond with a more detailed approach to how we would approach the task you have specified. Our question is: do you want us to adhere to the "situation, work, outcome" format, or do you want a more specific approach to how we solve each individual question for you?
The "situation, work, outcome" format can be adhered to whilst also linking your responses to demonstrate how you will apply those skills to ensure the successful delivery of this project.
2. How many users to do you expect to use the new service? Including both government officials and consumers?
We estimate that the numbers of users for MVP 1.0 will be circa 5000, including trading standards officers and government officials.
3. Have any technology decisions been made as a result of the discovery phase?
No technology decisions have been made as a result of the discovery phase.
4. Will BEIS recruit user research participants, including consumers? Or will this responsibility lie with the supplier?
Yes, BEIS will recruit some user research participants although we may require additional support from the supplier to recruit other user research participants.
5. Was the discovery phase completed by BEIS, or with a supplier?
The Discovery phase was completed with a supplier, The Engine Group Ltd t/a Transform.
6. Are you expecting the MVP to be launched as a private beta, with a small sub-set of users, before rolling out the service to all users?
This is not known at present. We will review this as part of our planning for Beta.
7. Will the Service Manager and Product Owner at BEIS be working full-time on the project? Will you expect the supplier to include a product manager in their bid to provide support and advice on prioritisation?
The Service Manager will be predominantly focused on this work but will have other priorities to deliver in addition to this. The Product Owner will be full time. We are not currently expecting the supplier to provide a Product Manager.
8. Was Discovery carried out by an external company? If so, which one?
Yes, Discovery was carried out by an external company. The Supplier for Discovery was The Engine Group Ltd t/a Transform.
9. Do you have a preferred technology stack for this project?
No, we do not have a preferred technology stack for this project.
10. Can you pls share with us who carried out the Discovery Phase and are they able to bid for Alpha and beta? Thank you
The Discovery phase was completed by The Engine Group Ltd t/a Transform. Yes, they are able to bid for Alpha and Beta as this opportunity is open to all capable suppliers on the Digital Outcomes and Specialists 2 framework agreement.
11. Can you please confirm that this contract is outside of IR35?
This is unable to be determined at this time as it is possible for contractors who are both in and out of scope of the off payroll working rules to be engaged through DOS. The successful supplier / contracting authority will need to check the status in accordance with the HMRC online tool prior to contract commencement. A link to this tool can be found here: https://www.tax.service.gov.uk/check-employment-status-for-tax/setup
12. Can you please confirm the roles, skills and team sizes you expect for: 1) Alpha Phase 2) Beta Phase
We would like bidders to tell us how they would propose resourcing this project.
13. Given that the project is already in Alpha, is it possible for the discover outputs to be shared at this phase?
The Discovery outputs will be shared with all shortlisted suppliers.
14. The dates outlined in the Overview do not align with the intended completion date; could you please clarify the dates and the intended timeline? Further to this, could you please provide more information about the required 1 month review between phases within an Agile project delivery.
We anticipate that alpha will run for 12 weeks approximately May-July. This will be followed by a month to allow an alpha service assessment and any consequent work as a result of that. Assuming no major issues arising from that, we anticipate starting beta at the start of September for an estimated 6 months with a view of completing beta by end Feb 19 and then arranging a beta service assessment for March 19 to precede moving MVP 1.0 into public beta by end March 19.
15. The project is described as being in the Alpha phase, could you please describe how far into this phase the project is?
The project has not yet commenced the alpha phase. We anticipate starting alpha in early May.
16. Have any technical stack preferences / considerations been made? If so, is this information available to applicants?
No decisions have been taken on the technical stack as yet.
17. Is cloud hosting a consideration for this project?
We are open to all technical proposals so long as they are consistent with the Government Technology Code of Practice and Digital Service Standard.
18. It is understood that the intended solution will be required to integrate with a number of other platforms; are these key integration point/platforms known?
These key integration point/platforms are not known at present.
19. Are the webservices already built?
No, the webservices have not already been built.
20. Has the Discovery been delivered in house, or in conjunction with an external supplier? If the latter, which supplier was it?
Discovery was carried out by an external supplier, The Engine Group Ltd t/a Transform.
21. Could you please elaborate on the reason for the 1 month hiatus between Alpha and Beta? This is likely to be problematic from the point of view of team continuity between the phases.
This is to allow for an alpha service assessment to take place to provide assurance that we have met the digital service standard and are ready to proceed to beta.
22. The first Essential Skills and Experience question is: "Demonstrate how you will apply your skills and expertise to:" Could you please provide guidance on how you would like this to be answered? Suggest 'N/A'.
Please do not provide a response to that statement as it is not a question that will be scored. Due to the word limit when posting criteria the question has been split into two parts. A response of "N/A" would be acceptable.
23. Was the Discovery phase undertaken internally or by an external supplier?
The Discovery phase was undertaken by an external supplier, The Engine Group Ltd t/a Transform.
24. Has an incumbent worked with you thoughout the Discovery?
Yes, the Discovery phase was undertaken by an external supplier, The Engine Group Ltd t/a Transform.
25. What size of team are you seeking for Alpha and Beta? Is it expected that the resource profile will be skewed towards a larger team for Beta, bringing in more technical representatives at this stage?
We would like bidders to tell us how they would propose resourcing both Alpha and Beta.
26. Will the service be deployed to GOV.UK?
The current assumption is that this service will be deployed to GOV.UK.
27. Will the PO be co-located with the team, and engaged full time?
The intention is to provide a full time PO who will be co-located with the team.
28. Is the PO empowered to make decisions directly?
The intention is to empower the PO to make decisions directly although some decisions may need be referring to other parties.
29. Has enough user research been conducted in Discovery to support an Alpha service assessment (accessibility needs, all stakeholder roles researched etc)
User research has been conducted in Discovery with user personas and pen portraits defined. However, it also identified additional areas for research. The assumption will be that further user research will be required in alpha specifically around the user needs of primary users for the MVP 1.0 service.
30. What service design artefacts have been created so far?
We have identified user personas and supporting high level user stories; there has also been some thinking around the scope of MVP 1.0.
31. Are you looking for a description of how we apply our approach, rather than giving specific examples of how we have applied approaches in previous projects?
We are looking for examples of how you have successfully applied your approach in recent (i.e. last two years preferably) completed projects whilst also linking your responses to demonstrate how you will apply those skills to ensure the successful delivery of this project.
32. Where you refer to “Design Service Architecture” – is the focus on services intended to be from a business or technical perspective?
Both. MVP 1.0 will form the foundation of a wider service that will developed over a longer time frame. The service design needs to factor future iteration of the service that allows for new features to be added seamlessly allowing free exchange of data. This is dependent on a technical design that enables this including the potential long term use of API to share data with external sources.
33. In the criteria addressing “assess and implement API integration opportunities with existing relevant external sources”, what existing sources are referred to?
API integration is a long term aspiration of this programme and may not feature as part of the MVP 1.0 release which is the focus of this requirement.
34. Is the Office looking for software and services in the Alpha and Beta phases?
We are open to all proposals to help us deliver the MVP 1.0 service, however they must be aligned to the Government Technology Code of Practice and Digital Service Standard.
35. Can you please define the data feeds for the ISC?
By 'ICS' we assume that this means ICSMS which is one of the EU market surveillance database that the UK may lose access to post EU Exit. ICSMS enables EU market surveillance agencies (e.g. The Health and Safety Executive, Local Authorities Trading Standards) to share data on non-compliant products available within the EU. It is a non-mandated system based on manual input that creates case information. ICSMS has a public facing interface which enables users to search on products and provides information.
36. Can you please define the data feeds for the MX?
By 'MX' we assume that this means ICSMS which is one of the EU market surveillance database that the UK may lose access to post EU Exit. ICSMS enables EU market surveillance agencies (e.g. The Health and Safety Executive, Local Authorities Trading Standards) to share data on non-compliant products available within the EU. It is a non-mandated system based on manual input that creates case information. ICSMS has a public facing interface which enables users to search on products and provides information.
37. Can you please define the data feeds for the RAPX?
By 'RAPX' we assume that this means RAPEX which is one of the EU market surveillance database that the UK may lose access to post EU Exit. RAPEX is a rapid alert system used across the EU to notify authorities and the public on products available within the EU that are deemed dangerous with the potential to cause injury or loss of life. It is a manual feed system and has a publicly available EU site that provides weekly updates.
38. Will data relevant to MVP1.0 be available to access from Tuesday 8th May 2018?
Other than publicly available data currently held on ICSMS and RAPEX (see questions 35-37), we are not anticipating access to any potential relevant data to be available on 8 May 2018. User research in alpha may reveal non-ICSMS data sources currently in use by UK market surveillance agencies that may be accessible but this is not confirmed.
39. Is there any high level description of what MVP1.0 potentially will and / or won't be expected to incorporate? If so can you please share this.
We are currently in the process of defining the scope for MVP 1.0. Current high level thinking is that it will need to deliver case management and notification functionality in line with ICSMS/RAPEX and alternative systems in use by UK market surveillance agencies. The agreed scope for MVP 1.0 will be shared with the successful supplier for the start of alpha.
40. (PART A) Government Service Manual expects typical Alpha phases to last circa 8-weeks. What are the headline reasons that Alpha is expected to require 14-weeks?
(PART A) 8 weeks for an alpha is a guideline only and the actual duration is largely influenced by the complexity of what needs to be achieved. We originally estimated 14 weeks for alpha as we were aware that additional user research would be required in certain areas. However, the scope for MVP 1.0 means that some of this user research can be deferred to subsequent phases. We are also doing some pre-engagement with primary users to recruit participants for research and testing to enable the successful supplier to commence any user research right at the start of alpha.
41. (PART B) Government Service Manual expects typical Alpha phases to last circa 8-weeks. What are the headline reasons that Alpha is expected to require 14-weeks?
(PART B) Our current estimate is that alpha will run from 8 May to end July 2018, approximately 12 weeks. This is in line with our experience of alpha durations with previous projects.
42. We note that BEIS are allowing for a month interval between Alpha and Beta. Are BEIS open to suppliers who can demonstrate an approach to flow safely from Alpha to Beta without an interval?
No. This is to allow for an alpha service assessment to take place to provide assurance that we have met the digital service standard and are ready to proceed to beta.
43. Is it correct to assume that 29th March 2019 date is being driven by the start of the Brexit transition period? Otherwise, is this either an aspiratinal date, or is there some other important reason that you can share which driving this date?
It is correct to assume that the close date is influenced by the EU Exit timeline. However, this work is part of a longer term programme that is dependent on a service foundation being in place by end 2018/19 which MVP 1.0 will provide so this date remains firm.
44. Are there any interim critical dates which impact Alpha or Beta before 29th March 2019? If so, could you please explain at a high level how and when this might impact this requirement?
Both alpha and beta phases will require a digital service assessment which must be passed to allow the MVP 1.0 service to transition from alpha to beta and then into public beta. The anticipated timing for this assessments are August 18 for an alpha assessment and March 19 for a beta assessment. The MVP 1.0 service needs to be in public beta by end March 2019.
45. Has Discovery considered what candidate architecture or technology might be considered during Alpha? If so please describe this.
No decisions have been taken on candidate architecture or technology as yet.
46. Are there any existing technologies or enterprise technology strategy that the Alpha needs to comply with? Is so please describe these at a high level.
All technical choices will need to be in line with the Government Technology Code of Practice and Digital Service Standard.
47. Has an external supplier helped to deliver Discovery, if so which supplier(s) have been involved?
Yes, the Discovery phase was undertaken by an external supplier, The Engine Group Ltd t/a Transform.
48. Has Alpha identified the roles that a supplier should provide, if so what are these?
We would like bidders to tell us how they would propose resourcing both Alpha and Beta.
49. We note that you will provide Delivery Manager(s). We also note that "at the end of alpha to enable a full progress review against the alpha deliverables (to be specified in the contract)". Is it your expectation that BEIS will hold delivery management responsibility for achieving necessary outcomes, or do you expect the supplier to provide a Delivery Manager to ensure that necessary outcomes are achieved?
BEIS will provide Delivery Managers to assist in the delivery of supporting work streams, however we expect the supplier to provide a Delivery Manager to ensure that necessary outcomes are achieved.
50. We note travel within the UK may be required for user research and testing. Is there any indication that more than 1 role will be necessary to undertake this this work?
We have no views on this. We would anticipate a mix of face to face and remote user research and testing. We would like bidders to tell us how they would propose to ensure that all necessary user research is undertaken.
51. We note: "There will be a pause at the end of alpha to enable a full progress review against the alpha deliverables (to be specified in the contract)." What are the Alpha deliverables that are expected?
The primary deliverable at this point will be meeting the digital service standards for an alpha assessment that will be required at the end of alpha. However there will also be a post alpha retrospective to review progress and to highlight any scope for making changes.
52. We note that the Government Service Manual is largely silent with respect how to plan and deliver projects where data is a central element. Are you open to suppliers proposing approaches that mitigate important areas where the service manual is currently silent?
We are open to all proposals to help us deliver the MVP 1.0 service, however they must be aligned to the Government Technology Code of Practice and Digital Service Standard.
53. Are you looking for an open source development, or might you consider a platform solution based on a platform in the market like Salesforce? Alternatively, can various solutions be part of the Alpha, and reviewed during that process?
We are open to all proposals to help us deliver the MVP 1.0 service, however they must be aligned to the Government Technology Code of Practice and Digital Service Standard.
54. Did the Discovery recommend any technology solutions, and if so what were they?
No decisions have been taken on the technology solutions as yet.
55. It states, “In addition, there will be access to local business analyst, user research, content design and developer resource to provide support to the project.” Can you please outline the skills and experience of this team? As well as the numbers of each of the above that may be available for the project.
The resources quoted will be available to provide supplementary support to the supplier where possible. The team is largely inexperienced and should be considered at a trainee level.
56. (PART A) What are the specific expected outcomes for the Alpha?
(PART A) We are looking to validate user needs, including assisted digital, that will drive the MVP 1.0 service. From that we expect to see well defined user journeys that are reflected in a user centred service prototype(s) design that has been tested with users and iterated using their feedback. The prototype(s) will form the basis to develop a production level service in beta. We are also look for clear direction on technical choices based on testing out toolchains throughout alpha.
57. (PART B) What are the specific expected outcomes for the Alpha?
(PART B) All of this must enable a successful service assessment based on the Government Digital Service Standard assessment critera for alpha services which will be held at the end of alpha. To reiterate the service must be developed in line with the Government Technology Code of Practice and Digital Service Standard.
58. Can you confirm that Discovery findings will be shared in time with suppliers before the proposal stage?
Yes, the Discovery outputs will be shared with all shortlisted suppliers.
59. Has any thought been given to the longer term support and maintenance costs for the project, and if so, is there an outline budget? Might this include costs for licensing of any incorporated solutions?
Longer term support and maintenance will be the subject of a separate requirement.
60. Could you please provide some further information on the user roles and stories? In particular, is the Consumer any member of the public, or will they need to be granted access to the system? What is the process around raising and receiving notifications?
We anticipate that Consumers will not access MVP 1.0 service. The raising and receiving of notifications will be determined during Alpha.
61. Please could you provide some information about who carried out the Discovery phase of the work? Are there any outcomes of this phase that impact the potential user stories outlined in the opportunity?
Discovery was carried out by an external supplier, The Engine Group Ltd t/a Transform and outputs from the Discovery will be shared with all shortlisted suppliers.