Guidance for effective PRINCE2 Change Control
The starting point for effective PRINCE2 Change control on your projects will be to identify whether there are any corporate, programme management, or customer policies and processes that need to be applied, and incorporate them into the project’s own change control approach.
If the project is within a programme or portfolio, there may be a requirement that the project uses its defined policies and processes.
In a commercial environment, the project may be required to adopt change control procedures and processes defined in the contract.
Issue management and change control may be treated as separate processes or procedures provided the relationship between them is defined.
The approach may be tailored to reflect any tools used, in terms of roles,
workflow and terminology
Project size, scale and complexity
You should ensure that the PRINCE2 Change Control approach is appropriate to project size, scale, and complexity.
It is also important to ensure that the PRINCE2 Change Control approach to a project provides support for effective decision-making on the project and does not create an undue burden or bureaucracy.
In general, smaller, simpler projects will need correspondingly simpler issue management and change control arrangements.
Managing product baselines
All projects need an appropriate approach to creating, maintaining, and controlling product baselines for both management and specialist products.
For simpler projects, document management procedures will generally
More complex projects will usually need some form of formal configuration management, asset management or product management process, often supported by specific tools.
Regardless of size, scale, and complexity, the project team needs to determine:
- the appropriate level at which products need to be baselined. This is generally determined by breaking down the project’s products until the level is reached at which a component can be independently released, installed, replaced, or modified.
However, the level of control exercised will be influenced by the importance of the project and the complexity of the relationships between its products
- how configuration items are identified. Generally, a coding system of some type will need to be established, providing a unique identifier for each configuration item
- the specific authorities and authorizations needed to approve and baseline configuration items
- what information about configuration items needs to be captured and maintained in configuration item records if used.
- It is good practice to periodically verify that the actual status of products reflects the authorized state of products as they are registered in the configuration item records, looking for any discrepancies.
This is usually through reviews or audits, typically undertaken at the end of each stage and at the end of the project.
The project’s delivery approach
It is important that the approach to managing issues and change works with, and supports, the project’s chosen delivery approach, rather than working against it.
For example, a PRINCE2 Change Control approach that defines there will be a monthly review of proposed changes is unlikely to effectively support an agile delivery approach where delivery may be happening every week or 2 weeks.
The appropriate definition of product descriptions, quality criteria, quality tolerances, and work packages is important.
They can be defined in such a way as to allow for change at the detailed level, while at the same time creating a clearly defined baseline that can prevent a change to the purpose of a product from going undetected.
Delegating to a change authority
The project board is responsible for reviewing and approving requests for change and off-specifications.
In a project where few changes are envisaged, it may be reasonable to leave this authority in the hands of the project board. But for projects where there are likely to be many changes, the project board may choose to
delegate some decisions to a person or group, called the change authority
The project manager and/or the people with delegated project assurance responsibilities may act as the change authority.
In practice, the majority of changes will be generated at the work package level.
It is important to ensure the change authority for work packages has sufficient delegated authority so that changes can be made without always having to escalate decisions to the project board for approval.
Establishing a change budget
A PRINCE2 Change Control budget is a sum of money that the customer and supplier agree will be used to fund the cost of requests for change, and possibly also their analysis costs.
Unless the anticipated level of change on a project is low, it is advisable for a budget to be set up to pay for changes.
This arrangement can reduce the number of trivial exceptions arising in projects where the frequency of requests for change is forecast to be high.
Including a PRINCE2 Change Control budget provides for a more realistic expectation of the overall costs/timeframe of the project.
Where a change budget is given to a change authority, the project board may wish to put a limit on:
- the cost of any single change, and
- the amount spent on change in any one stage without reference to the project board.
The change control procedure would then be defined in such a way as to control access to the change budget. If used, the change budget is documented in the relevant plan.
The project board should decide the need for a PRINCE2 Change Control budget.