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.
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:
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
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
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).
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
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
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.
Change register/log
Change impact assessment document
Change control board decision stating the reasons for approval/rejection/deferment
Release notes