Implementing PRINCE2 Step-by-Step

Implementing PRINCE2 in project management can appear daunting due to its comprehensive structure. However, a gradual approach can ease this transition. Starting with basic elements such as governance structure and status reporting, then incrementally introducing more complex components like risk management, issue management, and project briefs can make the process more manageable. 

Step-by-Step

This patient, step-by-step implementation allows stakeholders to familiarize themselves with the method without feeling overwhelmed, ultimately leading to a fully integrated PRINCE2 framework that enhances project outcomes.

From Projects to Products. Is PRINCE2 Still Relevant?

A common misconception often encountered in the business field is the perceived conflict between project management and product management. However, the reality is much different: these two methods can be successfully combined, each complementing the other in achieving overall business goals.

PRINCE2 and Product Management can be viewed as two sides of the same coin, offering different perspectives but working towards a common purpose. 

Approaching PRINCE2 Management Approaches

Stakeholders can get annoyed if we are hitting them with text heavy project methods without creating sufficient value. A PRINCE2 template lends itself to abuse, tempting the author to document where no documentation is needed or to generalize where specifics are needed.

A particularly difficult and vulnerable area is the PRINCE2 Management Approaches where you easily end up generalizing or stating the obvious.

Making a Difference

As a project manager, you are advising the project board on what needs to be done to make sure the project succeeds. A good advice is an advice that is actionable and makes a difference. All sentences, paragraphs or chapters in the management approaches should fulfill or support the following criteria:

What is the Issue?

What is really the issue? Your project is in trouble, you have a concern or a change request is coming your way. It can be tempting to describe a PRINCE2 Issue by the consequences it causes. Sometimes issues are named Project Delay, Extend Stage, Extension of Project, Higher Cost or similar. These are typically the consequence or a recommended decision of the issue, not the issue itself. 

When looking at an issue we should ask ourselves "Why?" -

PRINCE2 Quality Management Approach

During Initiating a Project, the project manager is asked to clarify and document the Quality Management Approach as part of the Project Initiation Document (PID). The quality management approach describes how the project will manage quality - what we will do to make sure the projects products are “fit for purpose”?

If you are in an organization with complete and detailed standard operating procedures (SOP) covering quality management, and those produces are well implemented and used, your Quality Management Approach description should be quite slim and should focus on areas where the SOP is weak.

Below are some questions you should ask when clarifying and documenting the Quality Management Approach.

Issue Rating Scales

When an Issue is captured, the next step is to examine the issue by undertaking an impact analysis. The impact analysis should include rating the issue on severity and priority, but what scales should you use?

In the PRINCE2 Change Management Approach, part of the Project Initiation Document (PID), you are asked to define the scales for severity and priority. The PRINCE2 Change theme doesn't give you any examples or specific recommendations on which rating levels to use. Here is one suggestion that might help:

Yes, It is a PRINCE2 Issue

The PRINCE2 Issue Register and the Issue Reports are crucial tools to keep your projects under control. This is where all important decisions and changes are reported and tracked.

Some feel there is a negative connotation to the word “Issue”. As a consequence, they underutilize issue reporting and the issue register. The end result is either poor traceability of decisions and changes, or unnecessary use of additional tools like a “decision log”.

If there is a change request to an already approved baseline, something is not delivered as promised, or guidance or a decision is needed on a problem, then it is a PRINCE2 Issue.

Here is some practical guidance:

Risk Assessment Scales

In the PRINCE2 Risk Management Approach, part of the Project Initiation Document (PID), you are asked to define the scales for probability and impact. In the PRINCE2 Risk theme you find an example using five levels of probability and five levels of impact.

This is a easy and straight forward way of scaling probability and impact, and you can make a nice 5x5 probability impact grid for visual purposes. But, PRINCE2 doesn't give you any help to define the levels of impact. Here is one suggestion that might help:

PowerPoint PRINCE2 Project Brief Template

In complex environments with high level of ambiguity, rich content in the shape of a document might be needed to describe objectives, scope, products, approach and roles. But for some projects, the context is known and the project environment quite clear. In these cases more structure can compensate for less rich content, and a PowerPoint slide deck might do the job as a project brief.

PRINCE2 2017

Mid-2017, AXELOS launched a new edition of the PRINCE2 guidance. The updated guidance comes with new exams, both PRINCE2 Foundation and PRINCE2 Practitioner.

According to AXELOS, the new PRINCE2 2017 Foundation exam is leaner and more focused on the core of PRINCE2, while PRINCE2 2017 Practitioner is focusing on the practical skills. If you trained and certified on PRINCE2 2009 Edition, should you retrain for PRINCE2 2017?

PRINCE2 Project Brief – Scope vs PPD

A common challenge in PRINCE2 Project Briefs and PRINCE2 Project Initiation Documents (PID) is that the Project Product Description (PPD) is repeating too much of the Scope description. Repeating something previously described brings no added value, annoys the reader and potentially draws the attention away from other important points to get alignment on.

In addition, many struggle to get specific on the “Customer’s quality expectations” resulting in a Project Product Description filled with too many general statements. Sounds familiar? If so, the guidance below could be helpful.

When is it a project?

PRINCE2 is only suitable for use on projects, but how do we know if we have a project or if we have “business as usual” (BAU)?

“A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case”. This is the PRINCE2 definition of a project. It is helpful, but the definition is not always sufficient to help you judge if you have a project or a collection of tasks. Below you find some additional help.