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.
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.
|Change type||Delivery path||Team responsible|
|Large business enhancements||Release (N+1)||Projects|
|Small business enhancements||Release (N+1)||Projects|
|SAP support packs||Release (N+1)||Support|
|Non-urgent problem resolutions||Release (N+1)||Support|
|Urgent problem resolutions||BAU||Support|
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).
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).
|CR defined||Change request is defined as a particular change type i.e. emergency fix|
|CR approved||Change request is approved for inclusion in a release or as a BAU fix|
|CR allocated to release or BAU||BAU path or N+1 release path|
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.