What is change management?

Learn about the philosophy of change management and best practices for implementation.

This Content Component encountered an errorThis Content Component encountered an error
This Content Component encountered an error
This content was excerpted from the free eBook The Definitive Guide to Enterprise Network Configuration and Change Management (Realtimepublishers.com) written by Don Jones and available from a link at http://www.voyence.com/ebook/.

What exactly is change management? Browsing around the Internet doesn't provide much in the way of solid definitions. Is it a set of products you buy? A process you follow? A group of technologies, or a management buzzword? Change management can be all of those things, actually.

A process
At its heart, change management is a state of mind, a philosophy that says "we want to only make changes after due planning and consideration, and we want those changes to be made in a consistent, repeatable, reliable fashion." Implementing that philosophy usually results in a process, outlining how change occurs.

All change management processes usually involve some common steps:

  • Formal documentation of the proposed change.
  • Collaborative review of the change to assess risks and ensure accuracy. This should include testing of the changes in a lab environment to assess their accuracy, as well.
  • Timeline for implementing the change.
  • Acceptance of the overall plan by stakeholders.
  • Final documentation of the change as it will be implemented.

The process is intended to serve as a set of rules and reminders for how change is reviewed and implemented. Of course, you can't underestimate the penchant for people to work around rules and processes, especially harried network administrators who just want to put out today's fire. Discipline is required to make any process work, and it's also incumbent on the process itself not to present unnecessary hurdles. For example, a network change management process should offer a streamlined way for emergency changes to be implemented. For example, if you find out on Tuesday that your primary ISP will be going offline on Wednesday, then you'll want to quickly make some changes to route traffic through another connection. That's not something you can afford to spend weeks arguing about; your change management process has to provide a way for high-priority changes to be safely and quickly handled.

A tool
Change management can often be enforced and automated through tools. These tools may provide a variety of functions, including:

  • Tracking requests for changes and documenting the details of proposed changes.
  • Comparing proposed changes to known-good templates, to help weed out improper changes. Tools may also allow changes to be proposed through a template, ensuring a level of consistency for all submitted proposals.
  • Enforcing a workflow process that requires peer or supervisory signoff.
  • Basic boundary-checking to ensure that company policies and security practices won't be violated by the change (such as a change resetting all router admin accounts to have a blank password).
  • Displaying the exact changes which will be made to devices' configuration files.
  • Tracking the change and deploying it to the affected devices.
  • Monitoring devices for changes, pulling the changes, and documenting them for review.
  • Automatically redeploying a last-known-good configuration to devices which have been changed without authorization.

The variety and capability of change management tools provides a lot of functionality to help businesses better manage their networks.

Industry best practices
What should your change-management process incorporate? Which best practices have evolved in the IT industry that you can leverage to create an effective process? The following list provides an overview of what your process should address:

  • Change logging and filtering—Your process must include formal documentation for change requests. You should also spell out exactly who in your organization is permitted to submit change requests (ideally, everyone should be permitted to submit requests). Making the process accessible to everyone encourages participation; locking down the process encourages vigilantes who try to circumvent the process.
  • Provide links between problems and changes—When requesting a change to resolve a problem, ensure that the change request and the original problem remain linked in some fashion. Doing so will provide built-in documentation for the reason behind the change and provide information that can be used in post-change analysis.
  • Multiple priorities—Given that you can only accomplish so much in a day, your process needs to accommodate changes that are more important than others. Some initial review of change requests needs to occur shortly after their receipt so that the requests can be "triaged" and fed to the remainder of the process according to priority. Above all, ensure that your process doesn't create artificial barriers in the way of legitimate changes that are necessary for business or stability purposes. Your goal should be to create a usable management process, not an artificially complex bureaucracy.
  • Multiple categories—Build your process to acknowledge different types of change requests. You might categorize changes by the risk they pose to your environment, the resources required to deploy the change, the complexity of the change, or some combination of these and other factors. Categories should serve a useful purpose in helping to prioritize and manage changes.
  • Review—Your process must incorporate some type of review process to ensure that changes will be effective and safe. Total Quality Management (TQM) principles suggest that peer reviews are the best: studies have shown that professionals in most industries pay more attention to their work when they know a peer will be reviewing it. Supervisory review and signoff may be a political requirement in your organization, but this step is not a technical review. Don't rely on the hope that the boss is going to pick up on technical problems with a proposed change.
  • Periodic focus meetings—To ensure that everyone involved with the change-management and implementation process remains focused, schedule periodic focus meetings. Held once a month or once a quarter, these meetings allow the team to discuss problems with the process and to discuss long-term changes that are in the works. These meetings can also serve as a forum for discussing failed changes so that each member of the team can learn the lesson the mistake offers.
  • Approval—In the end, your process must include some formal approval step through which changes are approved and schedule for implementation.
  • Follow-up—Your process should also include a follow-up review of each change, either at a focus meeting or by a senior administrator. This review should frankly assess any negative impact created by the change, and these reviews should be fed back into the change-management process to fine-tune that process and prevent future problems of the same kind.


This content was excerpted from the free eBook The Definitive Guide to Enterprise Network Configuration and Change Management (Realtimepublishers.com) written by Don Jones and available from a link at http://www.voyence.com/ebook/.

This was first published in April 2004

Dig deeper on Network Performance Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close