Awarded to Made Tech Ltd

Start date: Monday 14 October 2019
Value: £797,200
Company size: SME
Ministry of Housing, Communities and Local Government (MHCLG)

Beta development of a new Energy Performance of Buildings Register service. copy

7 Incomplete applications

4 SME, 3 large

10 Completed applications

8 SME, 2 large

Important dates

Monday 22 July 2019
Deadline for asking questions
Monday 29 July 2019 at 11:59pm GMT
Closing date for applications
Monday 5 August 2019 at 11:59pm GMT


Summary of the work
MHCLG requires an agile, flexible team to deliver beta for a new digital service to replace the existing Energy Performance of Buildings Registers service (EPB Registers).
Latest start date
Monday 9 September 2019
Expected contract length
10 Months
Organisation the work is for
Ministry of Housing, Communities and Local Government (MHCLG)
Budget range
A budget is capped between the range of £900k - £1m for completion and successful delivery of this project.

About the work

Why the work is being done
The Department is responsible for providing a statutory service to lodge, store and retrieve Energy Performance Certificates (EPCs), Air Conditioning Inspection Reports (ACIRs) and Display Energy Certificates (DECs), until at least 2021.

The department is ready to commission work now, in order to ensure that there is no break in the continuity of this statutory service.
Problem to be solved
To meet the needs of the user groups (defined below) we require:

• new citizen-facing service
• new API access for assessors to lodge and retrieve EPB reports
• a new fee payment solution
• the cleansing and migration of a large amount of EPB data to the public cloud
• development of an improved address matching service
• a new EPB database and reporting solution.

Approximately 1.25m EPCs and 140k DECs & ACIRs are lodged on the registers each year.

Since 2007 20m domestic and non-domestic EPCs and 1.2m non-domestic DECs and ACIRs have been lodged.
Who the users are and what they need to do

• Find an up-to-date EPC report for a property
• Find an assessor to do an EPC assessment on a property
• Estate/letting agents need to access EPC certificates


• Lodge assessment data so that EPCs can be generated
• Need to have only one valid address for properties.

Data users

• Identify EPC data trends
• Get a bulk view of specific properties on the registers
• Enable property portals to show a valid EPC graph

Other interested parties: (subject to future data sharing policy) - property investment industry, property conveyance industry, construction and home improvement industry.
Early market engagement
Discovery and alpha phases have been completed.

The Alpha phase was procured via the Digital Marketplace:

Summary of alpha work:

Prototype front end developed during alpha:

The successful bidder’s team will have access to existing documentation from the completed discovery and alpha work and the subject matter experts within the internal team.
Any work that’s already been done
The recommendations for beta are:

• Drive the development of the service and prioritisation from user research;

• Continue to explore where this service sits within larger journeys for users (e.g. buying a house), and link up with other services where necessary;

• Design with data - understand what data is in the service and think about what useful information this can be turned into for users;

• Further investigation of the choices to be made regarding cleansing and migrating the existing EPC data from the legacy system
Existing team
MHCLG will provide a Service Owner, Product Manager, Delivery Manager and Tech Lead/Technical Architect. The team will be supported on a part-time basis by the Designer and Content Designer who worked on the alpha. During beta, we are hoping to recruit a User Researcher and may recruit other agile team members.

We expect flexibility in any proposed service and financial model to replace supplier team members with internal team members during the lifetime of the project.
Current phase

Work setup

Address where the work will take place
All work will be delivered at the MHCLG office located at 2 Marsham Street, London, SW1P 4DF.

MHCLG will not fund travel within London, but will fund necessary travel outside of London.
Working arrangements
We would prefer a co-located team in 2 Marsham Street, however team members may work remotely 1-2 days a week with agreement.

Travel/expenses to the primary site in 2 Marsham Street cannot be reimbursed by MHCLG.

We expect the supplier to work using agile methodology.

The supplier will also be expected to work openly.
Security clearance
CTC or above is desirable for suppliers as non-CTC staff require escorting on site. There is no requirement for supplier personnel to be security cleared. BPSS clearance will be required to access MHCLG's ICT systems.

Please make it clear whether staff have CTC security clearance or not when submitting responses.

Additional information

Additional terms and conditions
1. All materials/outputs derived from the contract shall be the property of MHCLG;

2. GDPR requirements will be discussed and agreed once the successful supplier has been notified (as part of discussions to agree the wording of the call-off contract);

