eSaude Change Management Process
Written: 2017-12-21
Last update: 2018-01-31
Authors: Jan Flowers, Valerio Joao

The following is the result of an analysis of our overall change management process:

1) Requests can come from multiple avenues for multiple reasons
  • Emails, phone calls, in person discussions from the MOH, CDC, IPs, and Health Facilities
  • Chat communication channels – slack, skype, whatsapp
  • During troubleshooting by helpdesk or others, during implementation at health facilities
2) General requests are tracked in Desk.com by the Helpdesk team
3) Classification of those requests will be based on request type, urgency, impact:
  • Request type: bug fix, changes to data elements and/or workflows, new features
  • Urgency:  Patient Care/Safety, Job Stopped, Job Function Affected, Needs addressing but not affecting job
  • Impact: Single, Multi, Software Wide
4) Escalation of requests occurs according to prioritization and service level agreements
5) For changes or new feature requests, these requests will be prioritized in collaboration with CDC and MOH 
6) Requirements gathering and specification documentation: We get to know the change requests that have been prioritized. This can be done in a variety of ways but often we do:
  • Spend time with stakeholders to document requirements and gain buy-in for scope: interviews, direct observation, mockups, etc.
  • Meetings with MISAU where we go through the demo and participants recommend changes that are discussed and agreed.
  • Change requests are analyzed by the dev team and further discussed with the owners if necessary, for example we had Flávio for a couple of times in our office to discuss the last MISAU requests.
7) For larger projects involving multiple requirements, we create a spreadsheet with all the requests in form of software requirements. See the first format here, and lately we use CDC EPLC Requirements Traceability Matrix format customized for better tracking, see the documents based on CDC review here and the latest MISAU requests here.
  • The requirements spreadsheet is then sent to the client for prioritizing tasks within the broader request. If not done by the client we use our own prioritizing criteria described in our dev process, based on complexity and dependency.
8) The next step is to create a change log for tracking. This is done by:
  • Linking each item in the RTM with corresponding item in the Requirements and Specs document. The req/specs document details what the new changes are in the software business logic and contains a change log table on top, and we use google docs to benefit of the change history feature provided, see example here.
  • Create a trello card that is linked with the requirements for the changes, and a github issue with a proper label and linked to the trello board, see example here.
  • Changes in the software are tracked using Code Commits, those commits have the proper description and the ID of the request that the code is solving. Status update is done automatically in trello and github and manually in the RTM.
9) We use the different reports and meetings with CDC and MISAU to discuss priorities and inform the progress.
10) In preparation for release, usability/UAT tests performed by MISAU, CDC or IPs that are also discussed and agreed 
Version Control
Note: For development over the next year, I would recommend releasing updates to the POC system on a regular schedule – monthly for the 1st 6-months, quarterly after that.  We will follow the versioning process we currently use (http://bit.ly/2z818Hy )
  • major, minor, patch or a specific semver version (like 1.2.3). This command basically just changes the version in the package.json file. The options will have the following effect:
  • major will increase the first number in the version and set the others to zero
  • minor will increase the second number and set the last one to zero
  • patch will increase the last number
Releases will be available centrally for download.  Updates will be managed by implementation staff, IPs M&E staff, and support by the UCSF Helpdesk when needed.

In google doc here: