This document outlines the processes to be followed for implementing system changes or fixes within the Network Delivery Project programme (NDP) or any alteration of critical systems and/or processes, IT hardware or software, telephony or network infrastructure.
It is the responsibility of all staff and managers that these procedures are followed. No change authorisation = no change takes place.
Purpose
To maintain integrity, security and availability of systems and processes/procedures there needs to be a robust and mandatory Change Control procedure in place to control the required amendments, enhancements and changes to existing systems and services, as deployed across the two trial regions.
- To collate, assess, approve and track all changes to NDP baseline systems, processes and procedures throughout the NDP trials, with appropriate performance metrics.
- To enhance communication of change, provide standards to the expectations of communications, and review processes for validating change.
- To ensure that NO changes are applied without the correct authorisation.
- To ensure that all relevant stakeholders are aware of changes and ensure any processes/ procedures/ documentation/ asset register/ information that requires updating is appropriately updated and all relevant parties are aware of the change and its implications.
This document outlines the change management procedure expected to be adhered to by all employees of FHS.
Scope
This procedure applies to all staff and volunteers involved in NDP.
All changes, new services, enhancements or amendments to ANY system or service which Volunteer Operations (VolOps) and Fundraising, Marketing and Communications (FMC) manages as part of NDP, including third party systems must go through the change procedure.
Aim
The aim of this procedure is to establish a standard process for requesting, planning, communicating, approving, implementing and reporting changes to FHS services and systems.
Roles
| Roles | Description |
|---|---|
| Change Requestor | The person raising a request for change, using
the Change Request Form |
| Change Owner | Person who ensures the assessment,
prioritisation, scheduling communication and delivery of the change |
| Change Implementer | Person who creates, builds, tests and deploys
the change |
| Change Manager | Person who administers the change process, ensuring all necessary process steps are completed and improvements are raised, when necessary, with Process Manager |
| Change Management Team (CMT) | The group/body who exist to support the
authorisation of change and to assist in the assessment, prioritisation and
scheduling of change, resolving priority conflicts. |
Procedure
Stage 1: Change Request – propose a change with supporting information
The change control procedure begins with a Change Request essentially a proposal using the required Change Request Form (CRF) shown at Annex B. The information on the CRF shall detail the type of change (see table below) being proposed and address aspects such as the scope of change, objectives for the change, targets to be met (including dates) as well as technical and organisational impacts that the change will bring about or may have.
A change proposal can be initiated by any member of staff, but it almost certain that they will need to consult with others in their management chain to gain the information required before submission of the CRF.
The change request should also estimate the change's importance or value to the business as well as steps to evaluate its success
| Change Type |
Definition |
|---|---|
| Standard | A routine change that is low risk, relatively common, and follows a
pre-defined procedure. For a Normal change to be upgraded to a standard change, it must have been completed successfully three times as a normal change and the procedure documented. The creation of the standard template requires approval by the change manager. |
| Normal | A change to an existing service, system, application or infrastructure
component with potential impact which may require approval before being
implemented. |
| Priority | A change that must be implemented as soon as possible, for example, to
resolve a major incident/prevent further damage or breach, implement a security
patch or to prevent an imminent failure. |
The Change Requestor should also determine what risks the change (or not making the change) presents and how it impacts continued service delivery, using the criteria set out in the table below.
| Risk Level | Criteria |
|---|---|
| High |
|
| Medium |
|
| Low |
|
When assessing the proposed change, the Change Requestor should carry out an impact assessment using the criteria show in table below.
| Impact Level | Criteria |
|---|---|
| High |
|
| Medium |
|
| Low |
|
Once the Change Requestor (and Change Owner) are satisfied that they have completed the CRF then it should be submitted to the Change Management Team (CMT), who will add it to the Change Control Register.
Stage 2 – Evaluation – the change request is evaluated by the CMT
The evaluation is to look at benefits to the business and the resources needed. The timeline for the change and its impact on other projects as well as risks and impacts associated with the change will be determined and discussed with the Change Owner and Manager.
Proposed changes that present medium to high risk or impact are likely to require more information from the Change Requestor or the Change Owner and Manager and may require additional steps for approval, such as consulting senior management or key stakeholders and having an initial plan to review.
Results of the evaluation will be provided to the Change Owner/Manager. They are to be in the form of requirements and conditions to be met as part of detailed planning for the change, and its implementation.
Evaluation should also identify exit strategies for high-risk changes or to prepare for worst-case scenarios.
Terms of reference for the CMT can be seen at Annex C.
Stage 3: Plan the Change
This stage may be broken down to ensure that the CMT has enough information to complete its evaluation prior to giving approval for the change to be implemented.
The detailed plan for change, developed by the Change Owner, Change Manager, Change Implementer with assistance from the CMT must address any requirements and/or conditions raised by the CMT as well as schedule, resources, risk mitigation, any training requirements for those affected by the change.
The plan should also include performance metrics for monitoring and assuring success of the change and expected results/outcomes.
Stage 4: Approve Change Plan
The CMT, based on its evaluation will determine whether the change can move forward, and under what conditions. The CMT may reject the change or defer the decision to a later date in each case it will provide its reasons for doing so in consultation with the Change Owner/Manager. Once approval has been given the implementation phase can begin.
Stage 5: Implement Change
The change is to be implemented in accordance with the detailed plan from Stage 3. The CMT will remain engaged throughout implementation, receiving regular updates on progress as well as any new risks/issues raised that had not been foreseen, providing advice and guidance as necessary.
The implementation stage ends when the change has “gone live” and is in situ as business-as-usual.
Stage 6: Review and Close
This phase is a joint effort between the CMT, Change Owner/Manager and the Change Implementer to review the results of the change. The review’s main objectives are to identify what went well or what could have been improved upon throughout the whole procedure.
Closing the change means determining if the change met expectations and provided evidence of its success. The close evaluates the plan in relation to the entire project. Documented proof of success can be a rise in efficiency, a reduction in cost or meeting a business goal.
Closing identifies mistakes or inefficiencies and documents them to apply to future change proposals.
Finally, the change register is updated to include all documents for reference and record-keeping.
Annex A: Procedure Flowchart
Annex B: Change Request Form
You can download the Change Request Form here, complete it and submit it directly to [email protected]
Annex C: CMT Terms of Reference
Introduction
The typical change enablement process starts when an individual, process, or business unit raises a change request. The change request gathers information such as the configuration item associated with the change, the reason for the change, the requestor's identity, the change type, risks and impacts.
The request is then reviewed by a change authority (for NDP this is the Change Management Team CMT) who assesses the need for the change. They may request more information about the change and its business practicality and reject the request if it doesn't seem to be of much value. The review involves the evaluation of the impact (on infrastructure, business, and other services), anticipated risk, constraints, and benefits of the services; the review is thorough because it is imperative that there is no disruption to service operations. As part of the approval the CMT will need to be satisfied that the implementation plan addresses the impact evaluation findings.
Once the change request is approved, the change is implemented by the appropriate technical and subject matter expertise teams who build, test, and deploy the change. If the change is to fail, or there is going to be downtime, a backup plan must be used. When the change is built and tested, the change manager gets notified. The change manager uses a change calendar and announcement/ notification features and schedules and plans the deployment of the change. Upon implementation of the change, the entire change process is reviewed and documented.
The goal of the CMT is to provide an objective, unbiased review that can help ensure changes are made in a controlled and coordinated manner. The team should include individuals from different functions, but each should also have knowledge of the business process and system being changed. This allows them to provide a well-rounded review of proposed changes.
CMT Responsibilities
The primary responsibility of the CMT is to provide recommendations and guide decision-making. The Change Manager is the one who has complete authority to green light or reject a change.
As a best practice, only particular necessary change requests need to go to the CMT. CMT approvals can also be predefined. While configuring a change template or workflow, certain changes can skip the CMT process by pre-approving the change.
CMT members are chosen based on the knowledge and expertise required for the execution of a particular change.
The CMT’s key responsibilities can be summarised as:
- Ensure that the Change Control Register is maintained updated throughout the procedure.
- Assess change requests from both a technical and a business perspective.
- Schedule and prioritise change requests.
- Calculate the risks associated with the change and present stakeholders with evidence and supporting documentation on why the risk is or isn't worth taking, including the benefits of the change or the reasons for rejecting it.
- Propose risk mitigation plans.
- Monitor the progress of a change and provide feedback.
- Maintain standards for changes.
- Guide the change owner/manager in decision-making.
- Communicate by creating documentation of the evaluation of changes irrespective of them being a success, failure, or pending.
- Take responsibility for continuous improvement initiatives in the change process.
- Make sure the [affected] organisation is aware of and adapts to new changes.
- Some of the risk and impact analysis done by the CMT is based on questions such as:
- How will subsequent services be affected?
- Will the performance of services increase and thereby add business value, such as an increase in client satisfaction?
- Can the business allocate the resources that this change will demand, including staff?
- Are the required resources available, including staff?
- Will the change impact data security and compliance?
CMT Members
The CMT should include at least one representative from all groups affected by the changes on the agenda (including non-IT groups if applicable) and can include managers or non-managers, such as subject matter experts and those with operational experience. Responsibilities of CMT Members include:
- Review changes prior to the meeting.
- Assess and recommend the approval or rejection of proposed changes in a timely manner. If a CMT member doesn’t approve a change, make sure they explain why.
- Attend scheduled CMT meeting(s) or send a qualified representative.
- Act as a liaison between the CMT and its team regarding change management policies, procedures, questions, or enhancements.
CMT Lead
The CMT Lead acts as a chairperson and should be a CMT member. This person is typically the Change Manager or on the change management team. Responsibilities of the CMT Owner include:
- Develop the vision and strategy for CMT meetings.
- Lead CMT meetings and make sure the required representatives attend.
- Define and communicate the CMT members’ roles and responsibilities.
- Document and communicate the CMT meeting agenda before CMT meetings and decisions after the meeting
CMT Meeting Agenda
A CMT meeting agenda should include:
- All high-risk changes and changes marked as required by the CMT
- A review of all failed and backed out changes
- Change management process updates
- Reviews for each change that include: