Technology updates and upgrades are part of the IT infrastructure life cycle. However despite the best intentions of the person(s) responsible for changing upgrading or modifying a system or solution, deploying changes can be one of the most difficult challenges IT teams face. Often resistance to change comes within the organisation itself, which is risk adverse, getting stakeholders on-board with a major change sometimes requires substantial skills in people management. That being said, this article describes the necessary steps to execute an effective change within any IT operations department.
The components of a successful change management practice should include as a minimum:
Reason for the changeBenefit to the end userDisruption to the businessTime required to complete the changeResources needed to complete the changeA secure backout plan if the change is unsuccessfulChange approval
Changes of any type should be conducted outside normal business hours, or at times when user traffic is at its minimum.
If you are operating in a managed service model, where alarm monitoring occurs, the change needs to include acceptance from the network operations supervisor, if it is going to create management alarms.
At times, change management is required to correct issues in software or hardware configuration. The ability to track those changes for auditing purposes becomes necessary, especially in the event of a roll-back or backout due to unforeseen failure.
Ensuring availability of server logs or system state information becomes critical if an organisation uses automated change agents within the network.
In case of large networks, automating the process of distributing software updates or configuration changes can save hundreds of man hours over a calendar year,
However, evaluating whether the change was completely successful will depend on the quality of the available audit information.
Most network change management suites consist of a modelling application that allows organisations to build the complete network in a virtual environment that runs the exact same configuration as the live network.
This allows the simulated deployment of a complete configuration change to be evaluated before it is committed to the live network.
If your organisation doesn't have the luxury of a fully automated change suite, or the type of planned change cannot be simulated then the following steps can be followed to realise an effective network change.
Reason for the Change
Regardless of the change you are planning, it is important to inform all the relevant parties involved the reason for the change.
Usually the reason will determine when the change will occur, and will be dependent on it's importance to the users of the system.
Usually taken for granted, but here are the questions which will be asked.
Is an outage required?
Can the change occur without outage?
What is the benefit/impact to the end user?
Can the change be merged with other planned change events?
How critical is the change?
If the change is major, it is important that sufficient resources are allocated beforehand, usually a project manager or some other responsible person should produce a change plan which all stakeholders can agree upon.
Change Risk Register
Many change requests have dependencies which can affect the overall change, sometimes the simplest things can cause a planned change to completely fail, such as site access, or cable length being too short.
The risk register should contain a list of concerns which the initial stakeholders provided during the initial meeting.
It is critical that open items on the risk register are closed or satisfied before the actual change occurs.
Responsibility Matrix
This is simply a list of who, what and when.
Prior to the changes, many things must occur first.
For example, purchase orders may have to be raised for external resources, equipment may require purchasing and some additional planning may be required.
The responsibility matrix covers the task and when it must occur.
Make sure names of people are recorded by each task and a completion date is also included.
Change Simulation
Depending on how critical the change is, it may require evaluating in a test environment first.
This can be useful to determine how much time is required to effect the change, and to iron out any unforeseen problems beforehand.
A change to swap a copper Ethernet connection to fiber is an excellent candidate for change simulation especially when redundant connections are involved, and fail over doesn't work as expected.
User Notification
Communicate well in advance with the end users, is vital to any successful change. Multiple announcements should be sent to affected users by email, and should contain as much information as possible, but as a minimum must include.
Reason for the ChangeBenefit to the userThe outage timeThe Backout Plan
Change management is a bit like robbing a bank, usually it happens in the middle of the night and there is only a short amount of time. There needs to be hard time limits attached to each activity.
Ultimately it is the project/change manager who decides to execute the backout if the change exceeds 75% of the allotted time.
Questions to ask stakeholders regarding the backout plan prior to the change.
Can we provide 100% service restoration in the event we have to backout?
What logs or information can be captured to report to management as to the reason for backout execution? Is there a point of no return where the backout plan is ineffective
Change Closure Report
This final aspect of most changes is often overlooked. It should be included especially if similar change events are planned for the future.
The report should include a list of events which went well, events which proved difficult, and events which could be done better next time.
If you found this article helpful, and would like to read more similar articles, up to date technology briefings, and news related to network management, planning and deployment, please visit http://road2it.com/
View the original article here
