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?