Managing Change in a Release Management Environment – Part III of IV (Critical success factors)

Last blog we discussed system architecture (N+1) as an important consideration in managing change in a Release Management environment and introduced several corresponding and important critical N+1 architecture success factors. In this blog we are going to drill down a little into each of the critical success factors. These being, change definition, process and managing parallel change.

Change definition

In part I we introduced a basic list of change types. In order to have an effective release strategy, a defining of the types of change to be managed by the release needs consideration. For example, the definitions should allow for important fixes and low impact changes to continue to trickle through the BAU landscape without undermining the overall strategy. If Gartner’s five different types of change are considered, the following could become a basic change definition table with delivery paths and team responsibilities allocated.

Table 1: Change type definition table

  In order to prevent non-urgent problem resolutions or portions of small enhancements sneaking into PRD via the BAU path, approval policy can be designed to prevent this from occurring. One of the side effects of introducing a release strategy into an existing IT change team is for process workarounds to come into play (for example, a sharp increase in the number of emergency fixes is often noticed).

Process

An appropriate and enforceable approval process will prevent workarounds and ensure the release strategy is adhered to by business and IT. Each step of the process requires an appropriate level approval before progressing (for example, the change requester ought not be authorized to define the change as BAU fix).

Table 2: Basic change approval process through to allocation

However, a process is more than approvals. A good process will, for example, include management of the various statuses each change within the release will pass through, manage potential conflicts within the release and govern management of the individual transports containing the changes.

Managing parallel change (conflict)

An important function of a process is to assist the IT development team manage the release changes technically. For example, simultaneous change within BAU and the release can result in overwriting of BAU change when the release is delivered to Production. Such errors can be very difficult to track down and can reflect badly on the quality of the release.

Additionally, careful control over changes within the release, i.e. order of migration of configuration and development into the test and production systems, is critical to minimize or prevent conflicts between the different changes within the release.