1

March 2019

Request for Proposals

Scorecard Software Development

“Scorecard Application”

2

Project Information

Across sub-Saharan Africa, health systems are making slow progress to save the lives of mothers

and infants. However, experiences in resource-constrained countries demonstrate that maternal

mortality can be reduced through the use of effective advocacy: deploying sound evidence to inform

and influence public opinion and holding decision makers accountable. Since starting in 2012, the

Evidence for Action (E4A) programme has used a combination of evidence to drive accountability for

maternal and new-born outcomes. The Evidence for Action (E4A) programme and its public face

‘MamaYe’ aims to improve adolescent and maternal health, new-born survival rates and quality of

healthcare.

E4A-MamaYe acts as a catalyst for action, using evidence strategically to generate political

commitment, strengthen accountability and improve planning and decision making at sub-national and

national levels. Advocacy is driven forward under the MamaYe brand, which augments the visibility

and profile of our reproductive, maternal, new-born, child and adolescent health (RMNCAH) work and

channels the collective energy and investments of others committed to improving RMNCAH

outcomes. E4A-MamaYe has worked intensively in Ethiopia, Ghana, Kenya, Malawi, Nigeria, Sierra

Leone, and Tanzania, reinforcing national level advocacy through engaging in regional and global

advocacy campaigns and accountability platforms. Currently we have country offices in Nigeria and

Kenya and support the work of advocacy coalitions across the region.

Options Consultancy Services Limited was established in 1992 and is a wholly owned subsidiary of

Marie Stopes International. We are a consultancy organisation providing technical and management

expertise in the health and social sectors to governments and international development partners to

transform the health of women and children. We provide information, expertise and influence to

governments, health workers, NGOs and businesses to catalyse change so that health services can

be accessed by the people who need them most.

Background

Across sub-Saharan Africa, E4A-MamaYe and other Options programmes are supporting data for

decision-making: presenting data on key health and health financing indicators in visually engaging,

attractive and easy to read ways so that the information contained can be used in decision-making

processes. The main output of this process is often a “scorecard”, which presents a range of different

indicators alongside a traffic light system. These scorecards are often paper-based with the

production and design happening in London. The overall aim and purpose of this consultancy will be

to provide scorecard application software that allows our partners to manage and create the

scorecard in situ, with no need for the extensive design and production support from the London

office. We want to pilot this approach in Nigeria, with the finalised product being a “white app” that can

be adapted and used in other countries and contexts.

Nigeria Context

In Nigeria, E4A-MamaYe supports State Led Accountability Mechanisms (SLAMs) to improve

accountability for RMNCAH outcomes. The SLAMs bring together different stakeholders – including

civil society and government representatives – to review, discuss and act on core health indicators. In

Nigeria E4A-MamaYe currently supports SLAMs in Bauchi, Gombe and Lagos States.

One of the main functions of the SLAMs is the production of scorecards. Developed by the SLAMs,

the scorecards track several health indicators using a simple traffic light format for easy reading,

understanding and interpretation: green means “good progress”, yellow means “some progress” and

red means “insufficient progress”. At present, the SLAMs produce up to 6 different scorecards at

least twice a year:

3

1. Maternal Newborn and Child Health (MNCH) Scorecard

2. Health Facility Maternal and Perinatal Death Surveillance and Response (MPDSR) Scorecard

3. Stockout of Essential Life-saving Commodities in Secondary Health Facilities Scorecard

4. Stockout of Essential Life-saving Commodities in Primary Health Facilities Scorecard

5. Health Budget Scorecard

6. Family Planning Scorecard.

7. Each scorecard has its own reference sheet. For example, this is the reference sheet for a

Lagos Family Planning Scorecard.

The data for the scorecards comes from government sources and other sources approved for use by

the government. This is recommended best practice and helps strengthen government processes,

especially the Health Management Information System (HMIS), by ensuring data collected through

these systems is regularly reviewed and used and attention is drawn to data quality issues. The

