Prince2 header
products page

PRINCE2 - Change control technique



General

There are 2 types of product that need control.





Specialist products

The development of which are the subject of the plan

Management products

These are required as part of managing the product and for establishing and maintaining quality, for example, End Stage Reports.
Examples of these management products are seen in the file ‘management products.doc’ in the product package.

This technique covers the control of specialist products.

There are two key elements to remember:

  • If a product is changed the Product Description should be checked for possible need to update it.
  • Once a product is approved, the Project Manager should only authorise any work that would change it after seeking approval from the Project Board.

As usual, if the programme or organisation already has procedures and forms make sure that they are compatible with the approach below.

Change control steps

Changes are treated via a type of Project Issue.

These changes could be:

Request for Change

  • A request to change what the project is set to deliver, for example, the specification of requirements.
  • A suggestion to improve one or more of the project’s products.

Off-Specification

  • A record of some current or forecast failure to meet a requirement.

The file ‘change control technique steps.doc’ contains a flow diagram of the necessary steps for recognising, recording and managing changes raised as a Project Issue.

Issue Log

Any issue will be raised as a Project Issue and given a unique number, the date received and the issue status.
This information is recorded in the Issue Log. A Product Description is given in the file ‘Issue log.doc’ in the product package.

Prioritise

All issues raised must be assessed for priority.

With the project in mind a system for prioritising changes could be:

Must

The final product cannot be produced or would fail without it.

Important

Not doing it would be inconvenient and a work around could be employed in the short term.

Nice-to-have

But not vital.

Cosmetic

Of no importance.

None

Does not involve any change.

The author of the issue will receive a copy of the Project Issue as acknowledgement of its entry into the Issue Log.

Simple issues, such as questions or misunderstandings should be answered immediately, giving a copy of the reply to the author, with the details and action recorded in the Issue Log.

Impact analysis

An impact analysis is carried out on the remaining issues.

The effect of the changes are assessed by considering:

  • What exactly would require changing including those of linked products?
  • What resource is required to make the change, for example, people and equipment?
  • What will be the impact on the Team, Stage and Project Plans would be?
  • Would the change create a deviation in project , stage or team tolerances?
  • Is there any impact on the Business Case?
  • Will any existing risks alter or would any new risks appear?

Following the impact analysis you should re-evaluate the priority.
This could be carried out by the Project Board or be delegated to a change authority who may make all decisions on Project Issues.

Authorisation

Change authority is covered in more detail elsewhere (see Change control).

Decisions on Requests for Change should only be made by either the Project Board or the delegated change authority.

For Off-Specification the Project Manager could try to solve the problem within the tolerance margins. This could mean extra activities form modifications to the plan(s).
Where the Off-Specification cannot be corrected within tolerance levels the Project Manager must follow the exception procedure, Escalating Project Issues (CS8) which will bring it to the attention of the Project Board in Giving Ad Hoc Direction (DP4).
If the Project Board accept the Off-Specification without any corrective action it is called a ‘concession’.

After impact analysis Project Issues are transferred to the Project Board or change authority.

Actions may be:

  • Reject the project issue
  • Put the issue in a pending status
  • Remove the cause of the problem
  • Ask for their implementation

Following this the Project Issue is returned to the Project Manager and the Issue Log is updated and an updated copy is sent to the author.

For any implemented Project Issue that may cause a deviation outside of stage or plan tolerances will be entered into an Exception Report.
This is covered in Escalating Project Issues (CS8).
The most likely result of this will cause the Project Manager to produce an Exception Plan detailing any necessary extra work.
This would be submitted via Producing an Exception Plan (SB6). Within this process the Project Board may be substituted by the change authority.

Impact analysis should consider the business, the user and supplier.
Make sure that all information is available before asking people to consider the impact.

Where a project is part of a programme you will need to consider where the decision base should be or to ensure that a programme representative is present on the change authority.

Non - PRINCE2 information

This product contains EVERYTHING in the publications:

Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.

And much more besides - at a fantastic price.