The purpose of change control is to ensure only beneficial or necessary changes to a baseline are implemented.
Previous
Chapter 21. Issue managementThe Teal Book: Part E
Chapter 22. Change control
22.1 Purpose of change control
22.2 Key points
- Changes are inevitable in project delivery but they should only be implemented through a structured change control process that protects the baseline against scope creep.
- Identify which aspects of the work should be subject to change control.
- Introduce change control progressively as plans are baselined.
- Every change request should be assessed through an impact assessment and only necessary and beneficial changes which further objectives should be approved
- Understand the impact of changes on the baseline and configurable items.
22.3 Why control change?
Changes are inevitable in project delivery. Without a structured process to control them, unmanaged changes can cause scope creep, where extra requirements are added in an uncontrolled way, leading to constraints being breached against the baseline, such as time and cost.
Change control exists to prevent this. It makes sure that every proposed change to scope and constraints is assessed for impact on the plan, solution design and management documentation baselines, prioritised against the objectives of the work and either approved or rejected through a clear decision.
It keeps baselines aligned and makes sure that relevant stakeholders and team members are aware of what is being proposed and implemented.
22.4 What is change control?
Change control is the set of activities to control requests to change the baseline of a portfolio, programme or project so that only beneficial or necessary changes are approved and implemented. The approach forms part of the governance and management framework.
An approved change request means that the change is integrated into baselined plans, solution design and management documentation, ensuring that the impacts of the change are fully factored into other parts of the work.
Change control is distinct from management of organisational and societal change, which is to prepare, equip and support organisations and individuals (for example, users, citizens) to change their approach and, where appropriate, behaviours and to embed the required changes delivered as a result of the work, as described in Chapter 35: Management of organisational and societal change.
Change requests can originate from any stakeholder, including policy makers and owners, members of the sponsoring body, end users, suppliers or team members. They are typically from:
- a threat that is above tolerance
- an opportunity that could be exploited
- an issue that cannot be resolved within the current constraints
In government, change requests often come from:
- a change in government or organisational policy affecting the objectives
- a change in the risk appetite
- changes in environmental factors
- changes identified from continuous improvement activities
- problems or faults identified within the solution
In programmes and projects, a frequent period for changes to the baseline is in readiness for a submission of an updated business case.
A change request is usually captured on a form which records the information needed for the change control register. The register records the characteristics of each change request, including categories, description, impact, related risks and issues, and status. The status indicates progression through the activities, typically:
- requested
- assessed
- approved
- deferred
- implemented
- closed
As a change request progresses through its journey, additional information can be added to the register such as an impact assessment covering the implications of the change on the plan, solution, management documentation and configurable items.
Change control has a direct relationship, as shown in Figure 22.2, with traceability management which ensure the relationships between the different components (or elements) of a solution and the associated management documentation are understood (see Chapter 23: Traceability management) and information and data management which ensures information and its underlying data (physical or electronic) is available and reliable for undertaking work and making decisions (see Chapter 24: Information and data management).
Decisions on changes to the baselined plan and solution design depend on the allowable tolerance set for the manager that part of the plan or solution is assigned. Where a change exceeds tolerance, but is considered necessary or beneficial, the change request should be escalated to the appropriate level. Decisions on change requests can be to:
- approve (with or without conditions) and authorise the change to be implemented
- approve but defer implementation
- reject with or without a need for more information.
If a proposed change is rejected because it exceeds approved baselines, then:
- further work can be initiated to consider if the change can be made more acceptable or accommodated through trade-offs without impacting the baseline overall
- a decision sought on whether work can be replanned and baselines reset to enable the change to proceed, which normally requires escalation to a more senior decision-maker or governance body (including, potentially the relevant investment committee where a change impacts the approved business case)
22.5 Who controls changes?
People undertaking a project delivery role require at least an awareness of how to request changes. Accountability and responsibility for change control should be clearly defined within the governance and management framework and reviewed on a regular basis, to avoid duplication or gaps. Typically, accountability follows the hierarchy in the work breakdown structure.
The portfolio director, in a portfolio, or senior responsible owner, in a programme or project, is accountable for change control and is the ultimate owner of changes. They own the change control framework ensuring that it is effective for understanding changes and impacts of changes on the baseline such as outputs, outcomes, benefits, defined constraints and objectives.
The portfolio manager or programme or project manager, as appropriate, is accountable for developing and managing the change control framework, including its processes, tools, techniques.
Depending on the scale of the work, there could be a dedicated change control manager or support office manager with the responsibility for overseeing changes on behalf of the portfolio, programme or project manager. They may exercise these functions through a dedicated change control board, which they or the portfolio, programme or project manager may chair, usually as a sub-board reporting to the portfolio, programme or project board. If a dedicated change control manager is not necessary, the portfolio, programme or project manager, as appropriate, should undertake the role. For work packages, the work package manager often undertakes the role for their own work package.
In general, any person with a legitimate interest may raise a change request and is known as the identifier. In practice a change request often comes from the sponsoring body or the team itself, including suppliers. It can also originate from a risk owner or an issue owner when they require a change in order to respond to a risk or resolve an issue, or from users, when for example circumstances or requirements change.
Each change is assigned to a change owner, who is a named individual responsible for assessing, planning, implementing, and closing a change request. The change owner can be supported by people to assess and implement the change. A change owner needs to be someone who can manage a given change either due to their position, authority, technical or other experience. To keep change control effective, care should be taken to not allocate too many changes to one owner. As the characteristics of a change becomes clearer during assessment, the ownership of a change can be reassigned to a more appropriate person if necessary.
More detail on the change control competency and how this relates to each project delivery role can be found in the Project delivery capability framework.
22.6 How to control change
22.6.1 What to consider when controlling change
22.6.1.1 Identifying the right decision-makers at the right level
Decisions on change requests should be made by those who have the authority to do so, within their assigned tolerances and who own the affected configuration items. If the impact of the change request goes beyond their authority, then either a higher level of decision-maker is needed or agreement sought from the impacted owner. The change control manager normally coordinates such escalations, often working with a change control board which oversees the change control process. The change control manager and board view changes in the aggregate, channelling, and prioritising change requests. If the change impacts another portfolio, programme or project, the decision maker should have accountability for balancing the competing needs of the work. Under such circumstances, decisions are often made at an organisational level, for example a portfolio board or investment committee.
To ensure effective decision-making a tiered system of delegation should be defined and established in the change control framework (see 22.6.3.2 on developing the change control framework). Portfolio, programme and project managers should have permissible tolerances within which they can approve changes without escalation. There are normally several levels for review and authorisation of changes depending on the level of impact of a change, for example, impact on baselined plans, approved business case or wider impacts on other projects, programmes or portfolios.
The need for escalation and the complexity of assessing some changes can make the assessment of change requests seem lengthy. This can be mitigated through good traceability management practices, delegation and separation of the work into streams which are focused on objectives, thereby making decisions possible at a lower level without compromising other work. Nevertheless, timescales for assessments need to be realistic or the quality of information for decision makers could suffer.
22.6.1.2 Assessing changes to an appropriate level of detail
The data needed to manage change requests can be effectively held in a change control register. The detail needed can vary depending on the individual portfolio, programme, or project’s needs. Enough information should be recorded to enable decisions to be made and action taken. The choice of tools and the experience of the team can also influence what needs to be collected and held.
22.6.1.3 Using change windows for solution design changes
Assessing and approving changes to the solution design can be managed more effectively if changes are grouped for implementation during specific periods. This is often the approach used for software changes. This period is called a ‘change window’ and it helps assess the aggregated impact of changes, which can then be implemented more efficiently. The use of change windows can help reinforce discipline around change control.
22.6.1.4 Being open and collaborative
The record of changes should be open to the core team so they are aware of what is proposed, and can take a view on whether their work could be affected. Such openness can help identify undiscovered problems and promote collaboration within the team. A view on all the changes can also show how stable the work is, with multiple changes indicating that the solution and plans are volatile and that risks need managing. This can also serve as a source of lessons for improving future working practices. Progression in the register also shows achievement in the disciplined control of change.
22.6.2 Preparing to control changes
22.6.2.1 Understand the wider governance and management framework
Understand the wider governance and management framework for the sponsoring organisation, portfolio, programme or project, as appropriate. Within this, understand how change control, issue management and risk management work together (see Figure 21.1) and, importantly, how decisions for changes can be escalated from one level in the project delivery hierarchy to another. All the planning and control practices need to work together both within a level and across levels. Consider how change requests are to be reported, so that there is consistency within and across those levels.
In addition, it is necessary to understand how change control interfaces with:
- traceability management as it includes the management of configuration items and baselines (see Chapter 23: Traceability management)
- planning as it is essential for implementing a change (see Chapter 16: Planning)
22.6.2.2 Understand the nature and context of the work
Develop an understanding of the context and nature of the work, such as understanding its complexity, scale and interdependencies with other programmes, projects and work. This informs the choice about which aspects of the work should be subject to change control and who should have authority for decisions.
The more complicated or complex the work is, the harder it is to control change efficiently and effectively and the change control process and tools need to be chosen to reflect this
22.6.2.3 Choose the appropriate tools and processes
Once the scale and complexity of the work is known, appropriate tools and processes can be defined, together with the resources needed to use them. For simple solutions or when the work is outsourced or contracted out, the data can be handled through spreadsheets. For more complicated solutions, specialist tools are needed to manage the volume of data and relationships and make it available to those who need it when they need it. The processes need to interface with the traceability management processes and are usually dependent on the same tool.
22.6.3 Key activities in controlling change
22.6.3.1 Overview
Change control requires a systemic approach to identifying, assessing, planning, making a decision on, implementing, and closing changes through the life cycle. It also requires a defined framework to govern and manage these activities, overseeing change control and closing the change control environment.
These related activities are shown in Figure 22.2. These may be sequential or iterative, depending on the nature of the portfolio, programme or project.
22.6.3.2 Develop and maintain the change control framework
The approach to change control should be defined including any processes, methods, tools and techniques to be used. This forms part of the overall governance and management framework for the work (see Chapter 4: Governance and management). The important considerations of this activity are discussed in more detail in 22.6.2. The framework should be maintained to address relevant feedback from its use.
22.6.3.3 Oversee change control
Change requests can come from different sources and can relate to the same part of the work. It is therefore often not desirable to consider each of them in isolation nor, if approved, implement them immediately, as this can be inefficient or lead to contradictory requests being implemented. An important part of overseeing change control is to identify where change requests are better managed as a bundle (in aggregate), merged or redefined. Having good traceability makes this task easier.
A systemic view also ensures that the change control continues to fulfil its purpose and meets the needs of the work. This also includes the maintenance of the control framework and providing periodic reports on changes and trends (see Chapter 18: Reporting).
The context and nature of the work could change throughout the life cycle. Therefore, the change control framework should be under continuous review to ensure it remains effective.
22.6.3.4 Identify a change
Identifying a change is when a change is proposed and a change request is put forward, formally registered and verified.
A change request can originate from any stakeholder, including ministers, policy makers, executive management, end users, suppliers, or team members. Alternatively, a change might result from responding to a threat that is above tolerance, an opportunity that could be exploited or an issue that cannot be resolved within the current constraints.
Once put forward, the change request should be registered and an owner assigned by the change control manager.
22.6.3.5 Assess and plan the change
The change request should be assessed and validated to understand its impact on baselines for the plan, solution design and the management documentation, interdependent work and whether it is necessary or desirable. Where necessary, supporting information or evidence can be sought. If the impact is not fully understood decisions may be based on incorrect assumptions.
The change request should be classified in accordance with the pre-defined categorisations in the control framework. The assessment of a change request can either be simple or detailed, depending on the nature of the change. A preliminary simple assessment can help determine if a more detailed or impact assessment is needed. There are different techniques that can be used to evaluate the possible options (which should include doing nothing) and their impacts. The Government Functional Standard for Analysis and the Aqua Book (requires sign in) provide useful guidance on how to carry out such assessments.
The proposed change should be planned in draft (see Chapter 16: Planning), with an understanding of how to incorporate it into the wider work and implement it. Residual risks should be recorded and addressed. Those undertaking the assessment should make a recommendation on what course of action should be taken and why. Once the assessment and plan are ready for a decision, the change control register should be updated.
22.6.3.6 Decide on the change
After assessing a change request, a decision should be made on whether to approve, reject or defer the change. The decision should be backed by the impact assessment, supported by evidence where possible, including possible implementation options and taking account of the associated risks.
Where a change is necessary but cannot be accommodated within existing baselines, a decision to replan or reset baselines may need to be sought through agreed governance. If inability to make the change threatens the viability of the work overall then, this should be escalated through governance such as to the portfolio director or senior responsible owner.
The change register should be updated with the status and the change control manager, change owner, relevant team members and stakeholders notified.
22.6.3.7 Implement, monitor and report on the change
If a proposed change is approved, the change should be implemented in accordance with the plan, and the change control register updated. Relevant configuration items such as baselines, documentation, and deliverables should be updated (see Chapter 23: Traceability management).
Actions taken to implement the change should be monitored and reported to ensure that the change is being carried out effectively, and those who need to know about the change and its progress in implementation are informed, such as impacted team managers and stakeholders. Monitoring also enables changes to be made to the plan if any issues or additional risks are identified.
The change control register should be updated regularly to reflect the current understanding of the change as well as its impact and implementation.
22.6.3.8 Close the change request
A change request should be closed once the change has been confirmed as being implemented or rejected. The change control register should be updated.
Closed changes should be kept on the register, stating when and by whom as this information can be useful for identifying likely sources of risks when conducting lessons learned reviews (see Chapter 38: Learning from experience) and for maintaining traceability (see Chapter 23: Traceability management).
22.6.3.9 Close the change control management framework
Once the work has been completed and change control is no longer needed, the change control manager should close the management framework, retaining information and data in accordance with the delivery and sponsoring body’s information retention policy (see Chapter 24: Information and data management).
22.7 Further reading
- Government Project Delivery, Project delivery capability framework
- HM Government, Government Functional Standard GovS 010: Analysis
- HM Treasury, Aqua Book: guidance on producing quality analysis (requires sign in)
Updates
Page permissions updated for public launch.
First published for closed beta consultation.