Evidence sub-committee of the SLAM is responsible for gathering this data (which is often entered in

an excel sheet) and then discuss and review them. E4A-MamaYe also create similar scorecards in

Kenya on a regular basis and in other countries in the region on a more ad hoc basis.

Scorecard Data Sources in Nigeria

• Maternal and Newborn Child Health Scorecard: draws primarily from the State Health

Information System 2 (DHIS-2).

• Health Facility Maternal and Perinatal Death Surveillance and Response Scorecard: draws on

data from quarterly checklist records collected across secondary health facilities.

• Stockout of Essential Life-saving Commodities Scorecards: draw on data collected from

quarterly stock-out surveys at Primary and Secondary Health Facilities.

• Health Budget Scorecard: draws on a range of data selected from the Ministry of Health,

Ministry of Finance, Ministry of Economic Planning Budget and Fiscal Responsibility

Commission etc.

• Family Planning Scorecard. The data for this scorecard come from a range of sources

including: Ministry of Health quarterly routine assessment reports; DHIS2; the Lagos State

Health Service Commission database; training reports and FP dashboards; private service

provider data sources etc.

E4A-MamaYe provides support to members of the SLAMs to determine which indicators to track; how

to collect and analyse data from different sources and use them to populate the relevant scorecards.

At present this collection and analysis is done using Microsoft Excel, with the finalised spreadsheet

sent to E4A-MamaYe in London who provide assistance in the design and presentation of the final

scorecard.

The scorecards document recommendations and “asks” for key stakeholders and target audiences.

These should, and do, vary according to the data available for the period. Each scorecard has a

relevant reference sheet, which provides information on the composition of indicators and relevant

data sources.

Purpose and rationale We are currently exploring digital solutions to ensure the sustainability of the scorecards, so that they can be created by SLAM members (and their equivalents in other countries), to ultimately be fully owned by the SLAMs without the need for support from E4A-MamaYe and Options programmes. A digitised scorecard system has the potential to:

1. Strengthen the project management of scorecards from development through to production

and dissemination.

4

2. Provide a means for the SLAMs and their equivalents in other countries to own the design

and distribution process, without the need to use specific (and expensive) design

programmes and external support.

The product will continue to be a simple scorecard format, with a traffic light system against key indicators and recommendations and “asks” summarised for target audiences. The scorecard development software will first be developed and piloted in Nigeria with the SLAMs but should be adaptable for other countries and contexts.

User Journey

To inform the development of this tender, we consulted with the SLAMs to draw up a “User Journey”

that details the process currently used to develop the scorecards and how this would be incorporated

into the scorecard development software. See Figure 1.

5

Figure 1: Use Journey Map:

6

It is envisaged that the Provider will develop an application that mirrors the user-journey outlined in Figure 1.

Where the Provider thinks other options would be more suitable, they should consult with E4A-MamaYe

staff. Specific features and functionalities are outlined in the design and development requirements section.

Scope of Work

The overall purpose of this assignment is to develop and pilot a scorecard development software programme

for the management and production of the scorecard process. The successful applicant will be expected to

develop a tool in line with the user-journey outlined in Figure 1, pilot with a mechanism in Nigeria and make

necessary amendments based on feedback from that pilot.

E4A-MamaYe expects to work in close liaison with the Provider so that there is transparent and open

planning at each step of the way. In particular, we expect the Provider to advise on the most appropriate or

effective methods, approaches and technologies and to offer guidance on how best to present visually

engaging scorecards with the application.

The Provider will develop a web-based platform which can function on laptops, PCs and tablets. A mobile

version will also be developed, which will only allow users to view and navigate the scorecards, without

having the functionality to adjust existing scorecards or create new scorecards. The programme needs to be

available online and offline as internet availability is variable and inconsistent in the countries in which we

work.

The software will need to have built-in excel worksheet functionality.1 This excel sheet will be based on an

