By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Managing change is a critical part of an IT department's job. When no process is followed, changes fail and mistakes happen. That's when things start to fall apart. Effective planning can streamline change management and decrease the number of service incidents IT managers have to resolve. Those who take the time to establish a change management process will likely see fewer service desk calls in the short term and more cost savings in the long term.
Change management has a reputation for being very bureaucratic and a resource drain. In fact, change management can often be accomplished with existing staff as long as their roles and responsibilities are defined. The costs of the process and staffing requirements will depend on how the process is designed.
Create ground rules for the change process
So how does change management begin? The first step is to design the process. Talk with staff in internal audit, regulatory compliance, security and IT data center operations when designing the process to get their input.
Set the ground rules. For example, any change to a system — whether it is a new version of Windows, a service pack, patch or configuration setting — should be documented in a Request For Change, called an RFC. There should be enough information to understand what must change and why.
The specific information that needs to go in an RFC should be defined by each organization according to its unique needs. The urgency of the change and its impact to the organization should also be included in an RFC.
Make sure the process is formally documented and stored with other approved IT policies and procedures. IT personnel should receive formal training regarding their roles in the process. Management should receive training on what the change management process is and how it affects the business.
Review, filter and assess impacts
The person in charge of the day-to-day operations of the change management process is called the "change manager." In many organizations, this is a full-time job because of the volume of changes being processed and the need for objectivity. In other organizations, the job belongs to someone with a vested interest in maintaining confidentiality, integrity and availability — such as the head of the data center or IT operations.
The change manager reviews the RFC. He or she may ask for additional information and accept or reject the RFC.
It is important to filter out RFCs that do not make good business sense. For example, don't make changes that are historically known to fail. Making use of historical data can help the change manager understand the risks associated with certain requests. Screening out these types of RFCs can help an IT department avoid a lot of extra work.
Change management is about balancing risks. The change manager needs to carefully assess the potential impact of making a change versus the impact of not making a change. For example, what are the risks of moving the Great Plains server to Windows Vista near the end of the quarter versus delaying deployment until after the financials have been calculated?
Determine the change model
The change manager must review the service that the affected hardware and software configuration items are a part of and then combine that with the impact and urgency to select the proper change model.
A change model is nothing more than a defined workflow with tasks and owners. The intent is to have a range of change models that balance risks and agility for the various services.
A predictable type of low-risk change is considered a standard change. For example, adding a hard drive to a RAID is often a standard change. Although it's pre- approved by change management, the change still needs to be recorded in the database that tracks change records so everyone will know what changed and when.
On the other hand, a more complicated change might require more review and testing, such as migrating to a new version of Exchange in a firm that is required by regulation to track all email.
When designing the models, aim to begin with no more than three models – standard/low-risk changes, medium-risk changes and high-risk changes. For each model, define the criteria that would trigger when each model is used and what level of testing is required.
Assign a change builder
The next step for the change manager is to assign a "change builder" to plan and implement the change. This may be someone from development, network engineering or the data center.
In some organizations where human error and malicious activities are particularly dangerous — like in the financial or healthcare industry — the change builder is not allowed to deploy the change into production. Instead, the documentation and releases that will be deployed are turned over to operations, such as the network operations center group, which then performs the required work.
Of equal importance is planning the recovery if a given change fails. These are known as "rollback" plans, and they can be vital. Imagine applying a Windows service pack to a series of critical servers, and suddenly core functionality is lost. There needs to be a planned and documented method to recover the servers to an approved state.
Use a change advisory board
If the change model warrants it, the RFC may be reviewed in a change advisory board, or CAB. The board is made up of representatives from areas such as security, networking, server engineering or internal customers who have an interest in whether the change is made and whether it is successful.
The idea is that CAB members understand IT services and their impact to the business. For example, a person from information security may review a planned change that may put the organization at risk for data theft. The change manager must also understand each member's perspective before approving or rejecting a change.
Once the implementation date is estimated, it should be published for all to see in the Forward Schedule of Change calendar. By doing this people, can see what changes are happening and when. This helps avoid "collisions" when two or more changes are planned for the same configuration items at the same time.
Change management is a critical process. It ensures regulatory compliance, security and IT operations by ensuring risks are properly managed. When IT shops can avoid unplanned work, they will free up IT resources and staff to work on projects that will improve not just IT, but the organization as a whole.
George Spafford is a principal consultant with Pepperweed Consulting and helps IT organizations in the areas of technology and process implementation. Spafford is an experienced practitioner in many aspects of IT operations, including strategy, audit and operations. He is a speaker on topics that range from security and IT governance to IT process improvement. He is the co-author of The Visible Ops Handbook.