Anti-Patterns of Change Control
Published on AgileConnection (https://www.agileconnection.com)

[article]

Anti-Patterns of Change Control

Summary:

Change control is a configuration management process used to manage changes to important baselines like requirements and production. Change control may be considered a critical practice in that it often can be used to manage critical items within a project lifecycle, an application lifecycle, or the organization. It can be challenging to implement change control effectively. Often the reason why is because there is an anti-pattern (poor unworkable solution) in place.

 

This article provides an approach that offers insight into appropriately identifying the key members of a CCB. This is done by identifying the items that need to be managed and the workplace level in which the items live. Ultimately, the question comes down to, "What are we managing and who is empowered to manage and/or approve the change?"

Attributes of Change Management

When discussing the scope of change management, consideration should be given to the following two attributes: the baseline stream that will be managed and the target level within the workplace. A common challenge to managing baseline streams is that the target levels of the baseline items are not appropriately considered. This results in an unbalanced level of personnel on the CCB that may not be empowered to enact the change. With this in mind, let us analyze the areas of baseline stream and target level.

Baseline stream: A baseline stream is a collection of similar items that have a continuous flow of change over time from which baselines are established. As you may know, a baseline is an identifiable and controlled collection of items specified at a point in time1. However, like many baselines, changes occur to the baseline stream so that new baselines need to be established over time. A consideration for scope is to determine which baseline stream is being considered. Examples of baseline streams are:

·       Requirements: The collection of requirements may include (but not limited to) a list of requirements that are targeted for an application release. At certain points in time a requirements baseline is specified, and then changes are managed to it.

·       Production: The collection of items that make up a running application. At certain points in time, a new production baseline is established for the application that includes changed functionality.

·       Environment: The collection of items (both hardware and software) that make up an environment. This may imply a work environment or an application or development environment.

·       Policy: The collection of policies and templates (and potentially processes and guidelines) that must be managed and that impact a workplace at some level.

If the baseline does not need to be controlled, it may not be important enough to apply any level of change control (e.g., version control or identification of the change may be adequate).

Target level within the workplace:  A second key attribute is to understand at what level within the workplace we are targeting the change. By identifying the level, it will allow us to better identify the personnel who can most effectively assess the impact of a change and are empowered to make a change. Below are three different levels (but not limited to):

·       Project level: Specific to the duration of the project lifecycle and used in relation to a specific project release or an application. Once the release is in production, the project lifecycle ends.

·       Application level: Specific to the duration of the application lifecycle. An application lifecycle is typically made up of several project releases that each contributes changed functionality to the application running in production. Once users no longer use the application, the application lifecycle ends.

·       Organization level: Specific to the duration of the organization lifecycle. An organization may be a company or a specific division within a company that operates independently from other divisions within the company. An organization may have multiple application groups working on numerous projects.

It is important to understand the target level within the workplace to identify the appropriate personnel so that an appropriate level of impact analysis can occur prior to a change. Assessment of impact may be incorrect if the incorrect level of personnel is performing the assessment.

Combining the attributes:Once the baseline stream in question has been identified and the target level is defined within the organization, a determination of who should be key CCB members can then be considered. It should be noted that there are many important members of a CCB. The table below attempts to identify only key CCB members. Each CCB should have members that allow for a robust discussion of each change.

What must be noted is that there may be more than one level of CCB for a baseline stream. For example, a level-1 CCB might focus on a specific set of requirements for a project while a level-2 CCB focuses on all requirements across all projects that are related to an application. The level-1 CCB can assess the impact of requirements that may affect several concurrent projects related to the application, while the level-2 CCB assesses only the impact to that specific project.

Below are some examples of assessing the baseline stream with a target level to identify the key CCB members.


Baseline Stream


Target Level


Key CCB Members

 

 

 


Requirements


Project


Project manager and key project personnel. If a requirements change may affect a different yet current project or subsequent projects, then chair of this CCB should raise awareness of these changes to the Application level CCB.


Requirements


Application


Application owner and project manager. This CCB assesses changes to requirements on all related projects. The project manager must ensure they communicate any requirements changes from the application level to their project level CCB (should one exist) if the requirements affect the project.


Requirements


Applications (this may be a program or release package made up of several applications)


Release manager (assuming there is someone assigned to manage the incoming project level release pieces from the different applications), application   owners and project managers (for each project release that makes up the program release package). This ensures all potential impacts of the change are considered across the program release). Project managers must ensure they communicate any requirements changes from the application level to their project level CCB (should one exist) if the requirements affect the project.


Environment


Application


Environment manager, application owner, project manager(s), SCM manager, test   manager. Application owner and Environment manager should ensure they communicate the changes to all personnel working on the application prior to making the change.


Environment


Applications


Environment manager, application owners, project managers, SCM manager(s),  test manager(s). Application owners and environment manager should ensure they communicate the changes to all personnel working on the applications prior to making the change.


Policy


Project


Project manager and key project personnel. The change should be communicated to all project personnel working on the applications prior to making the change.


Policy


Application


Application owner and project manager(s). The change should be communicated to all application personnel working on the applications prior to making the change. The project manager(s) should communicate any application level policy changes to their project personnel.


Policy


Organization


Senior management and compliance (may involve several groups such as QA,   audit, etc.). The change should be communicated to all organizational personnel prior to making the change and the change should be incorporated into the compliance and verification and validation processes.


Production


Project/application


Application owner, project manager and key project personnel. Since a project creates a set of deliverables that affect the running application (in production), the application owner should be on this CCB. Typically, the members of this CCB should include the same members as those that managed the   requirements baseline stream for the project (including the application   owner).


Production


Applications (3 applications contribute to the release


Release manager (assuming there is someone assigned to manage the incoming pieces from the different applications), application owners, project managers and key project personnel. Typically, the members of this CCB should include the same members as those that managed the requirements baseline stream for the projects and application.

 

Summary

The next time you are in a position to establish a CCB, consider using this approach and examples above. Identifying the items that need to be managed and the workplace level in which the items live may help you identify the best choice of key members for a CCB who can most effectively assess the impact of a change and are empowered to make a change. Also, if you are working on a CCB that is having a difficult time implementing or managing change, consider the composition of the group and determine if the appropriate personnel are on the CCB.

Change management will always be challenging. It will never be easy at any of the levels mentioned above. However, including the appropriate level of personnel on the CCB may provide one-step forward into more effectively managing change.

 

About the author