• Open Halo

• Go to Workspaces, Change Enablement, Normal RFC

• Select Change normal from Change Management Section

• Click the “+” in the upper right from the Normal RFC list view screen

• A. Fill out the main details of the change (Draft Status)

• Number – The change reference number and will be pre-set by the system. It can be used to reference this change.

• Set appropriate company at the top right

• Title – Describe the change in its basic form

• Description – A detailed explanation of the change, why the change is needed, and the end goal of the change, reason for the change, as well as any other pertinent information to the change and the approval of the change

• B. Details Tab (found in tab list on the left side of the Normal RFC window)

• Category – Set the appropriate category from the drop-down list

• Subcategory – Select if this is an Add, change, or remove, of the above category item

• Assignment Group – The group doing the change

• Assignment User – The member of the assigned group doing the change and is normally the one filling out the change request.

• Planned start date – The date and time in which the change is tentatively scheduled to take place

• Planned Duration - The estimated amount of time it will take to complete the change in hours, minutes, and seconds (HH:MM:SS).

• Has Risk toggle switch – Indicates there is risk involved with this change and will add the Risk tab to the left-hand side navigation.

• Financial impact toggle switch – Indicates a financial impact and will add the financial impact tab to the left-hand side navigation.

• Is there a cost to either centrexIT or our clients? Provide details of the financial impact on this tab. This includes the possibility of a one-time charge or a change in the monthly charges to centrexIT and/or the client.

• C. People & CIs Tab

• Affects (CI) – Add all affected CIs here. (For services, such as email, add the underlying system, IE Exchange or Microsoft 365, not the end service of email)

• People – Add the people associated with the change. This would include anyone completing parts of the change or advising on the change from cIT (assisting), anyone from the client that maybe involved or impacted by the change or the client system owner (watching), any vendors involved in the change (vendor), and the primary person leading this change (Lead).

• D. Risk Tab (Visibility of this tab is set by Risk toggle on the Details Tab listed above)

• If this change has risk, it must be defined and discussed in this section

• Risk Level – Identify the level of risk 1 = low, 3 = high

• Low risk – Change has been performed before and was successful AND if outage occurs, less than one hour to reverse.

• Medium risk - Change has been performed before with some challenges OR more than one department is required OR if outage occurs, less than 3 hours to reverse.

• High risk – Change has previously failed or has never been performed OR more than two departments are required for success OR if outage occurs, more than 3 hours to reverse.

• Risk Management Plan – Define and describe how risk will be limited and managed.

• E. Financial Impact Tab (Visibility of this tab is set by Financial Impact toggle on the Details Tab listed above)

• Financial impact description – Describe the financial impact

• For example, if adding a server, explain associated resources, licensing, etc that may be billed.

• Exceptions,

• If this change is part of a pre-scoped project and will not deviate from the approved scope and budget of that portion of the project, then this section can be ignored as the financial impact has already been assessed. If part of a project, the project must be included on the project tab

• F. Execution Plan Tab

• Build out the change plan and the individual steps. Phases are large sections with the (+) under each phase allowing for individual tasks/steps to be defined. All phases and steps are completed in linear fashion in the execution phase of the project so build out the steps accordingly. Each step should have associated changes items and describe the evidence that will show prior change settings and then updated settings.

• For each task/step of the plan you will be required to fill out the following:

• Title – Title of that part of the change, or short summary of that part of the change

• Description – A detailed description of that part of the change. Ensure all critical details, such as Versions, IP Configurations, specifics that differentiate this change from other and from the original state are included.

• Additional Values – These are additional fields that may be added to any change step if needed. The following are recommended if applicable:

• Testing Plan – This would be used to document a specific Testing plan step where this change can be verified as completed successfully

• Backout Plan – This would be used to document a specific backout plan should this step of the change fail testing.

• Escalation Plan - This would be used to document steps that may be taken prior to following the backout plan if challenges are experienced in the testing.

• Other additional values are not currently recommended but may be used in the future as Halo is developed.

• Example:

• Phase 1 – Reconfigure cIT-NOC-FW-1

• Step 1

• Title- Change IP address of cIT-NOC-FW-1 from 192.168.1.1 to 10.1.10.1

• Description – cIT-NOC-FW-1 will be re IPed from 192.168.1.1/24 to 10.1.10.1/24 all other network parameters will remain.

• Assignee – Person assigned that task/change

• Evidence of this change example needed in the execution phase would include screenshot of the configuration on cIT-NOC-FW-1 showing 192.168.1.1 prior to the change and an additional screenshot showing the updated configuration and new IP of 10.1.10.1 Additionally, a screenshot of the updated network diagram showing the cIT-NOC-FW-1 device with the new IP of 10.1.10.1 updated on that diagram as indicated in the change.

• G. Testing and Issues Tab

