.st0{fill:#FFFFFF;}

PRINCE2 Change Control 

 February 27, 2023

By  Dave Litten

PRINCE2 Change Control

Change Control in PRINCE2 projects

The PRINCE2 Manual uses the Change Theme to describe how change control should be executed.

In PRINCE2, whenever using change control, ALL changes are dealt with as a type of project issue. Put simply, they are:

1. General issues

2. Request For Change

3. Off Specifications.

PRINCE2 change control – General issues.

First of all, any general issue could be dealt with ‘face-to-face’ if appropriate – logging it as a ‘formal’ project issue would be done if that were the best and only option. As an example, a  ‘general’ issue change control could include:

  • a question/query
  • a good idea
  • an observation
  • a concern

There are also PRINCE2 change control RISK general issues:

  • an unavoidable risk occurring
  • advice of a new risk

Remember, in PRINCE2, a risk is something that has yet to happen, and MAY happen at some point in the future, whereas an issue has already happened. The last two items in the above list are issues “the risk HAS occurred”, and “we hadn’t thought of this new risk – now what is to happen?”

The “advice of a new risk” issue, would be logged, and the action would be to transfer it to the Risk Log and carry out first a Risk Analysis, and then, as part of Risk Management, building into appropriate Plans/Work Packages, the relevant activities and resources to manage the risk. Such actions may trigger the need for PRINCE2 change control.

PRINCE2 change control – Request For Change.

This is a change requested from the Customer/User side, and would, if implemented, cause a change to what had been originally agreed, to the Acceptance Criteria, Specifications/Scope. This therefore needs change control.

It might be a request to add or subtract to the original agreement. If you were having a house built, two examples might be you requesting an extra bathroom, or asking for a dividing wall to be removed. As such, any extra costs relating to this change should be paid for by the Customer/Users, and the PRINCE2 change control approach must be used.

PRINCE2 change control – Off Specification.

This covers errors or omissions either in work already carried out, or planned for the future. This will result in NOT being able to meet the originally agreed Acceptance Criteria, Specification/Scope.

An example similar to above, would be if the builder of your new house advises that they can’t include your patio area within the price. As such, any extra costs (either in re-work to fix the off-specification, or reducing the price to you), should be met by the builder under PRINCE2 change control.

Suppose that (possibly in order to meet your timescale…) you agreed to accept what the builder COULD give you ( that is, house without the patio), then in PRINCE2 terms, this is called a CONCESSION and is also dealt with under PRINCE2 change control.

Request For Change (RFC)/Off Specification management.

If either an RFC or Off Specification would cause forecast Tolerance to be exceeded – then the PRINCE2 Project Manager MUST bring this to the Project Board’s attention by raising an Exception Report. If the change is an Off Specification, the project manager would try to fix the problem using any available Tolerance (although optionally it may be prudent to seek advice from the Project Board…). This again, uses PRINCE2 change control.

But if the change is a Request For Change, the Project Manager MUST bring this to the attention of the Project Board – whether or not the change can be done within Tolerance. If the RFC can be done within Tolerance, the Project Manager would use the Directing a Project activity “Give Ad-Hoc Direction, as the means of communicating this and managing under PRINCE2 change control.

The Project Board are usually senior people, and they may consider that having to authorize (or not), all changes, that they should not be involved. In such a case, they may delegate their responsibilities to a “Change Authority”. This authority will act on the boards behalf and will be documented under the approach to PRINCE change control. The Configuration Management Strategy document will describe how your project’s change control system will be implemented.

Another possibility is that the Change Authority only handle lower priority/impact issues – say for example, under a certain cost, and the Project Board deal with all the rest. Another option (to be discussed during the Initiation Stage, and included in the Project Plan), is to include a Change Budget in addition to the Project Budget. This has the added advantage of ensuring that changes do not “eat” into cost Tolerance. Again, this is documented under your change control system.

If such a budget is not made available, then any changes beyond budget or Project Tolerance would require the Board to seek agreement from Corporate (or Programme) Management – since it was they that set Project Tolerance. PRINCE2 states quite rightly, that Project Issues should not be considered in isolation. This will greatly enhance decision-making.

Each issue should be considered in the light of any impact to the Business Case, Risks, Cost, Time – and should be carefully weighed against any such benefit, advantage or saving. Remember also, that if a product is to be changed, its Product Description should be checked to see if that too, needs changing.

All issues when raised under your PRINCE2 change control system, and should be entered into the Issue Log and categorized  All issues should be given a priority rating (ie. Must Have, Nice to have, ect). After Impact Analysis the Priority may have to be reconsidered by the Project Manager or Project Board. Any issues that are simple misunderstandings should be dealt with directly and the Issue Log updated to reflect this. For all other types, an Impact Analysis must be carried out as documented in your PRINCE2 change control system.

The PRINCE2 change control Impact Analysis covers:

  • What would have to change and what work effort it would take
  • What the impact would be on all plans (Team, Stage, Project), and whether this would cause deviation beyond Tolerance
  • What the impact would be on the Business Case and risks

Remember that the impact may be positive or negative (the Business Case might be improved as a result of the issue!)

One final point.

Whenever considering issue action, the Project Board (or their delegated Change Authority), have the following options when dealing with PRINCE2 change control:

1. Agree to the change

2. Agree to the change being implemented (possibly by approving an Exception Plan if the
change would have caused the original Plan to exceed Tolerance)

3. Reject the change

4. For Request for Changes, decide not to implement – but keep it “live” by placing it in “pending”
on the Issue Log. This might be implemented later or not at all.

5. They may remove the cause of the issue – thus remedying the need to resolve the issue itself

6. They may decide to prematurely close the project

Okay, so let’s summarize PRINCE2 change control:

No matter how many projects you will work on in your professional life, every single one of them will be subject to some form of change, whether it’s your customer changing their mind or specification problems, or the outside world changing, change is inevitable. So it needs the application of a PRINCE2 change control system.

It therefore makes good sense to embed a process for managing change – your PRINCE2 change control system at the start of each project, and this must include a systematic change control approach that covers the identification, assessment and control of any changes that arise.

In PRINCE2 all changes are treated as a type of project issue.  Any issues that the potential to impact the project’s performance targets of time, cost, quality, scope, risk and benefits.

It is often misunderstood, but be objective of issue and change control procedures are not to prevent changes, but rather, to ensure that every change is first agreed by the relevant authority before it is implemented within a PRINCE2 project.

PRINCE2 Configuration Management.

Configuration Management goes hand-in-glove with your PRINCE2 change control system.

The first important aspect to consider is the answer to the question “how will we know when a change is requested to what we currently have?”. The answer is to record the version details of each product, both management and specialist, once they had been signed off, and these are called a Baseline and these will feed into your PRINCE2 change control system.

Therefore, a prerequisite of affected PRINCE2  issue and change control is the establishment of an appropriate configuration and management system which records baselines for the project products and ensures that the correct versions are delivered to the customer.

There is therefore a very close relationship between change control and configuration management, for this reason the change control administration normally takes place within your configuration management group.  Within PRINCE2, configuration management is normally supplied from within Project Support.

It is therefore important that all issues and changes that may affect the projects PRINCE2 baselines, first identified, then assess, and either approve, rejected or deferred.

Configuration management is the technical and administrative activity concerned with the creation, maintenance and controlled change of configuration throughout the life of a product (or item).

A configuration item is an entity that is subject to configuration management. The entity may be a component of a product, a product or a set of products that form a release.

A release is a complete and consistent set of products that are managed, tested and deployed as a single entity to be handed over to the user(s). Issue and change control procedures need to be integrated with the configuration management system used by the project.

PRINCE2 uses the term ’issue’ to cover any relevant event that has happened, was not planned, and requires management action. It can be a concern, query, request for change, suggestion or off-specification raised during a project. Project issues can be about anything to do with the project – another great reason for implementing a PRINCE2 change control system!

Issues may be raised at any time during the project, by anyone with an interest in the project or its outcome. The different types of issue are:

  • Request for change.  A proposal for a change to a baseline. For example, the Senior User would like to upgrade the processor speed for an IT system to comply with the latest software release.
  • Off-specification. This is something that should be provided by the project, but currently is not (or is forecast not to be) provided. An example here, is a piece of functionality is missing, or a product that is missing.
  • Problem/concern.  Any other issue that the Project Manager needs to resolve or escalate. For example, advice from a supplier that they can no longer deliver one of the products specified by the customer.

Change Management in PRINCE2

It has been said that for projects, change is inevitable whether it comes from within the project or from external sources, then so too, must be change management!

For these reasons, whenever change occurs, it makes sense to have an agreed logical change management process that allows the project to identify, assess and control any potential and approved changes to the original baselines that where originally agreed for the project.

So what is needed is a systematic and common approach to change management.  Once the project plan and other key associated documents have been approved, these become the project “baselines” and can only be changed after approval by the appropriate authority — normally the project board.  Change control and hence change management is not there to prevent changes, but to ensure that every change is agreed by the relevant authority before implementation.

An important and vital element is the projects use of change control and configuration management . All products that the project produces is subject to configuration management, this includes management documentation as well as specialist products or deliverables.  It is important therefore to integrate the use of  change management and change control procedures with the configuration management strategy document and the system chosen to be tailored and used by the project.

The system that is set up to perform change management should also include the management of the general issues, and in particular how to capture issues and risks.  An Issue Register should be set up early in the project to capture and assist in change management and issues.  A configuration management strategy document must be created as part of planning and this defines the way in which changes and issues are to be managed and handled – hence to provide change management throughout the project.

The difference between an issue and a risk is that the issue has already happened, whereas a risk is something that may or may not happen — at some point in the future, but both can lead to the need for change management.

As part of change management, whenever an issue is raised, it may be managed informally — usually by the project manager, however if it is to be managed formally then the project manager would enter it into the issue register before proceeding any further.  The PRINCE2 methodology states that and Issue Report is created in tandem and contains supplementary information regarding that particular issue.

Types of Change Management.

Changes come in two flavours:

A Request For Change (RFC) which comes from the customer or user and is a request to change one of the project baselines in some way.  If there are any extra costs involved in implementing the RFC, then the customer would normally pay for it.  Since all RFC’s are a change to what had been originally agreed, it is normally the project board alone, who have the authority to agree  or otherwise such changes.

You can see here why it is important for the change management system to be agreed and documented since the whole management team as well as other stakeholders must use it if  project changes are to be kept under control.

Off Specification. These are normally raised from the supply-side of the project, and they detail some aspect that should be provided by the project, but currently is not – or is forecast not to be, provided.  This might include products or deliverables that are missing, or a product not meeting its specification or quality criteria.

At the beginning of a project it needs to be decided how changes and issues are to be prioritised, and it is usual that a ratings system might include terms such as, Must Have, Should Have, Could Have, or Won’t Have For Now. For obvious reasons, this is known as Moscow. Such definitions need to be agreed and built into your PRINCE2 project change management system.

Another aspect that needs to be decided is whether or not the project board or senior management wanted to be involved in reviewing all project changes.  If many changes are predicted then it may make sense for the project board to appoint a Change Authority who would make decisions on such changes on behalf of the project board.  In such cases, the “rules of engagement” needs to be determined and form part of your PRINCE2 project change management.

For example, it may be decided that the change authority only deals with low cost/low impact changes, and that all others are dealt with by the project board themselves.  Another aspect is setting up a change budget and change management is for the change of authority to use to fund any approved changes and their implementation.  Such additional budgets should be captured within the project plan before sign off. However, a change budget may be set up even if the Project Board decide to deal with changes themselves (and of course, documented in how the project is to perform change management), as it provides better control when dealing with such changes, and gives clarity to the management of the main project budget.

Change Management procedure

Here then, is the change management procedure itself…

Change Management – 1  Whenever a change or issue is raised, it should be categorised and entered in the issue/change register.

Change Management – 2  An impact analysis should now be carried out, and will normally involve relevant specialist team members.

The impact analysis should consider the change or issue impact (which may be positive or negative) on a variety of projects aspects such as:

  • Time
  • Cost
  • Quality
  • Scope
  • Business Case
  • Benefits
  • Risk

The change or issue should be prioritised, first, by the originator, and second, after impact analysis.  It is important when carrying out the above impact analysis, that representatives from the project business area, the users of the end products, and those who are supplying resources to the project — are fully involved so that a balanced decision can be reached.

Change Management – 3.  Having understood the full impact of the change or issue, the next step is to consider alternative options and proposing the best actions to take in order to resolve the issue or implement the change. A balanced view is needed and consideration should be given all these options on the projects duration, cost, quality, scope, benefit, and risk performance targets.  The advantages gained should be balanced against the impact of implementing the issue or change.

Change Management – 4. A decision is now needed whether or not to implement the issue will change.  For a request for change, this would normally need escalating to the project board for their decision, whereas an Off-Specification may be decided by the project manager if they have sufficient authority.

In all PRINCE2 projects, it is a principle that they will use Management By Exception where tolerance boundaries have been set, then should any proposed implementation deviate beyond these tolerances, the project board must be involved in the decision whether to implement or not. This too, MUST be documented and agreed as part of change management since it determines when a given change is escalated, and to whom.

During implementation, the project manager should ensure that its status is reported to the project board up to the point when the issue or change has been fully implemented.

PRINCE2 Masterclass

Fully compliant with the current PRINCE2 2023 Syllabus

5.0
Prince2 Practitioner Masterclass

Your Route To PRINCE2 Practitioner

Prepare for your PRINCE2 Foundation and Practitioner Exams with our famous on-line course with streaming HD Video Lessons, study guides and mock exams. In the last fifteen years we have had 6,000+ Academy students successfully transform their careers as PRINCE2 Practitioners.

  • Bite Sized Lessons  The sheer size of PRINCE2 can be daunting. The Masterclass will guide you through the syllabus in easy to consume bite sized lessons
  • Be prepared and confident for the exams  Test your knowledge in a fun, entertaining environment with the PRINCE2 Foundation & practitioner exam revision tools
  • Enjoy yourself!  This PRINCE2 Foundation & Practitioner online course is broken into bite-size lessons, combining leading edge multimedia and interactive exercises for optimum enjoyment and knowledge retention
  • Feel confident with full tutorial support  Benefit from fast access to experienced, one-to-one learning support as you study via email and phone, so there is no need to feel isolated while you are learning
  • Take your time  Study at your own pace by bookmarking your progress and picking up where you left off at a speed that suits you

Dave Litten


Dave has spent 25 years as a senior project manager for USA multinationals and has deep experience in project management. He now develops a wide range of Project Management Masterclasses, under the Projex Academy brand name. In addition, David runs project management training seminars across the world, and is a prolific writer on the many topics of project management.

The Projex Academy

related posts:

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Project Management Masterclasses