agreed template and set of indicators, which only users with a higher and specific level of admin access will

be able to modify.

The platform will be used by members of SLAMs (or equivalents in other countries), E4A-MamaYe staff in

the UK and country teams and technical experts of Ministries of Health.

The scorecard app will be delivered based on the following guiding principles:

I. Overarching principles and security of data and confidentiality:

1. The web platform and all rights to it must adhere to the Bill and Melinda Gates Foundation Global Access Policy 19 regulations2, must take into account Nigerian and European digital and data protection laws (e.g. permission to store data on a cloud or outside of the country), and must be aligned with the Nigerian eHealth Strategy (available at this URL: http://nitda.gov.ng/wp-content/uploads/2016/06/National-lCT-Policy.pdf.

2. The provider will be required to conform to global data protection security requirements and agree to ensure confidentiality of data; this will require anonymization of data before being sent to other data users (e.g. anonymising all data before it is sent to Options on behalf of E4A but retained for Ministries of Health). The provider will also be expected to have an agreement with E4A-MamaYe about what is stored on provider computers and cloud­based data backups where these must conform to European digital and data protection laws.

II. Design and development requirements:

1. The development and design will be guided by stakeholder needs i.e., the SLAMs through E4A-MamaYe. The Provider will be expected to advise on design and feasibility issues at every step of the process. Examples of prototypes or wireframes (mock ups) to be provided to agree next steps in development of different components of the platform. The development of a 'draft' or 'development' site would be necessary where different methods can be tested before being loaded to a 'live' site.

2. Issues identified will be raised immediately (within 5 working days) as they become evident to enable troubleshooting and mitigation. The provider will be expected to offer solutions that best meet the

1 For example, Piktochart has a built-in excel sheet. See from 0.50 https://www.youtube.com/watch?v=XiYXgALwNNw 2 http://globalaccess.gatesfoundation.org/?

7

user and E4A-MamaYe requirements and needs.

3. The final platform interface will be easily navigable, easy for users and incorporate user feedback.

III. The Design Features and Functionalities are outlined below:

1. To begin, the app will hold templates for the six (6) scorecards we currently support Nigerian states

to produce.

2. The software will need to have built-in excel worksheet functionality.3 This excel sheet will be based

on an agreed template and set of indicators, which only users with a higher and specific level of

admin access will be able to modify (modification includes the addition of new indicators or the

removal of indicators no longer deemed necessary).

3. The software should be able to hold data and create scorecards for all 36 states of Nigeria at one

time. The provider must note that Nigeria is the pilot country for this software and we will aim to

expand for different geographic locations. This will mean the software should be able to incorporate

and hold additional scorecard templates when we roll-out to other countries in the future.

4. In Nigeria, data are submitted to DHIS2 from all local government areas (LGAs). Each time a state is

selected, the app will need to automatically upload a list of LGAs in that state so that it is easy to

check how complete the data is. The scorecard should be flexible so that LGAs can be manually

removed if they are not covered by the scorecard.

5. The app should have the capacity to trigger alerts (see Step 1 of the User Journey in Figure 1.) by

mobile phone to different groups of people, including:

a. Members of SLAMS for every action that needs to be completed in the scorecard

development process such as initiating a new scorecard development cycle, arranging

relevant meetings and reviews.

b. Therefore, the app should have capacity to have a contacts database that complies with

local confidentiality regulations. This may take the form of WhatsApp group or similar.

6. Each state should be able to have a backend authorization. This means a dedicated authorized

person in the state will be able to have a back-end access to the state details in the application.

7. The app should be developed from scratch and not from plugin templates, as this will allow for ease

of modifications and expansion of the functionalities in future or as the need arises.

8. Colour codes and font sizes for the app should be determined, discussions between E4A-MamaYe

and the Provider will determine flexibility for colour choice and branding within the app.

9. The app should be able to automatically assign colour codes for different scores according to agreed

criteria (e.g. a score of >75% = green).

10. The app should be able to generate the finalized scorecard in a PDF format that can be printed and

also exported as an e-mail copy. The version of the scorecard for print will need a 3mm bleed

around it with crop marks for the printer. The e-mail copy will need to be without bleed. The Provider

should be prepared to discuss this with E4A-MamaYe alongside the size of the scorecards: either A4

or A3.

a. The app will have an inbuilt capacity to accept graphics (uploading of pictures and other

graphics) and upload these into designated areas - such as cover page photos and logos.

3 For example, Piktochart has a built-in excel sheet. See from 0.50 https://www.youtube.com/watch?v=XiYXgALwNNw

8

The Provider should be able to advise on whether pictures or graphics can be resized within

the app.

11. The app should include text areas where SLAMs members can add/edit information such as

explanatory references, and the section called “Asks” where advocacy messages are articulated

(see back cover of sample scorecards) etc. The Provider should be able to advise on whether text

size will be adaptable within the app.

12. There should be different access clearance for each level of users for those who will quality assure

the scorecard (Step 9 of User Journey) and for those who will have access to input/edit data in the

app (Step 4 of User Journey). The data should be agreed and finalised on the excel template before

being uploaded onto the software built-in excel functionality.

13. The software should have a pre-built checklist for individuals who will do a final validation before the

app translates to a finalized format. Until the validation checklists are signed off, the scorecard

design process will not move to the final stage of designing. This will help in eliminating error in data

etc. (Step 9 of User Journey)

14. The software should include a function that allows for a review of progress across different indicators

in scorecard produced in a state – producing a trend analysis against chosen indicators. If an

indicator or definition of an indicator changes, the app should flag this to the user, as this impacts the

validity of the trend analysis.

15. The software will have the functionality to be used offline, and for data to be downloaded/uploaded

when the user is able to connect to the internet. Data input and scorecard development will be best

done using a laptop or PC however the scorecards can be viewed on mobile phones.

IV. User Experience:

1. The platform will be designed to assure good quality (error-free) data entry, for example, by using drop down menus instead of free text fields where possible, use jump/skip patterns where appropriate, will force entry of a response or add prompts/ flags if fields are missed to reduce missing data fields where possible.

2. In line with E4A-MamaYe principles of high-quality and visually appealing presentation of data, the user interface will follow a colour palate, agreed by E4A-MamaYe but this should be adaptable for future versions of scorecards.

3. In line with E4A-MamaYe principles of high-quality and visually appealing presentation of data, the user interface will be laid out in a way that is easy to navigate. This may include having tabs at the top of the page, which logically separate data or group like data together. This is preferable to having a lengthy page that requires scrolling down.

V. Data Management:

1. The app will allow individual users from states to review and access the data inputted from their own states and health facility records (via an authorized-specific ID/username) and all data from all health facilities i.e. all facilities that the State authorities provide a user name / id to.

2. Periodically members of the SLAMs may choose to change indicators or add new indicators into the

scorecards. The platform needs to allow for this functionality to be included through an authorized process.

3. The app will allow for data to be entered into templates through Desktop/laptops (PC and Mac) and standard tablets offline and online and for scorecards to be viewed and navigated on Desktop/laptops, tablets and mobile phones. Where data is entered offline, records will be automatically updated when access to internet is available, with the integrity of all data maintained

9

even when tablets and desktop/laptops are offline.

4. The app will allow for centralisation and collation of all records from the different States. A mechanism to alert State-level authorities of updates – including the need for them to coordinate on inputs to the scorecard and, separately, notifying them that there are scorecards to review - should be defined and specified in the data management plan. This could be, for example, an automated email to alert specified email addresses on a regular basis of any inputs done with the application.

VI. Presentation of data:

1. The platform as a whole will be informed by a specific set of requirements for data entry and presentation of each variable that will be provided by E4A-MamaYe. This will include, for example: that E4A-MamaYe will be consulted on proposed designs for the platform interface and proposed outputs of data (e.g. charts and graphs).

VII. Sustainability/ training:

1. The final draft platform will undergo user testing, from between 5-15 users with guidance/ under the observation of the Provider before it is rolled out across the first pilot state. The system will need to be adapted to resolve any issues that arise during the user testing. These users should include E4A-MamaYe representatives (e.g. State Coordinator, Nigeria Country Director, London technical staff) and evidence sub-committee representatives of the SLAMs. The provider should demonstrate how it will capture user feedback and include this feedback in any revisions of the final draft platform.

2. All relevant data managers and users will be trained or orientated to the scorecard design platform by the provider, and detailed manuals will be developed by the Provider on how each of these types of users can use the platform and manage or access data.

3. The Provider will be expected to support planning for the sustainability of the system once the support from E4A-MamaYe to the users ceases. This may include, but will not be limited to:

a. Providing a summary proposal for short-term assistance that may be required following deployment of the app. This may include allowing for troubleshooting, response to queries raised by users on the management and functionality of the app.

b. Developing user-manuals (specific to the type of user and authorisation) that provide a clear “how to guide” for using the app. This will include a manual for Options Consultancy Services that details how the app can be tailored to different contexts and scorecards.

c. Providing a summary of the costs and relationships involved in running the app. This will be necessary for states / districts to have, especially where E4A-MamaYe support ceases.

d. Specify any considerations E4A-MamaYe should be aware of with regard to the use of the app where our support ceases and what this means for contractual relationships and ongoing provision of software support.

4. The Provider will develop a clear set of specifications of all resources, expertise and investments that will be needed to sustain and continue the web platform after the Provider contract has been closed. The Provider will be expected to deliver any activities and outputs relating to the sustainability plan and which can be achieved within the duration of this short term technical assistance. This could include, for example, further training of data enterers, data managers and IT personnel, possibly through a training of trainers model, and further orientation on accessing maintenance and troubleshooting support.

Expected deliverables and timing

The development process will begin in April 2019 with a view to concluding the pilot phase by June 2019.

E4A has proposed a workplan in Attachment 1, which the Provider should review and amend as appropriate,

submitting a final workplan with dates in their proposal submission.

Remuneration

10

The Provider’s payment shall be based on the financial proposal developed for this piece of work. Payment

shall be made in three instalments of:

(i) 25% payment upon submission of an inception report acceptable to Options

(ii) 25% upon submission of an acceptable Phase 1 report; and

(iii) 50% final payment upon submission of an acceptable Phase 2 report.

Qualification of consultants/Requirement for consultancy firms

• Professional qualification in software development and deployment.

• Possession of demonstrable skills in software development, specifically apps that are accessible on

web-based and mobile platforms.

• Previous experience in the conduct in developing and deploying similar software is essential.

• Ability to communicate technical concepts to a lay audience will be an advantage

• Experience of working in developing contexts will be an advantage.

Proposal Format

Consultants / agencies are requested to provide a proposal outlining the following in line with the detail

provided in the tender above:

1. Scope of work

2. Proposed methodology

3. Timelines

4. Staffing

5. Detailed budget breakdown

.

Proposals are requested by midnight, Wednesday 31st March 2019.

11

Attachment 1 – Workplan

Below is a proposed workplan.

Milestone #

Deliverable Responsible Deadline Start

week

Number

of days

Cost

Tender process 0 Agency chosen E4A-MamaYe 5th April 2019 Week

0-1

Contract signed 0.1 Executed Contract

E4A-MamaYe 12th April 2019 Week 2

Inception/ Planning phase

1 Submission of in-depth draft proposal detailing approaches, methods, tools and timelines as specified in these TORs, providing at least 3 working days ahead of an inception meeting.

Provider 19th April 2019 Week 3

1.1 Data management plan: Submission to the Provider of an in-depth data management plan outlining plan for data collection, documentation and metadata, legal compliance (GDPR) and data storage.

Provider 22nd April 2019 Week 4

2 Meeting with in-country team and SLAMs: deliver introduction presentation, gathering definitive templates, ensure consistency across templates.

E4A-MamaYe

/Provider

25th April 2019 Week

3-4

3 Initial Requirements gathering for developing specification, initial drafting of wireframes.

Provider 3rd May 2019 Week 5

4 Inception meeting to take place in country/London and/or by skype, which will include a presentation of deliverable (3).

E4A-MamaYe

/Provider

9th May 2019 Week 6

5 Final Technical Specification: document outlining the specifications of the system to be developed, addressing any comments by the E4A-MamaYeTeam.

Provider 14th May 2019 Week 6

Total inception/Planning phase cost TOTAL COST ££

Implementation:

Development

and testing

6 Development of Server Provisioning: a cloud- based server environment for configuration of the database. This will include setting up an agreed URL to access the server e.g. devscorecard.options.co.uk, security certificates to encrypt data flow traffic and a corresponding IP address.

Provider 14th May 2019 Week 6

7 Metadata Configuration: data/templates entry tools and forms

Provider 28th May 2019 Week

12

will be created and loaded into the database.

7-8

8 Developing 2nd round of mock-ups/wireframes based on deliverable (7). This includes:

Provider 31st May 2019 Week

7-8-9

8.1 Drafting of app layouts, headings, images, templates etc.

Provider 31st May 2019 Week

7-8-9

8.2 SEO optimization keywords and image tags selection.

Provider 31st May 2019 Week

7-8-9

8.3 Front end experience review/approval Provider 31st May 2019 Week

7-8-9

10 System Testing and Feedback meeting to take place in country/London and/or by skype, which will include a presentation of deliverable (3).

E4A-MamaYe

/Provider

4th June 2019 Week 9

11 Implementation based on deliverable (10).

Provider 11th June 2019 Week 10

12 Integrated System Testing and final sign-off: Fortnightly briefing meetings by phone/Skype to provide updates on progress and/or agree sign off.

E4A-MamaYe

/Provider

18th June 2019 Week 11-

12

13 First level sign off. E4A-MamaYe

20th June 2019 Week 12

14 Test with SLAMs. E4A-MamaYe

27th June 2019 Week 13

15 Test for functionality, integration, user friendliness and absence of bugs and malwares.

E4A-MamaYe

/Provider

27th June 2019 Week 13

16 System Testing and Feedback meeting to take place in country/London and/or by skype, based on deliverable (14) and (15).

Provider 4th July 2019 Week 14

Implementation based on deliverable (16).

Provider 11th July 2019 Week 14-

15

17 Final check from E4A E4A-MamaYe 12th July 2019 Week 15

Total implementation: development and testing phase TOTAL COST ££

Documentation 18 Technical specifications: A final technical specification document highlighting methods/tools updated from those specified in deliverable (5), and including any recommendations or suggested next steps to consider for longer-term sustainability.

Provider 19th July 2019 Week 16

13

19 System Administration and End User Documentation: a final user guide/manual for each different type of user (administrator level) of the system. This will include a separate document with all access rights for all levels of administrators that will be held by the E4A-MamaYe team leader and the E4A-MamaYe technical lead

Provider 19th July 2019 Week 15-

16

20 Production server provisioned: cloud-based live server set up for use, including SSL certificates and appropriate live URL for access.

Provider 19th July 2019 Week 16

Total documentation TOTAL COST ££

Training 21 Data Managers and Users Training: Training plans/user manuals and any guides needed to be provided in advance of training/orientation sessions held for users of the system.

Provider TBC

22 Refresher training: Any additional refresher training documents /plans /manuals to be shared with client in advance of training.

Provider TBC

(from

6months

to 1 after

launch)

TOTAL TRAINING TOTAL COST ££

GRAND

TOTAL

TOTAL COST ££

14