Back to CM Basics: Change Control

[article]
Summary:

This topic has in all likelihood been discussed and hammered more than any other CM-related subject.  But it's a good idea to revisit it now and then, especially from another prospective and point-of-view, just to keep it fresh.

One of the first things asked by those "threatened" by the notion of controlling changes is, "Why do things have to change?", and "What should be controlled?"  As we all should realize, we don't live in an ideal world, so when a configuration item or component is approved, there's no need to change.  However, we live in the real world where change is dynamic and inevitable.  Requirements change, boundaries change, errors are found in documents and specifications or are just plain wrong, designs change, customers change their minds - in general, stuff happens!  Consider the following important input criteria for change:

  • Nature: What is the nature of the change?
  • Alternatives: What are the alternative solutions?
  • Complexity: How difficult is it to implement?
  • Schedule: When is it required?
  • Cost: What are the potential costs/savings?
  • Severity: How critical is this change?
  • Priority: How important is this change?

If we stop to think for just a moment, the number of items that should be controlled becomes clear.  For example, requirements, design, test, and user documentation, source and executable files, database objects, models, prototypes, libraries and repositories, the CM domain, tools, scripts, plans, schedules, impact analyses, change requests, problem reports, migration requests, build requests, baselines, release notes, etc.  The list of items that should be controlled can be staggering.  Yet in many organizations, these items are not taken seriously and subsequently lost or worse - deleted.

To drive home a case in point, the affects of changes can be summarized as follows:

  • Requirements changes affect design
  • Design changes affect code
  • Testing finds problems the result of which causes changes to code, design, or requirements

How can we define the need for change?  To answer this, a number of questions must be asked and their responses analyzed and considered.  Such questions may include:

  • What needs to be changed?
  • Why must it be changed?
  • Who wants the change?
  • How will it be changed?
  • Who approves the change?
  • Who will make the change?
  • When must it change?
  • What are the impacts? If changed? If not?
  • How much will the change cost?
  • How long will it take to implement?
  • What are the schedule and resource impacts?

Now that we've identified some "what" and "why" criteria for change control, let's focus on the "how" and "who".  To begin, we need to define a change control process, which is established by accepting changes in a controlled and stable manner.  The change control process controls and manages the release and change of configuration items and components throughout the development lifecycle.  It also provides several key functional aspects including:

  • Change impact analyses
  • Change authorization
  • Tracking changes through closure

Changes made to baselined configuration items should be done according to a defined process and documented procedures.  Such procedures should specify:

  • Who can initiate change requests
  • Approval/rejection authority
  • How revision history is kept
  • Impact (analyses)
  • Check-out and check-in procedures
  • CCB process
  • Escalation process

The most effective mechanism for controlling changes is the change control board or configuration control board (CCB).  The CCB should include in its membership those stakeholders closest to or impacted most by changes, provide overall authority for managing baselines and configuration items or components, and ensure that all changes are considered, reviewed, coordinated, approved/rejected, and implemented.  The CCB should also control impacts to project costs and schedules, categorize and prioritize enhancements (new requirements), resolve defects and problems, and establish an authority responsible for all change activity.  The CCB also considers:

  • What is the specific benefit of the change?
  • How would the change affect project costs?
  • How would the change affect the project schedule?
  • How would the change affect product quality?
  • How

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

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!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09