Change Control & Release Management

Change management is the process of how IT management plans, implements, and makes changes to an organization’s technology in a controlled way to reduce unwanted changes or system downtime. And it’s a necessary and ongoing process as organizations strive to grow, improve, and adapt to the changing business needs and the technology landscape. 

IT departments always have regular change requests to their software or infrastructure to fix bugs, install software, report downtime, and address other business needs. And continuous change is necessary to maintain a stable, robust, and secure IT environment, and for continuous improvement in the quality and performance of systems. 

For more complex changes, such as writing software for subject matter experts who have specific needs, change control may require a steering committee. Steering committee meetings should be scheduled on a regular biweekly, monthly, or quarterly basis to update the committee on progress and receive input on necessary changes. 

Change control and release management should always be forward looking and consider the long-term impacts of changes and what stakeholders should expect in the future. For instance, considering potential upgrades, creating data warehouses as databases grow, considering the systems required for scalability, as well as ongoing maintenance tasks, documentation, and end-of-life considerations.

IT managers often see resistance to change because stakeholders fear that changes will create unexpected costs or problems. In other words: “If it’s not broken, don’t fix it.” However, the reality is, IT systems age and die, become obsolete and insecure, and may end up creating greater costs and more problems than they are worth. If those costs are not kept under control, they could easily rise into the millions of dollars. So, it’s important for management to demonstrate the benefits of any changes, address concerns to stakeholders and staff, and receive feedback during the change process. And ensuring these changes are managed by professionals who know what they are doing helps to ensure seamless continuity of business operations with zero downtime. 

High priority items tend to include software and systems that are critical to the immediate needs of the organization, or requests by the executives. Requests that are easy and may be completed in 5 minutes may also be highly prioritized since they yield immediate value. Requests that take a longer amount of time, need to be prioritized based on the requestor and its business impact. And any request that may require a project plan, or stakeholder buy-in, may need to be set aside for management approval and management sign off. 

A change request may include any of the following elements:

Backoff plan, if one is needed, describes how staff will revert back to the old system in the event of a deployment failure, or is determined to be incomplete by management. For example, instead of upgrading an existing system, it’s usually better to deploy a new system. When deploying to the cloud, many cloud providers have blue / green deployment options that allow the old version and new version to be switched by clicking a button. This allows a deployment to quickly be reverted back to the old system if anything goes wrong.

Significant changes to IT software and infrastructure should be planned in advance. And depending on the complexity of the change, it may require some project management, financial analysis, timelines, and milestones. This planning process provides for the ability to do scenario analysis and predict unforeseen problems, in addition to unforeseen requested changes by management.

Create test or staging environments to test changes before they go into production. This should be a normal part of the deployment process. That enables management and staff to perform load testing, performance testing, quality assurance, and user acceptance testing. Ideally, replicate the production environment in the test or staging environments as closely as possible so unexpected problems may be discovered beforehand. This also provides the ability to perform capacity planning and understand infrastructure requirements. This also provides the opportunity to create technical documentation, perform training, review laws and regulations, review security measures, and test backup and recovery. 

Releases may be complicated and may involve many working pieces that need to be sequenced in a very specific order. Without a structured change release plan, and without professionals who know how to upgrade or migrate systems, the deployment may fail when it goes into production. And reverting back to the old system may prove precarious.

Deploying new software written in-house, or new infrastructure systems, may require substantial planning. And the project planner will want to create a structured release plan, which outlines the systems impacted, the stakeholders involved and how to contact them, and the scope of the release and who it impacts. 

A deployment plan is a document that IT staff will follow when deploying new releases, such as newer versions of software. This deployment plan will likely have a number of systems in place, such as DevOps, staging and production deployments, and deployment timeslots. It should also document who will be doing the deployment, what systems are impacted, and what steps need to be performed and in what order to successfully deploy the software. For example, changes to an internal business application should document every system, script, database, function, schema, or configuration affected by the change. This serves as a checklist so that when in the maintenance window (i.e., the period of time when the new systems are about to be deployed) each item may be reviewed to ensure no items are missed.