Change Management Policy

Purpose

To establish a systematic and controlled approach for managing changes to software systems throughout their lifecycle. This policy aims to minimise risks, enhance stability, ensure compliance, mitigate regression and foster effective collaboration.

Scope

This policy applies to all employees and contractors associated with the development of the ecoPortal product (web application and mobile offering), consisting of software engineers, product managers, business analysts, quality assurance engineers, and contractors with access to ecoPortal source repositories, system resources, and change management tracking softwares.

Policy

Change Request Process

Any proposed change to the software product must be documented through a formal change request via relevant work tracking software, via Trello board relevant to the nature of the request or high level documents on Confluence for larger requests.

Exceptions to formal change request documentation are permitted in extreme circumstances where system reliability or performance is adversely compromised and changes are actioned by relevant area lead(s).

The change request should include a clear description of the change, its impact on the system, and for functional changes; the business rationale for the change.

Change requests should be submitted to the designated change management team or authority for review and evaluation.

Change Evaluation and Prioritisation

The change management team will assess the potential impact, benefits, and risks associated with each change request.

Changes will be prioritised based on their urgency, business value, and alignment with strategic objectives.

Change Approval and Planning

Approved changes will undergo further analysis and planning, including resource allocation, scheduling, and potential dependencies. Larger change requests will be refined through detailed level requirements on Confluence.

Change implementation plans will be documented, outlining the necessary tasks, timelines, and responsible stakeholders. These will be made available via Atlas.

Development and Approval

Changes will be made in accordance with the Secure Development policy and adhere to all coding guidelines. Changes will be regular committed into source control via GitLab. All changes will be reviewed and approved by relevant area leads or multiple engineers in that area before release candidacy is considered.

Testing and Validation

Changes will undergo comprehensive testing, including automatic unit testing, integration testing, and system-wide regression testing via internal quality assurance teams.

Test results and validation documentation will be reviewed and approved before proceeding to deployment.

Change Deployment

Changes will be deployed in a controlled and staged manner, following established procedures and guidelines.

Rollback plans and contingencies will be in place to address any unforeseen issues or failures during deployment.

Communication channels will be utilised to inform stakeholders about the upcoming changes and their potential impact when required. All released changes will be communicated to wider stakeholders.

Impacts to the wider system will be taken into account when scheduling change deployment and where relevant, wider customer communication and warning.

Documentation and Auditing

All change requests, approvals, plans, test results, and related documentation will be properly recorded and maintained in relevant tools, this includes but not limited to work tracking tools, source code repositories, document storage, chat applications, and test tracking tools.

Where required, any relevant project documentation, such as the project scope, risk register, or configuration management system, will be updated to reflect the approved change.

Continuous Improvement

The change management process will be periodically reviewed, evaluated, and refined to optimise efficiency, effectiveness, and responsiveness.

Lessons learned from past changes will be shared, and best practices will be identified and incorporated into future change management activities.

Change Management Team

Designated change management teams are made up of at least the following roles:

Feature Requests, Functional Changes:

1. Affected area lead(s)

2. Product manager

Security patches, Infrastructure Changes, Compliance Updates, Integration Changes:

1. Affected area lead(s)

2. Head of Engineering or Chief Technology Officer

Bug Fixes, Performance Enhancements:

1. Affected area lead(s)

Exceptions

Requests for an exception to this policy must be submitted to the Head of Engineering or Chief Technology Officer for Approval.

Violations & Enforcement

Any known violations of this policy should be reported to the Head of Engineering or Chief Technology Officer. Violations of this policy can result in immediate withdrawal or suspension of the system and network privileges and/or disciplinary action in accordance with company policies up to and including termination of employment.