Overview

This training plan provides a systematic and consistent approach to train the master trainees on the usage of the Salama app (DIGIT HCM application) and its various modules and functionalities for the seasonal malaria chemoprevention (SMC) campaign at Nampula. The master training of trainers (ToT) will be conducted at Maputo for three days.

Participants

• SMC Technical Working Group (Inclusive of NMCP, DIS, DTIC and MC). Number of participants - 12.

• eGov trainers.

Training Curriculum

The training will cover the following topics:

• Introduction to the mobile device and its basic usage

• Salama app and its various functionalities

- Registration & Distribution

- Inventory Management

- Supervision checklists

- Complaints module

• Troubleshooting guidelines

• Program SOPs (User management and help desk)

• Assessment

• Feedback

Training Assets

eGov Foundation will create the training material in English and Portuguese, and the Malaria Consortium will review it. The training materials will include Powerpoint presentations covering all the modules and functionalities as listed in the curriculum. The reference material will be provided in a soft format to conserve paper and stay environmentally sustainable. The app training will be conducted on the personal phones of the master trainers.

Training Plans

Training Prerequisites

1. Training venue/hall with internet connectivity with a capacity of hosting 20 persons.

2. Projector

3. Mic (4)

4. Refreshments and other basic amenities for trainers and trainees.

5. Extension cords (5)

6. Pre-filled registration sheet

7. Agenda printout

8. Training materials soft copy.

9. Training setup/infrastructure readiness on cloud.

10. Training instance setup in the cloud with master data from previous campaigns.

11. Creation of login for different personas in the system for the training.

12. Laptops for the participants (participants to bring their own).

13. Internet

Cost Heads

1. eGov’s staff travels, accommodation and transport will be managed by eGov.

2. All other costs will have to be discussed and agreed upon.

Day-Wise Schedule

Objective

The purpose of change management is to implement processes for effecting change, controlling change and helping the project teams to adapt to change arising out of various internal and external factors. This document seeks to outline the change management strategy for the HCMP rollout in Mozambique.

Approach for the Change Management Process

All activities that require a change in the agreed scope shall be handled through the change management process. The following activities will be executed as part of change management:

• Receipt of a change request (CR) from internal or external entities. This could be CHAI/NMCP or other partners as well as eGov's internal teams.

• Impact analysis of the change request by the eGov team.

• Negotiation/decision on the change request implementation.

• Change implementation

• Change tracking

• Change version control

• Change release and record management.

The initiator of the change request will have to formally raise a request for a change mentioning the relevant details. eGov as the platform provider will establish a change control processes to manage changes to the agreed scope and other dimensions within the project. The process will capture all requests for change while at the same time ensuring that decisions are traceable, made at the correct level, and that their impacts are fully analyzed and absorbed.

We propose to follow the listed change management procedure:

A. Change Initiation

Any request received to make changes in the project scope will be logged as "Change Requests" and compared against the agreed scope and the schedule baselines for the project. The reasons for the change request could be due to one of the following drivers:

• Changes in the business environment

• Changes in functional requirements

• Changes in technical specifications

• Changes in system design

• Changes in technology

• Changes in volume and load projections

• Changes in personnel and staffing, and their roles, etc.

• Changes in the times and schedule which may necessitate scope changes

B. Change Registration

All change requests raised will be logged in the ‘Change Register or log’ which is expected to be maintained jointly by the EGOV and CHAI project coordinators. This will help maintain a consistent log of all change requests that are raised. The Change Register will be shared at least on a fortnightly basis with all stakeholders.

The Change Request Note (CRN) will describe the change:

• Scope of the change

• The rationale for the change

• The estimated benefits expected to accrue from the change,

• The priority and importance that is attributed to the implementation of the change

• The estimated time within which this change is expected to be applied

Overview

The Ministry of Health(MISAU) in Mozambique is implementing the Health Campaign Management (DIGIT-HCM) platform in Mozambique with support from eGov. A helpdesk has been proposed to receive, log, prioritise, assign, track, escalate, and resolve hardware and software-related issues raised during the campaign which impede campaign operations.

