A Target Approach for who should Manage Change

[article]
Summary:

The activity of managing change is known as Change Management.  Managing change is typically very challenging and may occur at many levels within a workplace.  A key when implementing a change management process is truly understanding what should be managed and by whom.  For the sake of argument, I will refer to the group that manages the change as the Change Control Board (CCB).  However, there are other names used to represent this group (e.g., Configuration Control Board, Governance Board, etc.).  It is important to understand that while I use the phrase "manage or control the change", a CCB may not really control the change as much as acknowledge the change and apply impact analysis for the change in order to determine the best deployment guidance for the change.

What this article hopes to provide is an approach that offers insight into appropriately identifying the key members of a CCB.  It will do this 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 the incorrect 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 

What is a Baseline Stream?  This 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 time 1.  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. This 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.

1. If the baseline does not need to be controlled, then 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

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!