|Español - Italiano|
Configuration management encompasses the administrative activities concerned with the creation, maintenance, controlled change and quality control of products. Its goals are to:
- identify the products that will be treated as configuration items;
- support the assessment of change requests and document the results of change control;
- maintain the validity of the configuration and the accuracy of the configuration management system.
A configuration is the complete set of functional and physical characteristics of a final deliverable defined in the specification. At its simplest, configuration management is the same as version control.
Configuration management provides control over the development of products. It helps to avoid mistakes and misunderstandings about what a product is required to do and whether it does this. It provides the verification of products as required by solutions development. This function also ensures that adequate procedures are in place to provide continuing maintenance of products for the duration of the product life cycle.
A typical configuration management procedure is shown below:
A configuration management plan (whether as a separate document or a section of the scope management plan) should describe any specific techniques and the extent of their application during the life cycle. The plan should also identify roles and responsibilities for carrying out configuration management. Initiation will make sure that the required resources, including people, tools and systems are in place.
Configuration identification involves breaking down the work into component products (configuration items), creating a unique numbering or referencing system and establishing configuration baselines. This aligns closely with the preparation of a product breakdown structure in scope management.
The control step ensures that all changes to configuration items are documented. An important aspect is the ability to identify the interrelationships between configuration items. This is essential information for the review and assess steps in the change control procedure as the practicality of making a change to scope will be affected by its impact on interconnected configuration items.
Status accounting tracks the current status of a configuration, providing traceability of configuration items throughout their development and operation. Regular status reports will indicate if change requests are being processed in a timely manner and may highlight products that are subject to frequent requests for change or stakeholders who are common sources of change requests.
Verification and audit is used to determine whether a product conforms to its requirements and configuration information. Typically, an audit is undertaken at the end of a phase, stage or tranche.
Configuration audits take one of three forms:
A physical audit looks at the relevant elements of a configuration item and will confirm that the item meets its specification. It will check the results of quality control and confirm that all the necessary test documentation has been completed.
A functional audit of a configuration item will check that it performs the function for which it was designed.
A system audit checks that the configuration management system is working, able to support the planned procedure and perform the necessary functions. This aspect of configuration management is part of the assurance of the function.
A form of configuration management can also be applied to the management documentation. This is mainly about version control but could also include functional audits as part of assurance.
As work is completed, responsibility for maintaining deliverables passes to the client or business-as-usual. The management team is responsible for ensuring that relevant information management principles have been applied and the configuration is easily transferable to those who will be maintaining the products long after the project, programme has been closed.
Projects, programmes and portfolios
The need for formal configuration management beyond simple version control will depend upon the scale and complexity of the objectives. It will also depend upon the degree to which specification changes are allowed. In a project that has a contract based on a firm price payment method, no change is allowed. In an agile project changes are an inherent part of the method. Both contexts need to track different versions of a product in development and both need to support verification of products against the specification. Configuration management systems have to adapt to very different situations.
Within scope management, work definition produces a product breakdown structure and detailed descriptions of each product. This becomes the configuration and once it is baselined it is subject to formal change control and configuration management.
Some projects are more complex because they include safety critical, secure or related environments. The larger the project, the more people may be involved in developing, testing and integrating a product. Configuration management has a role to ensure that there are no gaps in the chain of quality control, testing and record keeping for all products, intermediate assemblies and testing regimes that might compromise the final deliverables.
A programme management team need to ensure that all outputs fit together and function properly in the context of the blueprint. Each project and area of change activity within the programme must adopt a consistent approach to managing configurations. This makes it much simpler to assess whether a change to the products of one project will have any effect on the products of another project, or on the programme’s eventual benefits.
A portfolio is unlikely to produce any configuration items other than key management documents but where different project and programme deliverables come together to meet a strategic objective the portfolio management team must track the configuration to ensure the final integration achieves the required result.