The helpdesk team will be based in Nampula to ensure easier coordination with the provincial teams who are responsible for distribution. For resolving technical issues or queries in the Salama (DIGIT-HCM) platform, there will be 1-2 members from eGov based in Mozambique to support the helpdesk staff of MISAU. eGov will set up a remote support team (also referred to as level 3 support), located in Bangalore, to resolve issues that the local helpdesk team in the Nampula is unable to resolve. The helpdesk will become operational a few days before the start of the actual drug (sulfadoxine-pyrimethamine and amodiaquine or SPAQ) distribution activities as proposed by the NMCP and will remain operational for a few days after the distribution.

The helpdesk will operate between 6.00 am till midnight (12.00 am) Mozambique time (CAT) and a roster needs to be maintained for the entire duration for the local team (Layer 2 support in Mozambique) as well as the remote support team (Layer 3 team based in Bangalore).

Scope of the Helpdesk Support

• Technical support on hardware and software (for Salama- DIGIT HCM platform only).

• Resolution of general how-to queries relating to the Salama platform with the help of a FAQ document that may arise from the field.

• User management: Creation of the users (named users who access the platform using their individual usernames and passwords) using the user management module of the Salama platform, and helping the field users with the required information if they forget the user names or passwords.

• Master data management: Uploading the master data in the platform and updates to Master data if the list of villages change during the campaign.

Examples of the queries to be handled by the helpdesk:

1. Issues with the application or the dashboard functioning.

2. Login or password not working or forgotten.

3. Creating new users, if any, due to field staff getting changed during the campaign.

4. Updating new localities or villages in the system during the campaign.

Operational/Programmatic Queries

The operational/programmatic queries received by the helpdesk will be redirected to NMCP officials by the level 2 support team.

Examples of operational or programmatic queries (to be routed to NMCP):

1. Not having sufficient stock of drugs.

2. Not receiving the device or any loss of device in the field.

3. SPAQ quality issues.

4. Logistic issues related to the distribution of SPAQ.

5. Any issues relating to the SPAQ distribution process as outlined by the NMCP.

Helpdesk Workflow

The typical lifecycle of a helpdesk ticket starts when an issue is received and ends when a ticket gets closed. The below representation shows how the helpdesk ticketing management system will work. In this representation:

• The WhatsApp groups of registrars, LMs and district supervisors will play the role of level 1 support.

• The helpdesk team based in Nampula will play the role of level 2 support.

• eGov technical support team (based in India) will play the role of level 3 support.

• For the issues which are not related to scope of the helpdesk, the helpdesk team will redirect the issue (over call/ WhatsApp) to concerned NMCP officials for further communication and resolution.

Raising Tickets

The helpdesk staff will use the grievance portal (complaints module of the Salama app) to record every incident or grievance that is reported to them. The helpdesk staff will be able to login with a dedicated user ID and password and log a complaint by raising a ticket against it. The login credentials will be generated from the backend and provided to the identified users.

Support Levels

Modes of Communication

Phone calls & WhatsApp messaging:

It has been observed from the previous campaigns that users in the field (that is, the distribution teams) often reach out to local monitors (LMs) and district supervisors for simpler queries over a phone call or WhatsApp communication for quick resolution of their queries. This is deemed as the level 1 support in this document. The district supervisors escalate more complex issues to the helpdesk team again, over phone calls or whatsapp group communication. Usually the provincial focal points create a WhatsApp group during provincial ToTs and add the relevant members. The same approach would be followed for the SMC campaign in Nampula When the issue gets escalated from district supervisors over a phone call or WhatsApp message, the helpdesk team (level 2 team) will record them in the complaints management tool.

Ticket categories

Following categories of incidents are envisaged to be logged at the helpdesk. Each incident category will have its independent process of resolution as defined in the SOP section of this document.

Level 2 helpdesk operating dates and timings in the Nampula.

The helpdesk will be operational for the below mentioned duration.

Dates: Starting from 7-Aug-23 till the end of the SPAQ distribution.

Mozambique: 6:00 am – 12.00 am CAT (midnight).

Ticket Tracking

The primary goal of the helpdesk is to restore normal operations at the earliest possible, and with a minimum impact.

Critical app-related issues that cannot be resolved within the campaign duration will be shared with eGov which will be picked up immediately after the campaign for review and resolution.

Enhancements (major and minor) will go through a change request process. Due to the nature of the project, there will be no feature updates to the DIGIT system during the campaign period. Any updates to the HCM application during the campaign window will be avoided as far as possible because it may be difficult to push the updates to all the devices and there may be data loss due to the same.

