The differences between PRINCE2 2005 and PRINCE2 2009

PRINCE2 was refreshed mid-2009 to give us the current version of the method. The changes made were partly to bring PRINCE2 terminology in-line with other APMG qualifications (such as MSP), but also to take account of feedback from the using community. However, because the method is intrinsically the same the upgrade was called PRINCE2 2009 instead of becoming PRINCE3.

So why does this matter? To people coming to the method afresh it doesn’t really, other than they can be assured that, as part of continuous improvement, the method embraces current thinking. However, because the practitioner qualification is valid for 5 years, after which time a re-registration exam is required, those who took their Practitioner pre 2009 version need to be aware of the changes for their re-registration exam.

Introduction of Principles

The first change to note is the introduction of the PRINCE2 principles. These were always implicit in the method but have now been brought out and emphasised. To be able to say that you are running your project in accordance with PRINCE2 you need to be adhering to these principles in some way. The principles are:

• Continuous Business Justification – making sure that you have a sound business reason for starting your project, and that reason remains in place throughout the project.
• Learn from Experience – mechanisms to ensure that you don’t repeat the same mistakes and do repeat positive lessons learnt.
• Defined Roles and Responsibilities – those involved in the project, especially the project management team, know and understand their responsibilities, which should be clearly documented.
• Manage by Exception – saving senior management time, the Project Manager is authorised to run the project on a day-to-day basis as long as serious problems are referred.
• Manage by Stages – the project is broken down into manageable chunks.
• Focus on Products – that the outputs (products) of the project are clearly identified and activities are focused on delivery of those products rather than activity for activities sake.
• Tailor to suit Environment – that the use of PRINCE2 is tailored to the complexity of the project and the circumstances of the organisation, ensuring that the right amount of process is used / applied to give adequate control without being overly bureaucratic.

Other general Changes

Components have been re-named as ‘Themes’ – this is in-line with other qualifications and the wording better reflects that these are things (themes) that run through the entire project. The Controls component has been re-named as ‘Progress Theme’.

The numbered sub-processes have been removed, and activities introduced in their place – so the numbering convention has been removed. Those learning PRINCE2 and taking the exams used to get overly concerned about remembering the sub-process numbering. That is no longer an issue.

A new chapter entitled Tailoring PRINCE2 has been added, which better emphasises the need to tailor PRINCE2 and provides some practical guides as to how this might be done.

Increased focus on using lessons learnt rather than just capturing them.

The Closing a Project process has been amended to better cater for premature closure situations.

The ‘Path to Quality’ has been re-named the ‘Quality Audit Trail’.

Planning has been removed as a process and now product based planning is incorporated within the Plans Theme and has its own appendix in the manual.
Configuration management (component) is now included within the Change Theme and has its own strategy (a ‘How To’ document). Also, Change Control has been dropped as a technique and is now embedded within the Change Theme.

Changes to risk management include the introduction of ‘Risk Management Strategy’, there is more emphasis on risk opportunities, and risk countermeasures have been re-named as risk responses.

Changes to Product Descriptions

The Communication Plan and Quality Plan have been re-named as ‘Communication Management Strategy’ and ‘Quality Management Strategy’ – this helps to emphasise that they are not like ‘regular’ plans with timescales and resources, but that they are more ‘How To’ documents.

The Post Project Review Plan is now re-named as the ‘Benefit Review Plan’ and it is created earlier in the project (during Initiating a Project) – both changes cater for occasions when products are released and benefits realised during the project’s life-cycle rather than just after its closure.

Three logs have been re-named as registers (Risk, Issue and Quality). The daily log and lessons log remain as logs. This helps reinforce that the registers are more formally managed products. Incidentally it also makes it easier to remember when they are created as both logs are created during Starting up a Project and the registers during Initiating a Project.

The Customers Quality Expectations and Acceptance Criteria are now recorded in the Project Product Description rather than being separate products, and the Project Product Description is the Product Description of the final product re-named.

Issue reports have been added to the product descriptions (these are change request forms by another name).