Baseline management is necessary for both the project and the product baseline. Product baseline management is usually called configuration management (CM). CM is one of the most important project control disciplines. The major categories of CM disciplines are as follows:

		Configuration Identification
			Functional, Allocated, and Product Baselines
			Interface Controls
			Configuration Item Identification
		Configuration Control
			Change Criteria and Classification
			Deviations and Waivers
			Change Proposals, Evaluations, and Control Board
		Configuration Status Accounting
		Configuration Audits
			Functional and Physical Configuration Audits

Managing Change:

A project that will need to manage changes to the project scope or the product description and design should have a configuration management plan at the outset. This plan should document the configuration related risks and outline plans and procedures to control and manage those risks.

Configuration management begins with establishing configuration baselines. The statement of project requirements should be put under configuration control. Then a configuration control system should be employed to collect, evaluate, decide, and implement proposed changes to the project scope or the product specifications and design. Configuration baseline identification should be applied to functional, allocated, and product baselines.

There may be cases where project deficiencies will not meet specifications. These cases may result in deviations or waivers to the specification requirements.

Configuration status accounting provides a documentary trail from the initial project requirements specifications through all the design products and changes that result in a finished project output.

At project completion, the functional configuration audit confirms the product meets the stated functional requirements. The physical configuration audit confirms the documented design matches the as-built physical configuration.

The project manager should determine the level of scrutiny and approval appropriate for requests to change the baseline requirements or design. Technical changes should be reviewed for cost and schedule impact and for ripple effects throughout the project. Evaluation of change requests can adversely impact the project budget and schedule, even if the changes are rejected.

Change Control Board Process

In some cases the effects of a change might not be obvious to parties with a single functional view, and such change requests should be circulated for functional approvals. If a higher level of formality is needed, changes can be submitted to a cross-functional group for review. Such a group could forward a recommendation for approval or disapproval to the manager, sponsor, or customer with signature authority for baseline changes.

Approved changes must be incorporated into the project specifications and design documentation. Impacts on the system architecture should have already been evaluated by the time a change is approved, and these impacts will need to be reflected in updated documentation incorporating the change into the on-going work of the project.

Once a new system is up and running, user problems may generate new requests for system changes. These should be reviewed and evaluated in the same way as changes during development. To bring order to the process, small changes can be accumulated and implemented in blocks