Helpdesk Team Composition

Roles and Responsibilities Between MISAU and eGov

Objective

The purpose of this document is to outline the User Acceptance Testing (UAT) process for the DIGIT-HCM platform rollout in Mozambique as part of the seasonal malaria chemoprevention (SMC) campaign in the Nampula province. This will enable the SMC campaign users to validate that the HCM software meets the agreed upon acceptance criteria for various functionalities. It will ensure that the system satisfies the needs of the business as specified in the functional requirements and provides confidence in its use. It will also help to identify the defects with associated risks and suggest enhancements (change requests), communicate all known defects/enhancements to the project team, and ensure that all issues are addressed in an appropriate manner prior to go-live.

Expected Results

At the end of the UAT, the following results are expected:

• Sign-off of the application indicating that the app meet the requirements gathered.

• Obtain feedback from the end users (Health Facility coordinators, Community Distributors and Community Distributor Supervisors).

• Verify if the application is able to do the functionality required to conclude the task of the Health Facility coordinators, Community Distributors and Community Distributor Supervisors (completeness functionality).

• Verify if the application is easy to use for the users (usability).

• Understand the areas that end-user may face challenges to improve the training curricula.

Summary of the UAT

UAT Methodology

UAT observation classification:

The UAT team will execute all the test scripts referenced later in the "UAT Feedback" section. Users may also perform additional tests not detailed in the plan but remain relevant and within the scope of the project.

Users will report the feedback to the eGov team for documentation and escalation using a Google sheet. These defects will be described, prioritised, and tracked by using screen captures and steps necessary for the development team to reproduce the defect. For change requests, the requirements will be described, analysed, prioritised, and tracked.

Test Phases

The various phases of UAT are shown in the below diagram:

Scope for UAT

UAT will be conducted in 1 phase with the below mentioned scope

Out of scope of UAT

For the below mentioned functionalities, separate demo and/or training sessions will be conducted for the targeted user groups.

1. Help desk for complaints and user management

a. User Management module to add/update/ activate/deactivate users and role mapping

b. Handling complaints via inbox functionality

1. Central, Provincial, District dashboards and reports.

During UAT , the team will validate the end-to-end flow and features of the application as listed below:

• End-to-end business flow for each of the identified user flows

• All the required fields are present

• System is accepting only valid values

• User can save after form filling all the mandatory fields

• Correctness of label and its translations

Prerequisites for UAT

Following is the list of prerequisites for conducting the UAT

• The HCM Mobile App for UAT deployed in the UAT environment

• Mobile phones setup with HCM app.

• Configuration of HCM Mobile App in UAT environment with master data from Nampula

• Readiness of handouts

- Test Case document

- Mockups

- Defect/Change request reporting template

• Availability of teams from SMC TWG (Technical Working Group) and SPS for UA testing

• Nomination of participants for the UAT session so that test accounts can be created by eGov.

UAT Environment

The UAT environment will be similar to the production environment in terms of specifications, and will be provided by eGov, so that accurate assumptions can be drawn regarding the application’s performance.

UAT Process

Each test participant will be provided with a checklist to verify access to the applications within the defined scope of testing. The tester will then login, perform the prescribed steps, and generate the expected results for each activity. Any feature identified as missing or bug during testing from the UAT environment should be reported back to eGov.

UAT Data

Access to the test data is a vital component in conducting a comprehensive test of the system. All UAT participants will require the usage of test accounts and other pertinent test data which should be provided by SMC TWG upon request. The user roles should fully emulate production in the UAT path. The test accounts and role mapping shall be done for the users identified by eGov. Following are sample test data for UA testing:

• Sample Master Data

- Users data for test login creation

- Location master (AP/Locality/Health Facility/Village )

- Micro Plan of a district

Roles and Responsibilities

SMC TWG

• Nomination of stakeholders for executing the UAT

• Verification of product based on UAT scenarios

• Decision regarding date and venue

• Providing feedback after the UAT session and sign off

eGov

• Readiness of HCMP with required features

• Demo to SMC TWG before the UAT event

• Framing test scenarios

• Creation of UAT Plan

• Collection and triaging of the UAT feedback

• Translation of UAT feedback

NMCP

• Arrangement of logistics-Venue

• Addressing costs for all the government personnel involved in the UAT

MC

• Providing feedback after the UAT session

Nampula SPS

