The purpose of this discipline is to:

• Maintain a consistent set of work products as they evolve
• Maintain consistent builds of the software
• Provide an efficient means to adapt to changes and issues, and re-plan work accordingly
• Provide data for measuring progress

In many organizations, the term "configuration management" implies all of these things.

Within the context of this process, configuration management refers to the ability to maintain versions of artifacts and consistent configurations of artifacts, addressing the first two objectives listed above. Change Management refers to the process of managing changes to configuration-controlled artifacts, addressing the latter two objectives listed above.

Although it is important to keep up-to-date versions and configurations of all work products, the primary work products of concern are the Artifact: Implementation and the Artifact: Build.

Changes are managed via the Task: Request Change and subsequent prioritization and disposition of change requests via the Artifact: Work Items List.

This discipline spans the entire lifecycle. Every other discipline relies upon the configuration and change management discipline to maintain a consistent, up-to-date, set of work products -- and to prioritize and track changes to those work products -- throughout the lifecycle.

Configuration and change management is performed by everyone on the development team. Because of the importance and pervasiveness of this discipline, configuration and change management guidance is associated with tasks and work products in all other disciplines.

It is assumed that the project has some form of configuration management system, such as CVS, to maintain version and configuration information, and to enable collaborative system development. Without this, all but the most trivial of development will be virtually impossible.