The Value of Change Management

by Bryon D Beilman

You are now leading a new task to determine specifications and configurations for your new corporate intranet web server. This may involve vendor selection, careful hardware performance metrics specifications and which software will be used. You may spend time customizing it and rolling it into production. You get kudos from all departments and as a reward you get exposure and more departments want to use this server to collaborate with the rest of the company.
At first you were busy trying to meet your aggressive schedule and now the success of this project is inviting more users to ask for more modifications to this server or service. How do you maintain the availability and integrity of this service while still adding functionality, managing updates, patches and security vulnerabilities? How do you know what impact the implementation of your latest feature had or will have on performance?

Managing change is a critical process to ensuring that your service continues to work properly. “Gartner research shows that an average of 80 percent of mission-critical application service downtime is directly cause by people or process failures. The other 20 percent is cause by technology failure, environmental failure or disaster.” See Gartner Paper

Change management is a core part of the ITIL service and support methodology, yet, you don’t have to be an ITIL expert to utilize and benefit from the basics of change management. Here’s a crash course on change management, which is not all inclusive but designed to help you think about managing change in your IT environment.

1. Establish a baseline: If you are lucky, you captured all application and configuration files changes the moment you installed an application or an operating system. If you did not, then start now and establish a baseline. In order to know what changed, you have to know what to monitor.

2. Develop a process: This is typically the most difficult part for an organization that does not have any process in place.

  • Get stakeholders involved and decide what your change process is going to be.
  • Do you have separate development, stage and production platforms or are you so small that you only have production?
  • What is your review and approval process for changes?
  • What are the acceptable change time windows?
  • How do you test a change after it is implemented?
  • How do you back out in case it does not work?
  • How do you communicate the change and any functionality changes that are noticeable to the user?
  • There are many commercial and open source tools that can help you, and you need to decide what tools are right for you. In order to decide, you may need to answer a few questions that will determine the tools that you.

    3. Decide on tools that can help you:

  • Do you use a configuration management tool to manage revisions?
  • How do you track changes and the history of changes?
  • Do you utilize dedicated test platforms or virtual machines?
  • Do you have good backups to help you back out of botched changes?
  • Do you require clusters or other configurations that ensure 100% uptime during a managed change?
  • If you decide on your process, some rudimentary tools and a good communication process, you will have a good start. Later on, I will discuss the details of CMDB, process, and some tools that you may consider. If you are truly interested in the change management process and how it interacts with configuration management, incident management and problem management, check out the ITIL (IT Infrastructure Library) The Wikipedia is a good start for an overview

    Subscribe Here For Our Blogs:

    Recent Posts

    Categories

    see all