- Pass The PRINCE2 Exam First Time
- PRINCE2 In Bite-Sized Chunks.
- Key Foundation and Practitioner Learning Points - PRINCE2
- Change Management
- Managing and Controlling a PRINCE2 Delivery Stage
- PRINCE2 Project Closure
- PRINCE2 Starting Up A Project Process
- Using PRINCE2 Initiating A Project Process
- PRINCE2 Authorizing Initiation
- The PRINCE2 Controlling a Stage Process
- Appoint The Executive and Project Manager
- Authorising a PRINCE2 Project
- Authorize a Stage or Exception Plan
- Authorize a Work Package
- Capture and Examine Issues and Risks
- Change Control
- Change control procedures
- Configuration Management
- Configuration Management and Change Control
- Controlling a stage
- Create the PRINCE2 Communication Management Strategy
- Creating a PRINCE2 Plan
- Design and appoint the Project Management Team
- Execute a PRINCE2 Work Package
- Give Ad-hoc direction in a PRINCE2 project
- Hand over products and evaluate a PRINCE2 project
- Managing A Stage Boundary
- Managing Product Delivery process
- PRINCE2 - Authorise Project Closure
- PRINCE2 - Directing a Project PRocess
- PRINCE2 Configuration Management and Change Control
- PRINCE2 Controls and Tolerance
- PRINCE2 Estimating Techniques
- PRINCE2 Management Stages
- PRINCE2 Plans
- PRINCE2 Principles
- PRINCE2 Product-based Planning video
- PRINCE2 Product-based planning technique
- PRINCE2 Progress reporting
- PRINCE2 Quality Theme
- Plan The Next Stage or Exception Plan
- Plan the Initiation Stage in PRINCE2
- Prepare the PRINCE2 Quality Management Strategy
- Prepare the Risk Management Strategy
- Prepare the outline Business Case
- Product Based Planning
- Project Board and Project Manager PRINCE2 Controls
- Project Startup
- Quality Expectations and Acceptance Criteria
- Quality Management Strategy
- Quality review technique
- Report Highlights
- Reporting PRINCE2 Stage End
- Select the project approach and assemble the Project Brief
- Set up the PRINCE2 project controls
- Simple Study Aid
- Tailoring PRINCE2 Themes
- Take corrective action
- The Closing a Project Process
- The Controlling a Stage Process
- The Core Seven
- The Only PRINCE2 Sample Practitioner Exam Paper On The Internet!
- The PRINCE2 Business Case
- The PRINCE2 Change Theme
- The PRINCE2 Initiating a project process
- The PRINCE2 Process Sequence
- The PRINCE2 Processes
- The PRINCE2 Quality Review Technique
- The PRINCE2 Risk Management procedure
- The PRINCE2 Themes
- The Prince2 Process Sequence
- The risk management procedure
- prepare for planned or premature closure
- The PRINCE2 Article Library
- 38 Speedy Power Keys For Your PRINCE2 Project Health Check.
- Carrying out a PRINCE2 Quality Check
- The Product Description
- The plans theme and product based planning
- Creating a PRINCE2 Product Description
- PRINCE2 - Keeping Your Project On track - Part 2
- PRINCE2 Article Database
- PRINCE2 – Keeping Your Project On Track – PART 1
- Tailoring PRINCE2 for a feasibility study.
- Tailoring PRINCE2 with Agile (DSDM Atern)
- The Benefits Review Plan
- The PRINCE2 Risk Theme – Uncertainty Mastered!
- The PRINCE2 Work Package
- The Secrets Of tailoring PRINCE2
- The Use and Content of the Issue Register and Issue Report
- Applying earned value calculations to PRINCE2.
- PRINCE2 Foundation and Practitioner Exam Tips
- Using Project Sc ale In A PRINCE2 Project
- Creating a PRINCE2 Exception Report
- Agile verses PRINCE2 - a new species in evolution
- PART TWO of my Configuration Management In PRINCE2 Video
- PRINCE2 Quality
- Real-World PRINCE2 Planning
- Reviewing the progress on a PRINCE2 project
- Risk management
- Things You Might Not Know About PRINCE2
- The PRINCE2 Project Board and Governance
The PRINCE2 Change Theme
PRINCE2 In Bite Sized Chunks.
The technique for change control.
The PRINCE2 Manual uses the Change Theme to describe how change control should be executed.
In PRINCE2, 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.

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, 'general' issues could include:
- a question or query
- a good idea
- an observation
- a concern
There are also general issues:
- an unavoidable risk occurring
- advice of a new risk

Remember, a risk is something that has yest 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 occured", 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/Workpackages, the relevant activities and resources to manage the risk.
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.
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.
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.
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.
Request For Change/Off Specification management.
If either an RFC or Off Specification would cause forecasted Tolerance to be exceeded - then the 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...)
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.
The Project Board are usually senior people, and they may consider that having to authorise (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.
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.
If such a budget is not made available, then any changes beyond budget or ProjectTolerance 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, should be entered into the Issue Log and categorised. All issues should be given a priority rating (ie. Must Have, Nice to have, ect). After Imapct 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.
The 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:
- Agree to the change
- Agree to the change being implemented (possibly by approving an Exception Plan if the change would have caused the original Plan to exceed Tolerance)
- Reject the change
- 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.
- They may remove the cause of the issue - thus remedying the need to resolve the issue itself
- They may decide to prematurely close the project
For more information CLICK HERE



