Change Management and Configuration Management are closely related process areas. Change management is the process of
planning and coordinating the implementation of product changes in a planned, authorized, logical, and orderly fashion.
It does not develop changes, nor does it implement them. Configuration Management is the process of controlling and
synchronizing the evolution of the set of work products composing a software system
In order to understand the impact of changes and to plan for verification, change requests must identify which versions
of which artifacts were affected by the change. A common problem with stand-alone change management practices and tools
is a lack of traceability to the affected configuration items. For this reason, it is critical to integrate your
Configuration Management and Change Management processes.
Change and Configuration management are also related to Product Integration. The purpose of this process area is to
incrementally assemble the product from its components, ensuring that the integrated product functions properly.
Milestone builds and releases must have traceability to all implemented changes and their associated configuration
items.
Reference the following typical activities and key considerations for these three process areas as you define
practices for your organization.
Configuration Management
Identification of configuration items
Organizations should specify which work products and what parts of work products should be placed under configuration
management, and what specific controls are required, and when those controls are applied.
One way to represent this is with a table that lists work products or parts of work products, and lists the type of
configuration control required, and in what phase they are placed under configuration control. A separate
guideline (or practice) then describes the different types of configuration control, if there is more than one.
You may also wish to specify how configuration controls change for a single work product through different phases of
the project.
Another approach is to have a general policy that can be used to determine whether work products need to be under
configuration control. For example, you might just mandate that all project deliverables are placed under
configuration control, rather than have a separate table. You might also have a policy that says project
deliverables are placed under configuration control in the phase where they are first formally reviewed.
Levels of configuration control
Typical levels of configuration control on projects are:
-
No controls - this typically applies to work products that have no long-term value, such as results of
brainstorming efforts, throw away prototypes, and so on.
-
Version control only - in this case, you may capture past versions of a work product, but not have any controls on
what changes are made, by who, or why.
Naming conventions
Organizations may wish to specify naming conventions for different kinds of configuration items.
Configuration management audits
Define the policies for configuration audits. These audits ensure that the system satisfies the specified
requirements, including all approved change requests, and nothing more.
Configuration management environments
Organizations should specify tools and tooling configurations that automate the configuration management process and
enforce configuration management policies.
This includes the following.
Role authorization and notification
You may wish to limit access to certain kinds of information to particular project roles. For example, project
plans may not be available to customer representatives directly. Project plans may be updateable only
by the project manager. You may also set up automatic notifications so that certain roles are notified when
configurations items are changed.
The level of controls applied may be different for different project types. For example, you may wish to have a
high trust environment with very few controls in order to encourage high levels of collaboration.
Archival policies and mechanisms
Certain work products may be important to archive for metrics, compliance, or other reasons. These may be
identified using a table that lists work products that need to be archived. Or you may have a general policy to
identify which items to archive, such as "archive all configuration controlled items".
Product directory structure
Organizations may propose one or more standard product directory structures to organize configuration items.
Baselining
You may wish to establish policies on who can create a baseline, what kinds of work products are included, and what
approvals are required.
Baselines should be created from approved configuration items only.
Change management
Define Change Management practices to provide project teams with explicit approaches for controlling changes,
including defining states for change requests and tasks for transitioning change requests between their
specified states.
A good rule of thumb is to have as much formality as you require, and no more. Generally, it is most efficient to
minimize formal change control to highly visible features, and allow the project team to manage lower-level details
with a minimum of overhead. Organizations typically define a formal Change Management practice and an informal Change
Management practice so that teams can select the most appropriate approach for their project.
An informal practice provides a simple change management process which is integrated into project management
activities. In this approach, any team member may request a change to the system (or supporting
artifacts) at any time, either to correct a defect identified or to add an enhancement. The request for change is
captured in the backlog. During project planning the team reviews the backlog, prioritizes work, and
decides which changes will be implemented next. A more formal practice is used when additional governance is needed in
the Change Management process when there is a group of stakeholders outside the project team that needs to
approve and verify certain kinds of changes or changes need to be tightly controlled (such as late in an iteration or
release cycle) for stabilization purposes.
Confirm your Change Management practices address the following concerns:
-
work products and kinds of changes that are controlled by the practice.
-
change request types (e.g. defect, enhancement request).
-
change request states (e.g. approved, assigned, deferred).
-
how often are changes reviewed?
-
what roles participate in the change-request process?
-
what metrics are tracked?
Product integration
Product Integration practices help teams progressively assemble the product components in incremental stages according
to a specified integration strategy.
Enterprise policies for product integration prevent:
-
subsystems that don't integrate/ operate together.
-
installing a product that does not integrate with the customer's production systems.
-
delayed testing and increased integration times.
Establish enterprise procedures and the environments required to support the integration of product components.
-
Product integration environments may include equipment for testing and simulation, production hardware and
other devices.
-
Make build or buy decisions based on the the availability of existing organizational resources and the enterprise
product integration strategy.
-
Practices for the integration of product components typically describe such procedures as the types of tests
to be carried out at each stage, criteria for managing interface descriptions and repositories, and guidelines for
determining system build procedures.
-
Create tailoring guidelines describing how projects can tailor their project-specific process and integration
environment (including build/ buy decisions).
|