• Testing Plan – Describe in detail how changes will be tested after the change is completed. These steps or the evidence showing these steps were complete will also need to be included in any post change evidence. Should any of these steps fail, the Escalation plan will come into effect.

• Escalation Plan – Describe in detail the steps to be taken should the Testing or change phases fail to be completed. If the escalation plan fails, the backout plan will come into effect.

• Backout Plan – Describe, in detail, the backout or rollback plan should the testing and escalation plans fail. Describe how the system or CIs will be put back into configuration as to return them to the pre-change state.

• NOTE, for changes that have several distinct testing, backout, or escalation plans, these may also be attached to the individual steps. (See Additional Values in previous section on the Execution Plan Tab)

• H. Project Tab

• Project – Select the appropriate project if this change is associated with an existing project. One project may have more than one request for change associated with it.

• I. Attachments Tab

• Relationships – This section can be used to link the change to other Halo items, such as CIs (which will be included from people & CIs tab), as well as any other items that might be relevant to the change.

• Attachments - Include any attachments relevant to the change or showing evidence of the change. Also include any pre-change and post-change network diagrams. Label all documents clearly in the file name of the document.

• A. Once all the details are entered save the Normal RFC by clicking the save and stay icon in the upper right.

• A. Once a change is ready to be submitted for approval, select drop down arrow on the right of the blue “Draft” status at the top right of the window. Change the status to “Approval.” This will initiate the approval phase. Click save and stay to save this status.

• B. Approvals are automated and sent to the approvers associated with the company record. First approval is the client vITM. Second approval is the cIT SME team. Final approvals will include the cIT financial reviewer if applicable.

• C. Approval time frame – Each approver has up to one week to review and approve. If no approval is given from either group within that time frame the request will automatically be rejected must be re-submitted.

• D. Approval rejection – If either the vITM or the cIT SME reject the change it will immediately show a status of “rejected” and must be placed back in Draft status and resubmitted with updated changes to mitigate the reason it was rejected. Reach out to the rejecting party for further details on the rejection.

• E. Once a document has been approved, it will show the “approved” status. This means you can move on to the Scheduled Phase. To make this change, simple selected the blue “Approved” status box and select scheduled. Then save. Move to Scheduled Lifecycle Phase.

• A. Once the NRFC shows “Scheduled” as the status the change has been approved by both groups of approvers in the approval phase. Nothing is needed during this phase until the execution phase is to begin. Once execution of the change is ready to be carried out select drop down arrow on the right of the blue “Scheduled” status at the top right of the window. Change the status to “Execution” and then save.

• B. Should changes to the NRFC be needed, the status should be changed back to “Draft” and saved, and the details amended as needed. Then the change should be resubmitted for approval. No changes to NRFC tasks, testing plan, backout plan, escalation plan, or CIs, should happen without the change being moved back to “Draft” and resubmitted for approval.

• C. The change can also still be cancelled if not needed or if it needs to be completely resubmitted and it is easier to start from the beginning. Should a change need to be cancelled from this step, simple change the status to “cancelled” and save.

For full Execution Lifecycle Details, please see KBXXX CIT - Procedure - Executing a NRFC

• A. Once an NRFC enters the execution lifecycle it can no longer be cancelled or changed. Changes must be completed or reverted and the change control must move forward through all steps as indicated by the change, the testing plan, escalation plan, and back out plan.

• B. To complete the changes, move to the Execution Tab.

• C. Changes should show up as individual line items set for execution with the assigned user highlighted for each change. Complete each task and complete all steps and include all evidences as needed. If changes are not to be made, the change step should be set to reverted and evidence showing as such included for review.

• D. Once all steps are completed and NRFC is saved the status of the change will automatically be converted to review. Attach all additional evidence, updated documentation, etc. Save the NRFC.

• A. Review of the NRFC will take place at the next CAB meeting. The cab will review the following:

• i. All changes completed to specification

• ii. All items impacted were tested and evidence of that testing is sufficient

• iii. If any exceptions or other challenges were indicated that they were sufficiently handled, documented, and the change and end goal was still achieved or in the event of a back out, that the changes were reverted.

• iv. All evidence is detailed enough, documentation is updated, and any additional items of importance are covered including but not limited too:

• 1. Passwords
• 2. Network diagrams
• 3. CMDB configurations
• 4. Client documentation

• v. Once satisfied that the change was completed, the CAB will set the lifecycle to “Review Complete.” If any items such as billing are outstanding, the CAB will get confirmation of those items prior to complete closure. Should any items be missing, the CAB will set the lifecycle to “review rejected,” provide details of the rejection, and reassign it to the assigned engineer to complete the needed tasks. Engineer will then be responsible for updating the NRFC as required and resubmitting it for review.

• vi. A CAB member will denote the review was completed and that no outstanding items remain prior to setting it to the final status of completed.

• A. Once the CAB is ready to close a member of the CAB will set the NRFC to “Completed.” This is the end step and denotes a completed change. Nothing further is needed.