3. Non-disclosure agreement will also be required to deliver this requirement.

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
  • With examples, provide evidence of your experience in working with a multi-disciplinary team on agile projects of similar size, complexity and timelines as outlined in the Government Service Standard
  • With evidence, provide details in delivering and supporting a high volume, transactional, web-based service to the Digital Service Standard, including compliance with WCAG 2.1 AA accessibility guidelines and GDPR
  • With examples, provide details of developing and delivering secure/scalable and robust cloud-based services including a continuous-integration(CI) pipeline, live service monitoring/alerting and knowledge of system security risks and pragmatic mitigation
  • With examples, provide evidence of your expertise in using Terraform for infrastructure-as-code
  • With examples, provide evidence of your experience of building secure RESTful APIs with comprehensive test coverage
  • With examples, provide details of your expertise in migrating and cleansing large amounts of data from legacy servers to cloud-based storage using an Extract, Transform and Load (ETL) procedure
  • With examples, provide details of your understanding of the challenges associated with working with address data and UPRNs, and approaches to overcoming these challenges
Nice-to-have skills and experience
  • With examples, provide details of your axperience in taking on a beta where you did not complete the alpha
  • With examples, provide details of your experience of bringing an agile mindset and principles to teams who are new to Agile
  • With examples, provide details of your experience of publishing data to open data standards

How suppliers will be evaluated

How many suppliers to evaluate
Proposal criteria
  • Proposed approach and methodology – including technical proposal
  • Demonstrating an understanding of our requirements
  • Estimated and credible time-frames for the work
  • Team structure, including skills and experience of individuals and their relevance
  • Identifying risks and dependencies, and offering approaches to manage them
  • Demonstrating value for money
  • How the approach or solution meets user needs
  • How you will ensure smooth transition and knowledge transfer to the live service team
Cultural fit criteria
  • Experience of successful collaborative working as part of a mixed supplier-client delivery team sharing knowledge within the team
  • Experience of delivering in an open, collaborative way according to the principles of the Government Service Design Manual
  • Identifying risks and dependencies, and offering approaches to manage them
  • Demonstrate establishing rapport with stakeholders, keeping them informed and managing their expectations
  • Demonstrate simplicity (e.g. do less but better, explaining complex issues in a clear, simple way, break down and prioritise complex issues).
  • Team structure, including CVs of team members including dates
  • Experience of complex, multi-format, bulk data migration and data cleansing.
Payment approach
Capped time and materials
Assessment methods
  • Written proposal
  • Case study
  • Work history
  • Presentation
Evaluation weighting

Technical competence


Cultural fit




Questions asked by suppliers

1. Is there an expectation for the Alpha supplier to bid for this work?
This is an open, transparent and fair competition called off against a Government framework contract, so it is possible that the supplier (who delivered the Alpha phase) may bid for this requirement.
2. Asking for CVs greys the IR35 waters, can you confirm this opportunity is outside of IR35?
The purpose of requesting CV’s is to ensure that MHCLG gains an understanding of the skills and experience of the individuals suppliers propose to use if successful in bidding for this requirement. As this is an outcome (and not a specialist role), the expectation is that this will be outside IR35.
3. Is the supplier who completed the Alpha submitting for this opportunity?
Please see our response to Question 1 above.
4. Does the budget listed include VAT?
No, the listed budget is exclusive of VAT.
5. Please can you confirm if you have a preferred Tech Stack and if so, what is it?
No commitment has been made to a particular tech solution for the new register, and we expect shortlisted suppliers to suggest their preferred stack as part of the technical proposal. However, unless there are compelling reasons to diverge, we would expect the hosting, language choices and technical approach to fall broadly within the options recommended in “The GDS Way”.
6. As part of the existing team you state:

During beta, we are hoping to recruit a User Researcher and may recruit other agile team members.

Does this mean you expect, during the contract, to roll off the contracted resource and replace with your staff members? Can you confirm the roles you would require in the team?
As set out in the Existing Team section of the requirement, we are looking for a degree of flexibility. We anticipate that as members of the internal team are recruited they will work alongside the successful contractor and replace them at an appropriate point in order to prioritise resource where it can best support the development.
7. Please can you confirm the roles of the evaluation team?
The evaluation team has not been finalised yet. However, we expect that it will be comprised of Energy Certificate Policy staff, Procurement and Digital staff and, potentially, one independent evaluator.
8. Can you confirm if you are looking for single examples per competence or multiple examples?
Suppliers may choose whether they provide use single or multiple examples for each competence.
9. Does the budget listed include VAT?
This question was initially answered as question 4. However, question 4 was answered incorrectly. The correct answer is that VAT is inclusive.
10. In order to compare suppliers like for like, how will price be evaluated?
As set out in the tender document price attracts a 20% evaluation weighting.

