BD4SG implementation - Key considerations
The following diagram provides a baseline implementation project view for BD4SG initiatives where mobile big data is a core enabling component.
The model is not intended to be exhaustive - some services may contain/require unique components not reflected here. However it does indicate the key stages of development for participants wishing to engage in such an activity. The accompanying text highlights some of the key considerations at each stage for a BD4SG implementation; a major consideration that applies to all the activities described is that to realise a successful solution requires continuous active engagement from all parties.
The implementation timeline begins with a baseline view of a BD4SG pilot, and then evolves from pilot to production service.
The model is structured such that the considerations for a pilot are also used as foundational steps for delivery of an ongoing BD4SG service. The move from Pilot to Production therefore will likely require a number of the pilot stages to be revisited.
… to production
1. Define problem statement
Define problem statement
Successful BD4SG initiatives begin with a clear, addressable need. This must be identified, or at least firmly verified, by the demand-side party.
2. Legal and Procurement
Legal and Procurement
It is important that legal and procurement teams’ input are sought throughout the pilot phase, and also when moving to production. The transition to production may require a specific RFP stage, which can be protracted. Details of this depends on the stakeholders involved. Note: this is linked to the ‘funding consideration’ stage (see below).
3. Funding consideration
A funding commitment is an important consideration for BD4SG services. At the outset, it provides an incentive to the market to support the development of new capabilities to address demand-side challenges, and post-pilot to provide the investment required to move from pilot to production service. The financing available might impact what is feasible.
4. Initial set up and problem definition
Initial set up and problem definition
Building on the demand-side need, clarify the problem statement. This could be a testable hypothesis, or an outline of the problem and the requirements for a solution. This is usually an iterative process, requiring collaboration between both demand-side and supply-side participants. Key activities include the identification of stakeholders, sharing of prerequisites for solution development (e.g. adherence to a shared code of conduct for data protection) and agreement at headline level on core activities or outputs (e.g. outline methodology for solution development, agreement on the outputs expected at the end of pilot phase etc.).
5. Privacy, Ethics and Harm assessments
Privacy, Ethics and Harm assessments
Privacy and ethics are key considerations throughout the development of BD4SG services. A harm assessment should be performed as a matter of course, ideally as an intrinsic part of the design stage. Privacy by Design principles should be included from the outset for example, via completion of a privacy impact assessment. There should also be a formal evaluation and review at the end of the pilot phase, as part of a long-term iterative process.
6. Scoping and design
Scoping and design
In more granular detail, outline the system and outputs required to answer the demand-side need question, i.e. design the system to turn data into actionable insights. It is likely both this stage and the following technical development stages will be undertaken using an agile approach, with targets set and addressed in an iterative fashion. Key elements for a successful BD4SG implementation include a specification with an agreed definition of done, and a commitment from stakeholders of the necessary technical and human resources. Mapping of stakeholders, using an RACI matrix or similar tools, can be useful here. It is important to also consider the future scaling and sustainability of the service.
7. Contract or formal agreement
Contract or formal agreement
Develop a formal legal framework between parties to underpin the BD4SG activity. The details of this framework must be developed on a case-by-case basis, but may consist of a preliminary MoU, whilst a more comprehensive contract for provision of services is developed. The contracting process can be lengthy, and in practice, technical development will often begin before final contracting is completed. Note: This process may evolve as a project moves through the pilot phase, and could be revisited for the next phase.
8. Technical development
Develop the technical solution that will realise the transition from data to actionable insight. This will typically proceed in an agile fashion. The development phase involves the processing of operator and third party data, development of analytics, and publication of the outputs in a format that meets demand-side user requirements e.g. Decision support tools, Reports, App or Visualisation. Extensive commentary on technical requirements and processes for BD4SG are available in the technical section of this toolkit.
9. Implementation, testing & validation
Implementation, testing & validation
As part of an agile approach, the developed solution will need to be tested and validated. This is likely to be an iterative process, with revisions to the solution implemented as required. These could be error-fixes, additional functionality or improvements. Performance optimisation is typically included only late in the process, and may not be required at all in the pilot phase.
10. Training for users
Training for users
Experience from BD4SG implementations to date suggests the greatest value is realised when the demand-side user at the local level is able to apply and integrate the outputs to achieve their objectives. Training users early with real outputs in parallel to the implementation stage, serves to confirm for the development team that the outputs are fit for purpose. It may also highlight previously overlooked functionality that brings additional value, which can then be implemented in concert with the technical development.
11. Evaluate and review
Evaluate and review
Assess the output against the original demand. In the context of a pilot service, this includes checking the output against the original specification from the ‘scoping and design’ stage, and is a good opportunity to identify and record if further development is required.
12. Pilot validation
Building on the earlier ‘evaluate and review’ stage, pilot validation can pave the way to a production service. This involves rigorous testing of the outputs and assessment (versus the current approach, if applicable) to validate the effectiveness of the new BD4SG solution. For example, if the outputs are being used to inform a new health information system, external peer-review by subject matter experts may be expected. The assessment also needs to confirm whether the presented output can be integrated and the service can be operationalised.
13. Active deployment & operationalising
Active deployment & operationalising
It is likely this important stage will have multiple components, and it should be understood from the outset that it requires significant resource commitment from both demand-and supply-side participants. Indeed, the move from Pilot to Production will likely require a number of the above stages to be revisited as reflected in the baseline project view diagram. Key activities at this stage may include updating existing demand-side tools, and integrating the outputs into existing operational processes and associated technical systems. New working practices may need to be implemented on both the demand-side and the supply-side, and both will need to deliver operational support and training for users. Whilst governments are the primary customer for operator-led BD4SG services, it is important to emphasise that the scaling from pilot to a production service is driven by the demand-side; the government partner will need to lead the integration and change-management processes across their organisation and, therefore, will need to play an active leadership role across the engagement.
- Iterative Process