3 Steps to Understand PRINCE2 in 1 Hour

PRINCE2 is a comprehensive project management method, and you can easily get lost in hundreds of pages of PRINCE2 theory.

Joining a course and signing up for certification is a good way to get some momentum, but you need to set aside 3-5 days to get this done.


 If your need is to get started fast or just need a good overview, you can set aside 1 hour to cover the following topics:

Does Design Input Replace PRINCE2 Product Descriptions?

There is one recurring question in most organizations introducing PRINCE2: “Does Design Inputs, like functional requirements or user requirements, for the end outputs of the project replace any Product Descriptions for these end outputs?”
 

The short answer is “no”. If you have detailed design input for a product to be made, there is no need to repeat these detailed requirements in the Product Description. This helps simplify the Product Description, but it doesn’t make it redundant because:
 

A Fool with a PRINCE2 Tool is Still a Fool

PRINCE2, with its generic method approach and the specific tribal language, is the perfect gift for a fool who needs a new tool to misuse. Throwing templates, processes and language around can create frustration at a steaming level.

Here are a few PRINCE2 implementation mistakes you should avoid if you don’t want to end up as the fool with the PRINCE2 tool:

PRINCE2 Issue Report - Structure Gives You Credit.

There are times when a project manager ad-hoc needs to inform, seek advice and possibly get a decision from the project board. A demanding PRINCE2 Project Board will expect the project manager to provide structured analysis of the situation and recommended solutions, not just serve the board unstructured information and problems.

The way a PRINCE2 project manager is dealing with this topic is through Issue Reporting. Using a PRINCE2 Issue Report template helps the project manager to provide structured and analyzed information. Here are a couple of Issue Reporting advices:

The PRINCE2 Pitfalls of the Initiating a Project Process

Initiating a project is mainly about building the project plan, setting up the rules (strategies) for the project and firming up the business case.

The Purpose of Initiating a Project process is to establish solid foundation for the project, enabling the organization to understand the work that needs to be done, but too often pillars of the foundation are weak. Rules have no value if they are irrelevant for the project or not agreed upon, and a plan loses its value if there is no ownership to it on the supplier side of the stakeholder table. 

Here are some common “Initiating a Project” pitfalls, and how to avoid them:

Keep a PRINCE2 Process Model within sight.

As a PRINCE2 Project Manager or a PRINCE2 Project Board member, you need to understand and remember the process and document flow in the PRINCE2 method. Eventually, a project manager will intuitively understand the processes and documents in detail, but even then, it is useful to have a tool keeping the overview in sight. This is why you should keep a printed version of a process map on your wall or next to you while studying and practicing PRINCE2. Here is a couple of different models at different levels:

The PRINCE2 Project Manager’s Most Important Task.

If you casually ask people what a project manager’s most important task is, you will get many different answers. “Deliver on time, scope and budget” is a common suggestion. Other popular views are “understand critical path”, “prioritize”, “make things happen” and “plan the project”.

The tasks mentioned above are certainly important. Plans need to be realistic, understanding of critical path is essential and making things happen in prioritized order is a key to success. These things combined will absolutely help the project manager “deliver on time, scope and budget”. However, sometimes the “delivering-on-time”-obsession can cause sub-optimal return of investment. Maybe scope should have been changed, time added or more money spent to maximize an opportunity. If so, it is not the project manager’s decision to make. So what does that tell us about the project manager’s most important task?

Scrum and PRINCE2 – Who gets the workpackage?

If your project includes one or several Scrum teams, you could end up is quite a debate on who takes which PRINCE2 role. The Scrum team is by definition self managed. Scrum defines two roles in addition to the team, the scrum master and the backlog owner.

 

The Scrum Master’s responsibility is limited to facilitating the Scrum process. The Product Owner controls the backlog. In theory, a small project can be executed by the Scrum team alone. The scrum master could then take a role as project manager. But, what do you do if it is a larger project? Who would you then consider to take the Team Manager role and with whom do you negotiate workpackages?

PRINCE2 Governance: Who is Accountable for the Project Plan?

Some Executives have the perception that a project plan is something they order from the Project Manager. The Project Manager is then challenged to tune the project plan to shorter timelines and lower cost. The result is an unrealistic plan, and the Project Manager is held accountable to deliver on it. No wonder many project managers are stressed and burned out.


If this scenario sounds familiar, you should read on, because the PRINCE2 Organization and Planning Themes are really a great help in these situations – especially if you understand how to utilize them. The key trick is to get the Senior Supplier to take ownership of the realism of the plan – and this is how you do it:

Avoid the “Risk Management by Reporting” Syndrome

A risk is an uncertain event that, should it occur, will have an effect on the achievement of the project’s objectives. A threat is a risk that could have a negative impact on objectives.

In some project environments, the main identified threats are realized more as a rule than an exception. This can happen despite diligent use of Risk Registers and appropriate risk reporting. At a glance, such a project might appear to use PRINCE2 risk processes, but when reviewed in more detail, a typical risk management syndrome will appear:

A Couple of PRINCE2 Business Case Traps

First, the Business Case is more than a Net Present Value (NPV) or Payback calculation. Some think a Business Case is a calculated number, but that is only a minor piece of the definition.

The PRINCE2 Business Case captures the reasoning for initiating a project. The Business Cases is created to help decision-makers ensure that the proposed initiative will have value and relative priority compared to alternative initiatives based on the objectives and expected benefits laid out in the business case.

There is a couple of business case traps you should avoid:

The PRINCE2 Project Manager – King or Facilitator

There seems to be two types of project philosophies:

1. You build a project kingdom where the project manager is the King.
2. You build a project and line organization matrix where the project manager is the facilitator.

So which one of these philosophies is a PRINE2 match? Which philosophy will fit your organization? Where do you want decisions to be made and who is accountable? Some management consultants will argue that “The Project Manager needs to be King”, but is this really true? Here is PRINCE2’s answer: