Change Control and Configuration management in Project Management practices

Agile Project Management Certification
Get a FREE Trial for the BVOP Project Management Certification Exam
Get a FREE Trial for the BVOP Project Management Certification Exam

Change Control and Configuration management is a very important activity in Project Management practices today.

The information presented in the article is validated against the PM.MBA requirements for transparency in project management academic publications.

When you have completed this chapter you should be able to demonstrate an understanding of the following:

  • the reasons for change control and configuration management;
  • change control procedures (from monitoring and controlling in project management practices):
    • the role of the change control board;
    • the generation, evaluation, and authorization of change requests;
    • configuration management:
    • purpose and procedures;
    • the identification of configuration items;
    • product baselines;
    • the content and use of configuration management databases.

Introduction to Change control management in project management

Change control managementBusiness changes have many implications outside the narrow confines of IT development, including their impact on an organisation’s staffing levels, skills and responsibilities. Change management is concerned with the smooth transition of the organization to the new system that a project delivers. The Water Holiday Company integration project will create new software, change existing software and expand IT infrastructure.

These are technical changes, but the integration project will also require changes to the way the merged business will be run.The particular focus in this chapter, however, is on the events during a project that result in alterations to project requirements. The project manager’s skill lies in controlling those changes so that minimal disruption is caused to the planned objectives of time, cost and quality. Change control management ensures that modifications to any aspect of the project are only accepted after a formal review of their impact upon the project and its environment. The procedures for managing change should be established at the beginning of the project.

The planned functionality to be implemented may be modified during the project as the needs of the users and the business are clarified. These changes need to be tracked through a change control system. If outside contractors are carrying out some of the work, the need for a change control system is even greater. New IT systems usually need to be integrated with existing operational systems, and this may require modifications to these legacy systems so that they can communicate with the new functionality created by the project. The changes to these existing systems need particular care to ensure existing operations are not degraded. Changes are part of the entire project life cycle in the project management area.

Allowances need to be made within the project plans for the possibility of additional work caused by requested changes. These allowances could be part of the tolerances delegated to the project manager. The project manager ensures that these allowances are not exceeded. Where they are exceeded, a new project plan would need to be drafted and approved by the project sponsors. Agile management practices have a different approach to change management. They focus on short-term periods and the risk in long-term initiatives is minimized. All stated practices here are related to waterfall project management processes.

Change control, at some level, should be applied to all changes, whether they arise from a change to user requirements or are due to design modifications. It requires participation by the users and the developers, guided by the project manager. The users must judge whether a change is essential, desirable or optional. This decision takes account of the possible impact of the change as well as of not making it. The project manager must assess the technical feasibility of the change, and identify its impact on costs, time and quality. Once account has been taken of users’ and developers’ advice, if it is decided to go ahead with the change, it is the responsibility of the project manager to implement the change.


In Chapters 2 and 3, we introduced the idea of the project as a sequence of activities, each of which takes certain inputs and uses them to produce outputs. The outputs from one process may be inputs to others. Thus, a specification could be an input to a process that creates a system design (that is, the format of the user interfaces with the system) which will then be implemented as code.

During the process, the proposed interface designs may change rapidly as the designers try out different designs and the users give feedback on them. This does not need a formal change process. At some point, however, a decision needs to be taken that the design is now in a satisfactory state for constructing the system. At this point, the design will need to be frozen; in other words, the design is baselined. If changes are needed to the design after it has been baselined, then rigorous change control is needed because of their potential impact on the processes that use the design.

The idea of baselines was introduced in Chapter 3 with regard to project plans. A baselined plan may be regarded as an agreed plan against which variations will be measured. Any change to requirements could imply a potential change to the baselined plan. For projects, the baselines include the agreed scope and quality of work, schedule and costs. Project Management Academy teach these practices to be more optimized and shortened.

As noted in Chapter 3, these will tend to be interdependent. For example, if the scope of the work is expanded, then the cost will be increased. Similarly, cost or scheduled duration could be reduced by decreasing the functionality delivered. Variations on these baselines can be categorised as follows.

Changes of scope and Development changes

Changes of scope: These generally originate outside the project, usually by the users, managers or project sponsors changing the requirements, or by the cost or time constraints of the project changing. In the case of the Water Holiday Company integration scenario, the users may, for example, add a requirement that when booking a boat online the client should also be able to purchase holiday insurance. On the other hand, a reduction in the project budget may mean that some planned system features are dropped.

Development changes: These originate within the project and include changes that are routinely carried out as part of the normal process of developing and refining a product. Typically, this can be something as simple as an adjustment to a screen layout.

Faults: This type of variation also originates within the project and is caused by the project team making errors. For example, misunderstood requirements in coding detected by system tests could lead to additional corrective work. Some discretion will be exercised in accepting or rejecting scope and development changes but changes to correct design errors will normally be obligatory, since the system may not work satisfactorily unless they are corrected.


In order to encourage the UK boating holiday industry, the government decides that VAT on canal holiday bookings will be zero-rated with immediate effect. The management of the Water Holiday Company calculates that this could increase the demand for bookings by 30 percent. At the same time, the government introduces a special tax on holiday insurance that has to be accounted for separately on invoices. When considering the implications of changes, the project team realise that although holiday insurance was included in the original requirement, it has been missed out from the system design. What effect might these changes have on the project?


It is important to clarify the various roles and responsibilities in change control. We are going to use a very specific set of terms here to identify and explain the various roles and responsibilities. In a real project environment, it is very unlikely that these precise terms will be used. However, there should be people who carry out the following roles, whatever they may be called.

The project manager oversees the process and ensures that all requests for change (RFCs) are handled appropriately. In most cases, the project manager also has the role of the change manager. Project managers must ensure that user representatives approve any changes made to the project requirements. They also control the scope of the system to be developed: additional features will require more effort and increase costs. When the project sponsor agrees to additional features, adjustments may need to be made to the project’s contractual price. The certified project manager also needs to be on the lookout for informal changes made outside the process. Informal changes are often discovered during project reviews and a retrospective RFC form may need to be completed so that records remain accurate.

The change requestor recognizes a need for a change to the project

The change requestor recognizes a need for a change to the project and formally communicates this requirement to the change manager by completing the RFC form.

The change manager (who may be the project manager) is responsible for logging RFCs in the change register. They decide whether a feasibility study is required for the change. Where this is desirable, for example, because the extent of the impact of the change is uncertain, one or more people will be assigned to carry out the study.

The change feasibility group appointed above investigates the feasibility of a proposed change. It is responsible for researching how the change may be implemented, and assessing the costs, benefits and impact of each option. Its findings are documented in a feasibility study report.

The change control board (CCB)

The change control board (CCB) (often consists of business stakeholders) decides whether to accept or reject the RFC forwarded by the change manager. The CCB is responsible for:

  • reviewing all RFCs forwarded by the change manager;
  • approving or rejecting each RFC based on its merits;
  • resolving change conflict, where several changes overlap;
  • resolving problems that may arise from any change;
  • approving the change implementation timetable.

A change implementation group carries out the change. It is usually made up of staff from the project team.

Leave a comment

Your email address will not be published. Required fields are marked *