At the appropriate time, we shall request this information from suppliers. Normally, we request the number of days and day rates for each role suppliers shall provide to deliver the requirement. We have asked for a capped time and materials model, but if there are elements which are already fixed (by suppliers), these should be noted within suppliers’ commercial proposals.
11. Will the scores from the evidencing round be taken through to final evaluation? Or will they only be used for the purposes of shortlisting suppliers?
This has not yet been discussed or agreed with the Evaluation panel. However, previous experience of using the DOS framework suggests that long-list scoring will be taken forward to the short-list stage.
12. You list MHCLG roles in the existing team section. Are all the roles expected to be full time on this project (unless stated)? In addition, are all these team members permanent MHCLG staff?
MHCLG roles include: Product Manager, Delivery Manager and Tech Architect who will be full time throughout the project. Other roles will join the team as/when required. While they are on the team it’s expected they will be full time.
13. Will you be providing a full time Product Owner to this project?
14. Are you able to recruit and provide access to users for the purpose of user research?
Yes, MHCLG has facilitated access to users during the Discovery and Alpha phases of this project and will be able to do so for Beta.
15. Will you be able to organise access to stakeholders throughout the project?
Yes. Also see the answer to Q14.
16. Are you looking for an organisation with GDS assessment experience or just certain individuals proposed in the supplier team?
We’re looking for an organisation with demonstrable experience and competence in working to GDS service standards and a good track record of passing GDS assessments.
17. For the first evaluation round (evidence), what would you expect to see from an answer for it to be deemed 'exceeding' and score 3 marks?
This has not yet been discussed or agreed with the Evaluation panel. However, previous experience determines an ‘exceeded’ response as providing added value beyond simply meeting a requirement for a specific delivered outcome and details of what tangible benefits were achieved.
18. As per DOS guidelines 'You should only provide one example for each essential or nice-to-have requirement', are you only requesting one example per skills and experience question?
This question has (to a degree) been answered already – our response to Question 8. However, the DOS guidance is more specific than our response to Question 8 – so this is telling suppliers to focus on one example so you should focus primarily on one example.
19. What was the method used to establish the estimated budget is roughly correct to deliver the Beta?
The estimated budget is a guideline based upon our understanding of the scale and complexity of the project and a comparison with other government projects with similar features.
20. Has a roadmap for Beta been developed? If so, can this be shared with bidders?
We want to develop a detailed roadmap with the successful bidder.
21. Has the Alpha phase passed GDS assessment? If so, when? And if not, what is the reason for this?
Yes, the Alpha phase was assessed as meeting GDS’ standards on 13th June 2019.
22. How will you ensure a level playing field in this procurement for new suppliers competing against the incumbent Alpha supplier?
The Alpha supplier is not a current incumbent. The Alpha phase was completed earlier this year and it has taken MHCLG a little bit of time to get the various internal and external approvals to start the Beta phase.
23. What roles are you expecting suppliers to provide? In addition, are you expecting all roles to have the ability to be full time?
We expect suppliers to propose the team they would need to deliver the outcome, along with the roles provided by MHCLG.

We would expect to see at least one senior developer and a data engineer included in the core of any proposed team, along with other multidisciplinary agile roles as required. We are currently in the process of recruiting a Delivery Manager and should have an update on the requirement for this role for shortlisted bidders.
24. How would you like suppliers to present expenses (separate rechargeable or included in day rates based on assumption for travel)?
Under the Working Arrangements part of the original requirement. MHCLG stated that expenses to the primary site - 2 Marsham Street – cannot be reimbursed by MHCLG.
25. Has a risk log been developed along with mitigations against each of these? If so, can this be provided to bidders?
For Alpha, we drew up a list of possible threats to the EPC service, with mitigations. The threats we identified tended to be those faced by any modern data-backed web service. Possible mitigations include - securing/encrypting data,
using modern web frameworks,
keeping software and servers up-to-date
having adequate monitoring and alerting in place to be able to detect attacks, intrusions and respond accordingly.

Specific (unknown) risk for Beta covers migration of all existing historic data and certificates. Alpha did not fully answer the question of what the data migration looks like, so clarifying this early in the beta is essential.
26. Has a risk log been developed along with mitigations against each of these? If so, can this be provided to bidders?
Please see our response to Question 25 above.
27. Has a Target Architecture been developed along with a transition plan to this?
A possible architecture was developed during Alpha, but we are not committed to this for the beta. Definition of the architecture and transition plan will be part of the beta. The architecture considered during alpha can be seen at:
28. Are there any major drivers for the specified timescale? Also, are there any major dates you can share with potential suppliers?
Yes, the new service will replace a legacy register service which has a finite life. We have specified the dates set out in the tender to enable a planned and timely transition to a new register without a gap in service.
29. Are there any major drivers for the specified timescale? Also, are there any major dates you can share with potential suppliers?
Please see our response to Question 28 above.
30. Have you produced a prioritised backlog for Beta? If so, will this be shared with shortlisted suppliers in order to estimate against?
We have a list of the main high-level epics for Beta, viewable here:

But we believe that the development of a detailed roadmap and prioritised backlog should be done with the involvement of the full development team. We plan to do this as part of the initial project kick off.
31. Have any architectural diagrams been produced as part of Alpha? If so, are the able to be shared?
Yes, a suggested architecture was produced as part of the Alpha and can be viewed at:
32. From the budget section, can MHCLG please describe the project state that would be expected for 'completion and successfully delivery'?
As described in “The problem to be solved", we expect the minimum “successful delivery” to include a lodgement service via API for all domestic and non-domestic certificate types, migration of the existing registers and historical certificates to the new service, and a new citizen-facing service-standard-compliant service to retrieve certificates and find an assessor. This will also involve address lookup and matching, both for assessors and for the citizen-facing service.
33. Are all the outcomes listed in the 'problem to be solved' section in scope for the Beta?
Yes, they are. We believe a successful outcome will have to address each of the things listed.
34. Are there any gaps in capability of the incumbent supplier that would either prevent them from delivering a successful Beta or make another supplier more desirable?
No, as there is no current incumbent delivering the Alpha phase. Further details can be found with our response to Question 22.
35. What is the main reason you are procuring the Beta through the DOS framework and not moving forward with the incumbent supplier?
The Alpha phase was completed in June and there was a gap between delivery of the Alpha phase to the Beta phase to cover getting the appropriate approvals.
36. Please confirm whether one example should be used for each question?
Please refer to our earlier response to Question 8 – It is up to suppliers, however one response does fit nicely with the word limits imposed in responding to each question. A single example, which is more detailed, is preferred to multiple examples.
37. What impact will a “no-deal Brexit” have on this requirement?
We cannot give complete assurance at the present time, but this requirement underpins several other different government policy areas which the register service will need to continue to support – the green deal, private landlord (PRS) Minimum Energy Efficiency Standards and more importantly, the home buying and selling process. Therefore, the current expectation is there will be minimal impact on this requirement.
38. Has a Target Architecture been developed along with a transition plan to this?
Please see our response to Question 27 above.
39. You mention a 10 month delivery timescale. Could you provide some further details of how this was decided?
Please see our response to Question 28 above.
40. Are any proof of concepts available from the Alpha phase?
Prototypes for the customer facing aspects of Alpha are available (link in the specs).
During the alpha we decided not to replicate the current authorised user access to the registers and instead to develop API access for energy assessors and data users.
41. Are there any front-end initial requirements, such as web, static or databases?
No, not at present. All are currently up for grabs. There is some 80TB of data in the existing registers, much of it is XML documents. Early Beta will look at what data looks like and in what modern format can this be transferred or moved into a Cloud bulk storage area. Hosting may be in AWS, but no final decisions have yet to be made.
42. Do you know how many Users use the service?
As stated in the requirement, approximately 1.25m EPCs and 140k DECs & ACIRs are lodged on the registers each year.

Since 2007 20m domestic and non-domestic EPCs and 1.2m non-domestic DECs and ACIRs have been lodged.

From a current service perspective, it is difficult to predict how many people use the service, so no. There are more than 25,000 Assessors who will need access to the service to lodge EPCs and other reports and some assessors are more active than others. It is however difficult to predict number of users at any one time.
43. Could you provide further details of what you require from requesting CV’s?
We are looking to gain an understanding of the overall skill set and balance of the shortlisted suppliers’ respective proposed teams. Specifically, we would consider their experience of similar projects, experience of working with government, details of their rates and seniority.
44. During the Alpha phase, have you carried out a Proof of Concept (POC) in a cloud environment? Specifically, a Proof of Concept (POC) hosted in a new cloud environment that can persist and retrieve data from your database? If so, can this please be described, and details of the cloud vendor provided?
No. The Alpha phase used data from the Open Data Communities release to power the prototypes.
45. During the Alpha phase, have you carried out a Proof of Concept (POC) that explored path to migration and gives you confidence that the listed budget safely includes cost of migration?
A POC of the data migration was not carried out during the Alpha project.
46. Could you please confirm your expected timelines for the additional assessment methods, following shortlisting?
We are planning to notify shortlisted suppliers on 9th August, and invite them to present the proposal, response to cultural fit questions, case study and work history on 13th and 14th August.
47. As part of the existing team you state:
During beta, we are hoping to recruit a User Researcher and may recruit other agile team members.
Does this mean you expect, during the contract, to roll off the contracted resource and replace with your staff members?
Can you confirm the roles you would require in the team?
Revised response to Question 6 -

Whilst the MHCLG staff are rolled onto the programme, we expect the supplier to work alongside these in-house resources with the intention of cross skilling.