Change Management Strategy

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 Health Campaign Management (HCM) Programme rollout in Mozambique.

Approach for Change Management Process

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

• Receipt of change request from internal or external entities. This could be CHAI/NMCP or other partners and even eGovs own internal teams.

• Impact analysis of the change request by eGov team

• Negotiation/decision on 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 would establish 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 ensuring at the same time that decisions are traceable, made at the correct level, and that their impacts are fully analysed 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

C. Change Impact Assessment

After receiving the go-ahead from NMCP for the approved change requests, eGov will carry out an impact assessment of the change. The impact of the change will be carried out for the following parameters:

• Size of the change, that is, the effort required to incorporate the change

• Design considerations to ensure that the new feature introduced does not break any existing ones, remains scaleable, and interworks with existing functionalities

• The functionality being introduced should align with the product roadmap

• Schedule (Time required for incorporating the change)

• Release cycle where the change can be incorporated

The impact assessment report that would be submitted by the eGov team will include the impact on each of the sub-systems (if relevant) and other areas of the programme (if applicable).

D. Change Control decision

The results of the impact assessment exercise will be placed before the Change Control Board which will comprise of key stakeholders from NMCP, eGOV, CHAI, and other key partners. The Change Control Board can take the following actions with regard to a change request:

• Approve the change

• Reject/withdraw the change

• Defer the change

E. Change Incorporation

All approved change requests will go through the same development lifecycle phases and activities as the normal SDLC activities for a service on-boarding. As part of the change cncorporation process, the following activities will be carried out:

• Setting up a team for the incorporation of the change

• Identification of the ‘items’ impacted by the change

• Identification of the baseline impacted by the change

• Check out of the components on which change needs to be made

• Update work Item (code, documentation, test scripts, etc.) on which the change needs to be incorporated

• Testing to ensure change has been incorporated as per the requirements

• Regression testing to ensure that incorporation of the change has not impacted any base functionality

• Update baseline

F. Change Release & Closure

After the change request has been delivered, it will need to be approved by the initiator and the change control board will be marked as closed.

Before release, the CI shall be checked-in and baselined. Work products for internal use would also be baselined after modification. Revision history will be maintained for each baseline, which would also have the description of the CI's it contains, and the modifications done. The approved CI's will be baselined and placed under (checked-in) configuration management.

G. Deliverables from the change management process

• Change register/log

• Change impact assessment document

• Change control board decision stating the reasons for approval/rejection/deferment

• Release notes