Change Management

1. Change Management

Change management is a formal, well-structured system of planning and implementing system changes. Change management can be helpful with any kind of system, not just network or IT systems, but is especially important when making changes to hardware and software that will affect the company’s infrastructure and ability to do business. This lesson explains the steps involved in developing a request for change, getting it approved, and implementing it.

term to know

Change Management

A formal, well-structured system of planning and implementing system changes.

1a. Setting Change Management Goals and Objectives

The goal of any change is to fix or improve something about the current system. For example, a company might plan to upgrade the speed of the network connections to individual workstations. In order to do that, they will need to replace many NICs and switches, as well as a significant amount of cable.

key concept

To achieve that goal, the IT professionals planning the change may have some specific objectives, such as the following:

• Get management approval before the change begins
• Avoid disruption of everyday network operations as much as possible during the change
• Minimize the risk of problems occurring before, during, and after the change
• Document all the changes clearly and thoroughly

1b. Developing a Change Request

The first stage of the change process is to get management approval. The more expensive and extensive the change, the higher the level of management that must approve it. For example, if a user needs a certain application that’s not installed by default, they could request an exception to the software policy; a change like that might require only a mid-level IT manager’s assent. In contrast, the aforementioned upgrade of all the network connections to workstations would likely involve senior management’s sign-off.

In cases where a formal Request for Change (RFC) document is required, it may contain some or all of the information mentioned in the table below.

Component	Description
Reason for the change	The decision makers who will evaluate the RFC will first want to know why. Clearly, every change should be made for a reason. How will this change help the company meet its goals? Spell it out in plain language. Will this change: Help workers be more effective at their jobs? Improve customer satisfaction? (Are customers currently dissatisfied? How will this change help?) Increase revenue? (How?) Decrease expenses? (How?) Offer tax benefits? (How?) Enable the company to comply with regulations? (Which ones?) Make the company better able to compete with competitors?
Type and scope of the change	The change management process can vary depending on its scope and type. A change request might categorize a change as one of the following. Major: A big-budget change affecting lots of people and processes Minor: A small-budget change that is unlikely to cause any problems Standard: A change that has already been approved and follows a standard procedure Emergency: A change urgently needed to fix a significant problem
Timetable	The proposal should indicate how long the change is expected to take overall, as well as how long each step in the process will take. The following are some points to address: What is the target start date? How long will the planning phases take? On what date is implementation expected to happen? How long will it take for all systems to be fully operational after implementation? How long will it take to train the users, if needed?
Budget	How much will this change cost and into what categories do those costs fall? The following are some examples: How many personnel will be needed to implement the change and for how many hours? What hardware must be purchased and at what cost? Is the hardware cost to be a capital expenditure? How much will installation cost? How much will the software cost? Is that an upfront expense or a subscription? How much will training cost, factoring in the hourly wages of the workers who must conduct or attend it, as well as any outside trainer, if required? How long will it take for the company to recoup those costs?
Potential Impact	While unexpected adverse effects of a change can’t always be anticipated, a good-faith effort should be made to identify all possible systems that could be impacted by the change and what that impact might be. Consider the following points: Will the change require users to change the way they do something? If so, what and how? Will workers have a drop in their productivity during a learning curve period adjusting to the change? Will users who bring their own devices to work, or who have atypical computer systems (such as a lone macOS user in a company where Windows is the norm) experience any special challenges? How will those be overcome?
Rollback plan	Changes always carry a risk. Before any changes occur, there needs to be a rollback plan for reversing the changes and recovering from any adverse effects from the change. Consider the following points: If the change causes a critical system to fail, what is the plan for rolling back? How long will the rollback process take, and how much (if anything) will it cost? What will happen after the rollback has occurred? Will the change be abandoned, or will further testing determine and correct the problem before another attempt?
Details of the change process	The proposal should include a detailed plan that explains the details of the change process, including but not limited to exactly what will happen, and why. This is likely the largest section of the proposal. This planning process may take many days or weeks, and may involve staff from multiple departments. The following are some points to include: What will be done? Give a step-by-step summary of the process and, where relevant, explain why each step is necessary to the overall success of the change. Who will do it? List either the individuals or the job roles that will be involved and their roles.

terms to know

Request for Change (RFC)

A document used to request a change.

Rollback Plan

A plan used for reversing the changes and recovering from any adverse effects caused by the change.

Details of the Change Process

The proposal should include a detailed plan that explains exactly what will happen, and why.

1c. Getting Approval

Requests for changes should be fully vetted by a cross section of users, IT personnel, management, and security experts. In many cases, it’s wise to form a change control board to complete the following tasks:

• Assure that changes made are approved, tested, documented, and implemented correctly.
• Meet periodically to discuss change status accounting reports.
• Maintain responsibility for assuring that changes made do not jeopardize the soundness of the verification system.

The purpose of this change board is to evaluate change requests and approve them, deny them, ask for more information, or ask for modifications to the plans.

term to know

Change Control Board

A group of decision makers who evaluate change proposals and approve, deny, or request changes to them.

1d. Notifying the Stakeholders of the Upcoming Change

After approval has been obtained, the next step is to communicate with stakeholders—such as department heads and the individual users who will be affected—to let them know what’s coming. One of the associated benefits of this is that it creates additional monitors for problems during the change process.

As with any business communication, it is important to choose the best medium. Depending on the people involved, a combination of some of the following methods may be optimal.

• In-person meeting
• Email
• Printed memo or letter
• Online video meeting
• Personal phone calls
• Group phone call
• Text message

If it is critical to reach each stakeholder within a certain timeframe, sending the information via two or more different media may be helpful.

---

2. Implementation of Change

Change management implementation requires planning, coordination, and documentation. The goal is end-user acceptance. This is a complex and time-intensive process.

2a. Planning the Implementation

Even after the proposal has been approved, there may still be planning to do. The responsible person may need to assemble an implementation team, for example, and assign certain responsibilities to each member of the team.

The team may also need to define the maintenance window—in other words, the dates and times when the system will be unavailable because of the changes. All affected systems should be examined to determine how long they can be down without adversely affecting the business. The time required to make the change may exceed the allowable downtime a system can suffer during normal business hours, and the change may need to be implemented during a weekend or in the evening.

terms to know

Responsible Person

The person in charge of the change; the proposal will include their name and contact information.

Maintenance Window

The amount of downtime that will be required to implement the change.

2b. Implementing the Change

After all that planning and approval, the actual implementation is almost anticlimactic. Each team member does their part, and (in an ideal world) the change goes off without a hitch. If anything does go wrong, the team refers back to their planning documents to determine how to proceed—either by solving the problems or by implementing the rollback plan.

2c. Documenting the Change

The job isn’t complete until the paperwork is complete. In this case, the following should be noted:

• Who approved the change, and when?
• Who implemented the change, and when?
• What were the specific actions taken?
• How did the change affect the network’s physical or logical structure?
• What was the effect on the IT systems, both overall and specifically?
• What problems occurred, if any, and how were they solved?
• Do any problems remain to be corrected?
• What is the expected long-term effect of the change?

hint

Any network topology diagrams and lists should also be updated to reflect the network’s new structure.

2d. Getting End-User Acceptance

Some network changes are invisible to the end users, like speed upgrades. Other changes, like changing the software they use to fill out their time cards, may require some training and IT-support handholding to roll out. Extra helpdesk support people should be available on the day of the rollout to handle user questions. In cases where the new software is very different from the old, formal training sessions may be required.