Who Moved My (Application) Cheese: Change Management

Change…It happens. Not only does it happen, it needs to happen. The world moves quickly and applications need to keep up. Markets demand new features in software, just for businesses to stay competitive. Change also enables businesses to find “new cheese” and take advantage of opportunities. Application support teams have unique positions to help enable businesses by effectively managing change to Production environments.

Change Management is a process, but also, it is an art. Taking a stand when changes will cause undue risk needs to be balanced with the need for new features and bug fixes. Having a solid, healthy partnership between Support and Development always helps keep a balance.

Most companies have ways to track change, be it via change request tickets or simply via a spreadsheet. Obviously, the former will be better than the latter but the availability of change management tools also depends on the size of the organization.

It’s critical that change always be tracked, no matter how small. Attentiveness to this detail is critical, otherwise, change management will not be effective. Most change requests will contain at least the following key features (other than the obvious, such as Change Descriptions):

1. A Risk assessment
2. Timing of the Change
3. Implementation Plan
4. Backout Plan
5. Validation Plan
6. Responsible Party

It’s healthy for teams to know all this information, as it can be critical information to know when faced with a change-related incident.

Besides, the obvious (sometimes tedious) task of tracking changes, other practices also provide benefits in helping manage change.

For example, I recommend that Prod support teams designate a change manager who will run a weekly meeting to review changes for the upcoming week. The meeting should have as an agenda the coverage of a list of change tickets for the week. Each item should be represented by a Development resource who can speak to the need, risk and urgency of the change. This allows the group to ask questions about changes as well as propose alternative timings and approaches to the change.

Also, many large organizations have change meetings at a larger scale (in many organizations, they’re known as Change Advisory Boards), for higher risk changes. The change manager should represent the entire Prod Support team in the CAB meetings and be prepared to discuss the upcoming changes.

Many times changes are classified into various categories with differing lead times. For example, a “Normal” change might have a 5 day lead time, whereas an “Emergency” change might have shorter lead times. In general, the shorter the lead time, the higher the risk and thus the necessity for more levels of approval. Many organizations allow certain changes to go in without supervisor pre-approval, especially during Incident/Break-Fix scenarios.

There is one type of change type that many organizations don’t have, but that I highly recommend. I call them Business as Usual (BAU) changes. BAU Changes allow teams to make small, low risk changes (e.g. change an IP address in a configuration file) without the need for much risk assessment and levels of approval. Having this lite change type enables change resiliency. The change should still have a supervisor’s approval, but in general this should be easy to obtain. BAU changes should never involve releasing code (even small SQL changes to stored procedures), if anything to prevent misuse.

Another best practice I recommend is for Prod Support teams to always have some level of approval in terms of the changes to the environments they manage. This ensures that Prod Support acts as a gatekeeper and ensures due diligence has been done before the change is made.

Finally, Prod Support should also participate in the validation of change correctness.