Change Control:

Throughout the project lifecycle, and beyond through the lifecycle of the product or solution delivered, there will be continuous pressure for change to:

ImageCorrect errors

ImageIntroduce improvements

ImageReflect the changing needs of the market place.

It will not benefit the project manager and client to prevent changes such as these, but neither can they be applied freely. A well founded Change Management system offers a practical solution to the task of applying strict yet flexible controls.  These controls should be designed to minimise the potential chaos that would result from uncontrolled change, and give the reassurance that change can be accommodated when it is necessary.

Configuration Management:

Once a change has been approved, the configuration manager (whoever has been designated as the focus of configuration management, e.g. the Configuration Librarian on large projects, the Project Manager etc.), must log the change and mark the CI (Configuration Item) as Undergoing Change. Simultaneously, the CI must be copied, the original retained and the copy issued to whoever is designated to control the change.

This is aimed at protecting against the problem of accidental "double update"

Once the CI has been updated, and has passed its quality checks, its description will be updated with:

ImageThe new version number

ImageRevised change history

ImageAny other new information

ImageThe undergoing change tag is removed

ImageThe new baseline status recorded.

The progress of a specific CI through the change process should also be tracked, e.g. change identified, change evaluated, change approved, change applied, change tested, change submitted for QA, etc., together with any actions arising from testing and QA




Copying restricted

No right click