The goals of this process are to:
- record and evaluate change requests;
- submit evaluated change requests for approval;
- communicate approved changes to stakeholders.
Change control is often seen as purely related to changes in scope. This process, however, has a wider remit and deals with any changes to baseline plans. A change request could, therefore, be a request to delay an agreed deliverable date or an increase to management reserves because of increased uncertainty.
Click on the diagram below for explanations of inputs, the process and outputs.
Inputs
- Plans
-
The current baseline plans are an input to this process as they will form the basis for assessing the impact of a change request.
- Change requests
-
Change requests are outputs of many processes. They are all received by this process and must then go through a procedure that assesses their impact on the objectives of the project or programme. If the impact is considered to be beneficial or necessary to protect existing objectives, then the change request will be approved. Otherwise it will be rejected.
-
Change requests can broadly take two forms:
-
A scope change request describes a change to a product or service delivered by the project or programme. The change must be assessed to ensure it is necessary to maintain or improve the business case.
-
A change request may also be issued to request a change to the baseline schedule or cost plans. Progress reports may indicate that the current baseline delivery plans cannot be achieved, in which case new plans are prepared and the business case re-assessed. If the sponsor approves the new delivery plans and adjusted business case, the change is approved and the baselines re-set.
Functions
Click here to see how the Praxis functions map to the detailed ISO21500 processes.
The control changes function takes change requests and uses the change control function to assess them. This assessment is performed against the criteria of achievability, desirability and viability as set out in the business case.
Records associated with change control are maintained by the configuration management function and communication with stakeholders is maintained at all stages.
Click on the diagram below to see more information about each function
- Business case management
-
Change requests have to be assessed to discover whether they are beneficial to the objectives of the project or programme. Since the viability of the work is embodied in the business case, this is the primary document for making that assessment.
-
Since the business case is based on functions such as investment appraisal and risk management, those functions are also implicitly invoked by the control changes process.
- Change control
-
Change control is a simple procedure that illustrates how change requests are gathered, assessed, accepted/rejected and the relevant stakeholders then informed of the decision.
- Configuration management
-
Configuration management is a function that maintains records of every product – whether an output of the direct work process or a management document. Configuration management can report on the development and history of change for any configuration item in the project or programme.
- Stakeholder management
-
Change requests will originate from some stakeholders and other stakeholders may be affected by them (if approved). Control changes should ensure that relevant stakeholders are consulted as part of assessing change requests, and also that affected stakeholders are kept informed of the results of the process.
- Interpersonal skills
-
Conflict management has been highlighted here because decisions resulting from the control changes process may cause conflict when stakeholders find their change requests are not improved.
-
Communication is clearly a key part of the process since inadequate communication can lead to conflict or simply mean that approved changes are not correctly implemented.
Outputs
- Approved changes
-
While approved changes are an obvious output of this process, it should also be noted that rejected changes are also an output.
- Change register
-
The change register will record all change requests, the results of their assessment and the action taken following their acceptance or rejection.
- Updated plans
-
ISO21500 does not explicitly list the updated plans as an output of this process but it is clear that any approved changes must be incorporated into the plans and any other documentation. These then become the revised baseline plans.
Projects and programmes
The principles of this process do not vary to any great degree as complexity increases.
At project level the focus will probably be on scope change requests, although in an agile environment these will be far less formal than in a non-agile environment.
Change requests relating to the baseline delivery plans are likely to be less frequent provided sufficient tolerances and reserves have been built into the plans.
As the work becomes more complex it will be increasingly decomposed into management pieces. This introduces the need to co-ordinate change at lower levels and assess its impact at higher levels.
For example, a project within a programme may assess a change request within the context of its objectives, business case and baselines and consider it acceptable. It is conceivable that this approved change has a detrimental effect on the programme when considered in conjunction with changes approved in other projects.
These sort of conflicts can be avoided by suitable delineation between projects and the allocation of appropriate tolerances and reserves. However, it is appropriate for programme level management to invoke this process in a light touch manner to maintain a watching brief over the projects that are applying it in detail.
Similarly, the programme management team may use the process to assess programme level change requests that have an impact on the component projects and change activities.
This process may be applied at different levels within a programme or large project. Care must be taken to communicate between the levels to ensure the integrity of the work as a whole.