• Availability of the end users for SMC

• Access to the HF

UAT Team

The test team is composed of members who possess a knowledge of the operations and processes on the ground.

1. These team members will be able to initiate test input, review the results,

2. Have prior experience/learnings from SMC campaign digitisation in Mozambique

All team members will be presented by the eGov team with an overview of the test process and what their specific role in UAT will be. The eGov team will oversee testing by assigning scripts to testers, providing general support, and serving as the primary UAT contact point throughout the test cycle.

Note: The above table needs to be filled by SMC TWG with the details of the nominated participants of the UAT session.

UAT Deliverables

The following sections detail milestones crucial to the completion of the UAT phase of the project. Once all dependent milestones have been completed, NMCP/DIS/DTIC will formally sign-off on the system’s functionality and distribute an email to all project stakeholders.

UAT Activities and Schedule

All core UAT activities along with the deliverable dates are described in the below table:

UAT Session Structure

The UAT session will be conducted hybrid, in Nampula and remotely using Zoom Meeting. The detailed plan for the UAT session is as follows:

For the CRs identified during UAT, the standard change management process will be followed.

UAT Sign off

• The mutually agreed defects/CR from UAT will be discussed in the post- meeting.

• The sign-off shall be provided at the end of UAT by SMC TWG via an email communication.

• Post sign-off the application will be ready for the deployment in the production environment.

User Acceptance Test Cases

Test cases provide a high-level description of the functionality to be tested. All regression and new functionality test cases are contained in the Excel spreadsheet “UA Test Cases” to be shared before.

The team will leverage relevant QA test cases for project specific functionality. Each test case based on new functionality will reference a specific functional requirement.

Each script contains the test case number, test description, requirement number, action to be performed, test data to be utilized, expected results, error descriptions (if applicable), pass/fail results, date tested, and any additional comments from the UA tester.

The UA test scripts are contained within the UAT test case spreadsheet and can be accessed via hyperlink from each individual test case.

UAT Feedback

Defects and change requests will be entered and tracked in Google sheet by any member of SMC TWG during the UAT process. Each entry will include detailed information about each defect/CR.

UAT Defect/CR Tracking

Test team will be provided with instruction on how to effectively execute test scripts, as well identify, capture, and report defects/observations by the eGov team at the beginning of the UAT session. The test team will present their findings during the UAT session.

UAT Defect Life Cycle

Defects must be clearly captured and escalated to ensure prompt resolution by development. Each defect submitted by UAT will be assigned a priority, worked by development, resolved, and re-tested by UAT prior to closure. The following is a snapshot of the standard defect lifecycle:

Prioritisation

the SMC TWG together will prioritise and classify defects. Defects found in UAT can be assigned one of three (3) levels of severity:

• P1, Work Halted – Testing defects that due to the complexity of the function or the scheduled dates are putting the implementation date at risk. No workaround exists.

• P2, Work Slowed – Testing defects occurring in a less complex function of the application with sufficient time to resolve before the implementation date – but must be implemented as scheduled. A workaround has been identified and is listed in the defect.

• P3 and lower, Work Unaffected – Testing defects occurring in a function that are simple to fix or could be excluded if not resolved by the scheduled implementation date.

Response (acknowledgement of the issue) Commitments for Defects

As a non-profit, we are unable to make any commitment on how long issues will take to fix and deploy in production. We will endeavour to resolve P1 issues as quickly as possible.

UAT Change Request Life Cycle

The change request must be clearly captured and reported for analysis to identify effort and Impact to the eGov team. Each CR submitted will be validated and categorised for acceptance and then assigned with a priority. The development team will work on it and will be made available for testing. Following is a snapshot of the standard CR lifecycle:

Categorisation

eGov in consultation with NMCP will decide acceptance and categorisation of change requests. Change requests found in UAT can be assigned one of three (3) levels of category:

• Must Have – Change requests that are needed for the success of a campaign. No workaround exists.

• Should Have – Change requests that are required for better tracking and monitoring and will increase the ease of use of the system for users. A workaround has been identified and is listed in the CR.

• Good to Have – Change requests that are simply for better visualisation and reporting. It could be excluded if not resolved by the scheduled implementation date.

eGov to endeavour to cover the "must have" changes before distribution. Lower priority changes will be taken through the eGov gating process for planning the subsequent releases.

Here are the articles in this section: