Awarded to Digi2al Limited

Start date: Monday 11 March 2019
Value: £240,000
Company size: SME
Department for Business, Energy and Industrial Strategy

Alpha for Official Development Aid Financial and Programme Reporting Transformation Digital Service

11 Incomplete applications

8 SME, 3 large

33 Completed applications

24 SME, 9 large

Important dates

Wednesday 2 January 2019
Deadline for asking questions
Wednesday 9 January 2019 at 11:59pm GMT
Closing date for applications
Wednesday 16 January 2019 at 11:59pm GMT


Summary of the work
Design and build prototype dashboard service for a) collection of financial and programme data from multiple organisations with varying systems/databases, and b) management and evaluation of data via analytics and reports, to help organise and evaluate data, and mitigate information management risks. Review code adaptability and suitability from existing systems.
Latest start date
Monday 4 March 2019
Expected contract length
3 months (with a possibility for an extension if necessary)
Organisation the work is for
Department for Business, Energy and Industrial Strategy
Budget range
The guide budget range is £200-£250k (excl. VAT). This range allows for further user engagement if required, and the various solution approaches/prototype development that could potentially meet our requirements.

All travel, subsistence and other expenses must be included in the overall cost.

Separate day rates for each role should also be supplied with details of management processes and mitigation for poor service delivery, staff handover, turnover, quality maintenance and corrective actions.

About the work

Why the work is being done
The current tool for collecting ODA financial and programme spend information is not fit for purpose. ODA is open to scrutiny by the media, DFID, Cabinet Office, HMT, Publish What You Fund, Ministers etc., and poor quality of reporting can be detrimental.

Data and reporting requirements are increasing - new ODA Transparency commitment, as well as more information required to fulfil portfolio and fund management functions.

There is a huge operating burden, the current system (excel) is lacking stability, and accuracy of data is compromised due to poor version control and confusing nature of the tool.
Problem to be solved
Programme managers in various organisations need to easily and efficiently report on their programme and financial information into one place, that can be one version of the truth, addressing version control issues. Data should be easily extracted and manipulated in various ways, as soon as it is reported (by country/organisation/theme etc). Users should be able to access a dashboard style view of spend respective to their organisations or country spend, for comparison and strategic awareness. Data extraction/report outputs should be possible for various reporting organisations with varying and specific information requirements.
Who the users are and what they need to do
As a reporting officer:
1. I need to know what data to provide, when to provide it, and see guidance, so I can provide correct and timely information.
2. I need to access the latest version of previous data so that I update the right data.
3. I need to see which programmes have been added/removed.

As a knowledge and information manager:
I need to share reports with peers, for knowledge transfer and informing senior management.

As a programme manager, I need to analyse and report on spend data, so I can mitigate risks, and produce reports.
Early market engagement
Any work that’s already been done
We have completed a discovery phase. This involved:
- Running user experience workshops to understand the user journey.
- Liaising with other ODA spending government departments and teams, and assessing whether there are any existing reporting systems we could use.
We also started developing a technical requirement document, which can be used to inform the supplier and be built upon through further user engagement.
Existing team
We work across two teams:
ODA team in BEIS, London - ODA Policy and operations
Research Management Team in Swindon - programme managers working on day to day management of funds/reporting
There will be a dedicated person working on ODART from one of the teams, but regular engagement will be necessary with multiple individuals within each team for user engagement, checking the development of the prototype, tracking progress etc.
Current phase

Work setup

Address where the work will take place
The supplier can work from their own premises or remotely. Interactions with the client team and partner organisations will between Central London and Swindon offices, and may require some travel to one of our delivery partners based in Exeter.
Working arrangements
Travelling between London and Swindon offices for user engagement, due to a wide range of users located in different organisations.
The supplier team should be available to participate in weekly catch-ups in central London or remotely. We expect face to face interactions between client and users (approx. 16 teams) across central London, Swindon and Exeter, plus a presentation of prototype and knowledge transfer event.
Security clearance
No security clearance required as supplier will not be based in the building.

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
  • Have experience in delivering a financial management and information dashboard service to be used by multiple organisations or businesses.
  • Have experience of meeting the Government's digital service standard, including meeting multiple organisations' requirements for secure online access to a cloud delivered service
  • Have experience in delivering an agile project, adhering to and prioritising user needs, and presenting effective data visualisations.
  • Have experience designing services for users with low digital literacy
  • Have experience of transitioning services/data from physical infrastructure to cloud
  • Have experience of successfully transitioning of projects into a live service environment within a government department within the last 12 months
  • Have experience of successfully completing a Digital Service Standard Assessment.
Nice-to-have skills and experience
Have evidence of experience of working with user groups that store information in different operating environments, for example MS Office 365, Google G-Suite, and various databases.

How suppliers will be evaluated

How many suppliers to evaluate
Proposal criteria
  • Proposed approach and methodology
  • Demonstrating an understanding of our requirements
  • Estimated and credible time-frames for the work
  • Identifying risks and dependencies, and offering approaches to manage them
  • Demonstrating value for money
  • How the approach or solution meets user needs
Cultural fit criteria
  • Work as a team with our organisation and other suppliers
  • Be transparent and collaborative in decision making, user acceptance, and transferring knowledge
  • Take responsibility for their work
  • Share knowledge and experience with other team members
  • Can work with clients with low technical expertise
  • Demonstrate very high quality interpersonal communications, especially showing sensitivity to established relationships and competing pressures.
  • Be adept at applying agile methods in the context of more traditional working practices
Payment approach
Capped time and materials
Assessment methods
  • Written proposal
  • Work history
  • Presentation
Evaluation weighting

Technical competence


Cultural fit




Questions asked by suppliers

1. Can you provide details of how much of your teams time will be assigned to this project and whether they will be ready to start on the expected start date?
We have one project manager working 80%, and a senior policy lead working 40%. Both are ready to start on the expected start date. Delivery partners (users of the anticipated system) will be available on an ‘as needed’ basis and the supplier will work with the project manager to find the best times to engage with users as needed.
2. What do you see as the identified risks around the delivery of this work?
Project risks will be disclosed with shortlisted candidates at evaluation stage.
3. Please confirm who the people on your selection panel are and their individual roles and responsibilities.
This information will be disclosed to shortlisted candidates at evaluation stage.
4. Does the SRO for this opportunity have the capacity to attend/partake in agile ceremonies? e.g. show and tells, retrospectives etc.
We have an SRO and a deputy SRO dedicated to this project. The deputy SRO will be more ‘hands-on’ and will aim to be present for conclusive show and tells/retrospectives. The SRO and deputy SRO will also be regularly updated with highlight reports, and project board meetings will take place at key decision-making stages. Project board meetings could be an opportunity to present to the SRO.
5. Please could you confirm what is meant by 'our delivery partners based in Exeter'?
Our government department distributes ODA funds to various delivery partners. Teams in these organisations are responsible for delivering ODA programmes, and reporting progress to BEIS. These teams are part of the users of the anticipated system, and are located in London, Swindon, and one of the organisations is based in Exeter. For the purposes of any further engagement with users required in Alpha stage, the supplier may have to travel there for exploratory meetings/show and tells. Travel to Exeter will not be regular/weekly.
6. Is it anticipated that the solution would be handed over to them [delivery partners] upon task completion?
The anticipated solution will not be handed over to delivery partners upon task completion. The solution will be handed over to BEIS/the business.
7. Who completed the discovery? How many hypotheses were recommended out of discovery that the business aim to test and build during Alpha?
Discovery was completed by a Project Manager that has been working from the beginning of this project, alongside some user researchers and policy leads. There was only an indicative hypothesis that was recommended, consisting of user needs and not an actual solution. The business expects the supplier to review the user needs, and issues with the current system, to provide recommendations and build a prototype for a solution during Alpha.
8. Can the output from the Discovery phase be shared at this point to better inform an approach to deliver the Alpha?
This will be shared with shortlisted candidates at evaluation stage.
9. Can you provide some guidance on the question, "Have experience in delivering a financial management and information dashboard service to be used by multiple organisations or businesses?” Is the financial information key indicators or delivering reporting against a standard such as FRS or GAAP?
This does not need to be delivered against a standard. The financial information reporting will be based on key indicators, so evidence of experience against indicators will be sufficient.
10. Was the Discovery phase delivered by an external supplier or was it delivered in-house?
The Discovery phase was delivered in-house.
11. You state that a Discovery has been completed. There may be a need for further discovery activity e.g. understanding dashboard types. Can we assume that this sort of work will be needed and is part of the Alpha?
Yes, it is fair to assume that further activity such as understanding dashboard types, and any further necessary engagement with users may be required in Alpha, to build on the discovery work already completed.
12. What is the expected next step beyond the Alpha and when might that start?
The immediate step beyond Alpha will be a Digital Service Standard assessment, which will review Alpha outputs and determine whether the project should move onto Beta private phase. If successful, we expect Beta phase to begin in mid-July/August, provided there are no delays in assessment and control spend processes.
13. Do you anticipate other users e.g. Viewers Only, Administrators, Data Maintenance for a fully live system and if so how many of each type?
Yes, there should be a range of users with various accessibility requirements. We estimate at least 2 administrators within the business, at least 2 information managers/data inputters from each partner organisation (approx. 40 user profiles), and some lower tiered administrators (1 within each organisation if not already an assigned user profile) within each partner organisation (for reviewing/signing off and submitting checked data).
14. Will ODA gather all the requirements for the final dashboard/reports or do you expect the supplier to undertake the discovery of this as part of the Alpha project?
BEIS/The business has gathered majority of the requirements for a dashboard/system (functionality), and the supplier will need to review and will only need further requirement gathering if they feel existing user needs are not sufficient. Actual reporting requirements (in terms of what data needs to be collected), have already been gathered by BEIS and will not be a responsibility of the supplier to research.
15. Where will the base data originate? Will it be imported by integration or by “data loading” on a regular basis? If loaded, what formats can we expect, or can we specify via a template?
The base data will originate from our delivery partners’ systems. We hope for a solution to require minimal manual handling of data, and the supplier can specify the best way to do this, by working with the delivery partners to establish the best method that is most efficient.
16. Will an initial data migration be required and if so, please confirm that any data integrity or cleansing will be the responsibility of the ODA/BEIS?
An initial data migration is not expected in Alpha. We expect to migrate data in Beta phase.
17. Is a public facing portal required to share this with the public or more widely within government?
A public facing portal is not required. We are not sharing data with the public. We expect the solution to be accessed by defined user access/login, however it would need to exist on the cloud as most of our delivery partners are not on government IT systems.
18. Is data entered by “programme managers” (see Problem to be solved) and/or “reporting officer” (see Who are the users), all standard across programmes or will each programme require different input types to cover differing data?
Data ranges across two funds, GCRF and Newton Fund, which mostly collect the same information, however the way in which we collect the same data may differ for some organisations. The supplier will need to liaise with the delivery partners to get a clearer understanding of the best ways of collecting some datasets – the outliers for discussion will be highlighted to the supplier by the business.
19. You state you have run user experience workshops to understand the user journey. Is this now fully defined or would the supplier need to complete this task?
The user journey is fully defined.
20. How many ODA/BEIS users will be expected to take part in the Alpha and need to access/test any prototypes?
Around 10 users.
21. We assume that submissions to demonstrate how we will meet the proposal and cultural fit criteria will be required at the next stage of the process should we be shortlisted?
Yes, that’s correct.
22. We assume that the request around separate day rates, details of management processes, staff handover etc. will all be addressed at the next stage of the process should we be shortlisted?
Yes, that's correct.
23. Can you share work already done at this stage, or is the expectation that this will be shared at the next stage of the procurement process?
This will be shared at the next stage of the procurement process.
24. What is the size of the current team managing the reporting process?
2 staff working full time in the core BEIS team. This is the team currently responsible for managing the receipt, upload and processing of data/information provided by our delivery partners. The team also supports active management of and central reporting of the ODA funds, through the review of data (e.g. progress of projects and spend of projects against allocated budget).
25. What is the current tool used for collecting ODA financial and programme spend information?
Excel spreadsheets.
26. What is the expected timeline/process for this procurement exercise?
We will be receiving applications until the 16th Jan. We will then take 1 week to review applications and shortlist candidates, which will be followed by emails to shortlisted candidates with a request for further information (proposals and times for presentations). We will include more information about the project and give you 1-2 weeks’ time to prepare and send final submissions/attend presentations, at which point we will evaluate and decide on the award of a contract.
27. What are the current types systems and databases from which programme and financial data is extracted?
The data is manually written into Excel spreadsheets and sent via e-mail to BEIS. Information is then uploaded to an Access database to collate / report information held on different spreadsheets.
28. Would further work to scale and more widely roll out the dashboard but subject to a further procurement exercise or run on from this one?
Yes, if a suitable prototype is built and the Digital Service Standard Assessment is successfully completed, we expect to move to Beta phase for full implementation and rollout, following another procurement exercise.
29. Is the scope of work purely to design, build and implement a prototype dashboard for the authority?
We expect the supplier to design, build and assess the usability of the prototype (through user testing etc.). If the prototype demonstrates that it can meet BEIS needs, then it will be developed into a fully working system at Beta Stage following another procurement excercise.
30. What is the expected scope of this prototype?
We expect the prototype to enable: 1) the collection of financial and programme reporting information from various users; 2) the implementation of on system data checking and authorisation by users; the production of various standard reports on submitted information; production of dashboards indicators (e.g. to support a) reporting process control and b) oversight of reporting information; and have functionality for data mining and manipulating to enable the production of bespoke reports to fulfil BEIS reporting requirements.
31. What was your decision making process for "buying a product" ?
We identified key user needs / functionality and then undertook a high-level review of several systems used by other government departments. However, we did not find a system that seemed to meet our key user needs. The option of developing our own solution was a recommended approach. However, this might involve using code from one of the above systems. As part of the planned Alpha stage work, are asking the contractor to review feasibility of using existing code form a limited number of systems.
32. The opportunity on Digital Marketplace mentions that BEIS has completed a discovery phase and started developing a technical requirement document; is this information to be made available to suppliers at this stage?
This information will be made available to shortlisted suppliers at evaluation stage only.
33. Does this requirement imply that programme directors may upload their information in different formats (MS Excel, Google Sheets, etc.), and that the supplier must therefore be experienced with handing data provided in different file formats, in order to aggregate data from multiple sources, parse and verify it and display in a dashboard?
Or, does BEIS require the solution to directly access/integrate with the systems of programme organisations in order to automatically extract the necessary data (ETL/‘extract, transform, load’)? If so, what are the expectations around working with these organisations to ensure their systems are compatible (ongoing basis)?
We expect users to be able to upload their information in different formats. Note once the upload formats are agreed with user teams, we expect the formats to remain fairly stable over time. The dashboard should also have access for direct manual input, and the system should be configured for easy user upload of various files for an automatic system verification and aggregation into a dashboard. We do not expect the solution to directly interface with delivery partner systems.
34. We have valuable experience in delivering similar projects for commercial and educational organisations, and while we are confident in achieving DDS Assessment, we cannot currently meet the "Essential" criteria below.
Have experience of successfully transitioning of projects into a live service environment within a government department within the last 12 months
Have experience of successfully completing a Digital Service Standard Assessment.
We would be interested in demonstrating our approach if there is any room for flexibility in the criteria given our experience in migrating financial dashboards from Excel.
Unfortunately, only suppliers that answer "yes" to all of the essential skills criteria are able to apply for the opportunity.
35. Does the budget include licence fees for any potential SasS type solution?
36. Will the supplier require any security clearance?
We will require a minimum of BPSS clearance.
37. Are there any security restrictions on access/viewing the data that will make up the final dashboard/reports?
The data needed to make up the final dashboard/reports will be sent/provided to us by our delivery partners and should not need higher security clearance than BPSS. We envisage the system where this information is to be stored (Alpha prototype) to be accessible by users depending on their access need, which will be specified.
38. We don't have any experience of completing a Digital Service Standard Assessment but our services are ISO accredited and we have been providing relevant digital services and solutions to many public sector clients such as HMRC, Environment Agency, Highways England. Are we still eligible to apply?
Unfortunately, we are only able to review applications that meet all essential criteria.
39. You state that the supplier will, as part of the Alpha, “Review code adaptability and suitability from existing systems” – how many systems need to be assessed and can you indicate base code types?
Currently, suitability of two codes from existing systems need to be assessed. One is an Office 365 based Azure database, another is ASP.NET MVC application, written in C#. The user interface uses HTML 5 and CSS as well as various Javascript/JQuery libraries (e.g. D3 and Bootstrap).
40. Will access to these systems for assessment be easily granted?
These codes are open sourced, and individuals/ technical architects working with the codes/systems are government officials and will be introduced to the supplier and available for exploratory chats to assess feasibility. Whilst creating admin/guest accounts may be tricky, suppliers will be able to work alongside said individuals and explore functionality that way.
41. What Tech Stack would you like to use or are you open to what we think is the best fit?
We are open to recommendations from the supplier based on the best fit for our requirements.
42. How many knowledge and information managers, programme managers, and reporting officers will there be for any full rollout/live system?
We estimate at least 2 administrators and 2 information managers within the business, at least 2 information managers/data inputters from each partner organisation (approx. 40 user profiles), with an additional 18-20 profiles for overseas partners (info managers) and some lower tiered administrators (1 within each organisation if not already an assigned user profile) within each partner organisation (for reviewing/signing off and submitting checked data).

(some information missed in Q13)
43. You state that you have liaised with other ODA spending government departments and teams, to assess whether there are any existing reporting systems that could be used. What were the results of this work?
We reviewed a number of systems, but none fully met our needs.
1) Could not be used because its’ code was not openly sourced.
2) System was not yet externally facing, did not have a financial module, so at the time was not suitable. They haves since improved the code (openly sourced), and are keen for us to assess whether it would be feasible to build on.
3) Office 365 azure database tool (open sourced) could fulfil our basic needs (without dashboard/analytic capability), but no external facing access. Needs to be assessed whether it would be feasible to build on.
44. The requirement is just for an Alpha. Can we assume, as the project is T&M, that we can define the outputs of the Alpha during initial negotiations and as the project progresses (in an agile fashion)?
Yes, Alpha outputs will be defined during initial negotiations.
45. Review code adaptability and suitability from existing systems. You mention ‘existing systems’ – what existing systems are used by you and these multiple organizations please?
The existing systems/code that will need to be reviewed for suitability are not currently being used by ODA users/programme managers in BEIS. We are referring to systems from other govt. organisations – please see Q39.
46. b) management and evaluation of data via analytics and reports
What Business Intelligence & Analytics Tools do you have in play currently?
We are currently able to undertake some limited analysis using basic data base tools, but this is not comprehensive across all current data.
47. What Tech Stack is in play i.e. what technologies are you using currently?
Currently, we are using MS-office tools only.
48. What types of restricted access would you like? User, Organizations, etc?
Restricted access would be 1) Organisations 2) Specified Users within organisations, (there will be different type of access for different users (e.g. to upload /enter data, to check / review data, to approve data, to run reports).
49. Please expand on what your users would want to see for the words "and see guidance"; I need to know what data to provide, when to provide it, and see guidance, so I can provide correct and timely information.
This refers to simple guidance notes next to data/information entry screens or cells where the user is being requested to enter data / information (e.g. ability to scroll over a ‘help’ column to expand/define/remind what value/level of detail we are asking for reporting).
50. What levels of concurrency do you expect in users?
At least 100 but extendable to any number in future without changing the code. We have not yet looked at how many will be using the system at any one time and would look to the contractor to advise on potential concurrency capacity issues and the options available.
51. How many distinct functional roles do users fall in to?
We currently visualise the following but will be looking to the contractor to support review / definition, which may increase the number and types of roles.
1. BEIS Programme Managers (admin roles) – accepting reports, accepting and authorising new data, adding/deleting programmes, extracting information, pulling reports etc.
2. BEIS Information Managers – Viewing and extracting all information, pulling reports.
3. Delivery Partner Reporting Officers – Inputting information and sending reports, viewing mode, pulling reports from available data.
4. Delivery Partner Authorizer – viewing mode, authorize data (or deny data for review) before it’s submitted for BEIS viewing.
52. Will any users need to use mobile devices to access reports and dashboards?
At the moment it’s not a key requirement, but this may be something we may wish to think about.
53. Is there an indication of the amount or complexity of the type of information that needs to be displayed within the dashboard?
Currently, we have 30+ individual spreadsheets received quarterly, each spreadsheet containing roughly 100+ lines per organisation, 3 main tabs for completion (financial: actuals and forecast split by quarters; and programme – 25+ columns).
Reporting will also include additional data to support new portfolio and transparency reporting. We are also considering moving some reporting data to a monthly basis.
54. What is the lowest required latency of the data between source and dashboard?
The data should as real time as possible.
55. How much self-sufficiency would you like your user base to have? E.g. all reports/dashboards pre-built, run, and distributed to them? or the ability for users to be able to generate their own reports and/or run analytics within reports they have received?
We would like to create: i) some standard reports that are automatically generated and refreshed (on dashboards), ii) include some more specialist reports that can be generated when needed; iii) for bespoke queries and reports to be run on an ad-hoc basis.
56. Do you have preferences for cloud-first, API-first or mobile-first technologies?
We require the solution which is cloud based, accessible on mobiles and APIs should be available for others tor interoperability.
57. Do you have a preference for Open-source tools?
First preference should be on using Open source/ standard tools.
58. a) collection of financial and programme data from multiple organisations with varying systems/databases.
You mention ‘multiple organisations’ – which organizations please?
The organisations include 3 Government bodies and 5 non-Government bodies. Details will be provided at Evaluation stage.
59. You mention ‘varying systems/databases’ – what systems/databases are used by you and these multiple organizations please?
We only have a partial list of the individual systems used by our delivery partners (DPs). Flexi grant, Oracle and Workday. Note, we are not expecting our new system to directly interface with DP's systems. We expect the contractor to identify ways that information can be uploaded/input to the new system (e.g. via a CSV file and through direct entry). Individual DPs will determine how information can be downloaded from their own systems into a CSV file – although we would expect the contractor to advise DPs on potential practical and standard available solutions.
60. Do you follow an open-source first approach to software decisions? Is Escrow an acceptable alternative for vendor code?
Yes, as per GDS and government guidelines, we would like to follow an Open-Source first approach to solution. Yes, Escrow will be acceptable alternative.
61. For the purposes of developing a prototype, please confirm that multiple consultants/developers can access the development environment concurrently (if provided to us, rather than by us).
Development environment should be for at least 10 developers but one should be able to test the system for all conditions.
62. Are you looking for examples in just application security or also infrastructure security?
Yes, please demonstrate both the Application and infrastructure with examples.
63. What are the underlying technologies for data storage currently? Are these likely to change in the (near future)?
There are no underlying technologies for data storage at the moment. We archive our data on spreadsheet files on a shared filing system. System should be able to migrate the existing data to the new system.
64. Will relevant internal staff be available to assist the development team during the prototype phase? (Both business & technical)
65. Do you have a preferred cloud provider i.e. AWS, Azure, etc? Who will manage this relationship the buyer or the supplier?
No, it can be any cloud provider which meets the requirements. We will expect the contractor to help us decide the best approach.
66. Given the users are primarily Programme Managers, please give examples/interpretation of the users who would fit into this requirement; “users with low digital literacy”.
Current users are familiar with the basic use of MS tools (e.g. the entry of data/information into cells in spreads sheets). The system solution will need to follow clear and easy to understand ways of entering and retrieving data, and running reports.
67. Is this something that the department was to be able to support themselves or are you looking for a managed service model?
The department is looking for the development of a tool that can be mostly self-sufficient (i.e. admin can edit requirement fields, add users etc.), however, we would look to the supplier to advise on relevant models most appropriate to BEIS needs.
68. During the discovery phase, we assume that there were multiple hypothesis proposed. We wanted to understand how many of these were
a) data collection, organisation, report/dashboard/API development related?
b) access, management, evaluation, or risk mitigation (or other pieces related to governance) related?
c) any others?
We are unsure of what this question is asking. We will explore further in evaluation stage.
69. Is this role outside IR35 or inside IR35?
We would need to assess whether IR35 applies.
70. a) collection of financial and programme data from multiple organisations with varying systems/databases
You mention ‘collection of financial and programme data’ – please share data types/formats etc.?
By way of illustration typical data fields include:
a) programme data - Status, Activity name, delivery code, description, aims, country, region
b) financial data - forecast spend (by quarter), actual spend (by quarter), profile spend etc.
Fields range from numeric, alphabet, and code values.
We will be providing fuller detail at a later stage.