PRINCE2 Pitfalls: Why Projects Stall and How to Avoid Them

Projects that go wrong under PRINCE2 are usually blamed on bureaucracy, yet the method rarely asks for the paperwork people complain about. The real pitfalls are skipped tailoring, a business case nobody reopens, a project board that watches instead of directs, stage ends treated as forms, and tolerances nobody set. PRINCE2 7 has a principle or practice that answers each one, and this article pairs them.

Does PRINCE2 fail because it is too bureaucratic?

The complaint has a familiar shape. Somebody opens a forty-page initiation document for a two-week website change, the board meets every week to hear a status report it could have read, and every small request goes into a register before anyone looks at it. Weeks later the team concludes that PRINCE2 is slow. What they actually saw was the method applied at full weight to a job that needed a fraction of it.

PeopleCert, which owns PRINCE2 and runs its exams, does not describe the method that way. Its page for the PRINCE2 7 Practitioner says the course teaches you to apply and tailor the method to a project's specific needs, size, context and level of complexity. Tailoring is built into the method, so a project that never adapts anything is departing from PRINCE2, not following it.

The same description explains the second cause of the complaint. PRINCE2 is a description of good project management practice, and it has to be interpreted for each organization. When nobody sets a shared interpretation, every project manager reads it in a personal way and the organization ends up with several private methods under one name. People on the receiving end see inconsistent demands and call the whole thing bureaucratic.

So the useful question is not whether PRINCE2 is heavy but which part of it was applied badly. The sections below treat seven recurring pitfalls, say how each shows up in a meeting rather than in a document, and name what PRINCE2 7 offers as the remedy.

Which pitfalls do PRINCE2 projects fall into most often?

The table lists the seven that appear again and again when organizations adopt the method. They are drawn from how the method is described and from the failure patterns the guidance itself warns about, so treat them as a checklist for discussion and not as a statistical ranking.

Pitfall	What you see in practice	What PRINCE2 7 offers
No tailoring	The same documents and meetings for every project, large or small	The principle of tailoring to suit the project, recorded in the project initiation documentation (PID)
A board that does not direct	Monthly status meetings; nobody can say who decides what	Defined roles and the directing a project process
Tolerances never set	Either every wobble is escalated or nothing is until it is late	Manage by exception, tolerances and exception reports
A business case written once	The case that won approval is never compared with what is now known	The business case practice and continued business justification
Stage boundaries as paperwork	A ten-minute meeting that always ends in approval	Manage by stages and the managing a stage boundary process
Vague scope and endless changes	Small requests slip in with no decision behind them	Focus on products, product descriptions and the issues practice
Lessons logged and never read	The same mistake appears on the next project	The principle of learning from experience, lessons log and lessons report

Notice that all seven right-hand cells come from the principles, practices and processes the method already contains. None of them needs a new tool or a bigger template. They need the people who hold the roles to use what is there at the right size.

What happens when nobody tailors the method?

One template for every project

Picture a mid-sized insurer that adopts PRINCE2 and issues one document pack to every project. A change to a claims form that takes two weeks gets the same pack as a fourteen-month policy platform migration. The form project drowns in paper and the migration team, who know a full pack is unreasonable, quietly keep the pieces they like. Within a year the company has two groups of projects that both say they follow PRINCE2 and look nothing alike.

Twelve project managers, twelve methods

The second form of the pitfall is subtler. Project managers are normally the only people who get trained, so they alone know the method. Project teams, and more importantly the senior managers who govern projects, often do not understand their own role in it and see only the overhead. If nobody sets an organizational view of how the method should be used, each project manager interprets it personally, and the organization has effectively created many methods. The cure is a short house guide, agreed by the people who sponsor projects, saying which products are always produced, which are optional and how big a project must be before each applies.

What tailoring really changes

Tailoring is adaptation to the project's size, complexity, risk and environment. Done well it changes quantity and ceremony, never purpose. For example:

• A management product that fills a document on a large project may be a paragraph in an email on a small one.
• The number of management stages follows the risk and the planning horizon, so a short low-risk project may need two while a long uncertain one needs many.
• The project board can be small, with one person covering two of its roles where that is genuinely sensible.
• Reports can be weekly, fortnightly or conversational, as long as the board still gets what it needs to decide.
• The vocabulary and tools can follow the environment, including agile delivery inside a PRINCE2 governance frame.

What tailoring cannot do is remove the principles. A project that drops business justification, defined roles or management by exception is no longer running PRINCE2, however many PRINCE2 documents it produces. The tailoring decisions themselves belong in the project initiation documentation so the board approved them and the next project can learn from them. Tailoring is part of what the Practitioner exam covers too, and the PRINCE2 Practitioner syllabus sets out the areas it draws on.

How does a project board end up receiving reports instead of directing?

In PRINCE2 7 the project board is the group that holds accountability for the project: the Executive, the Senior User and the Senior Supplier. It authorises the project and each stage, sets the tolerances, makes decisions when a forecast says the plan will not hold, and confirms closure. The project manager runs the project day to day within the limits the board has set. The pitfall appears when the board attends meetings but does not use any of those powers.

Signs the board is watching rather than directing

• Agenda items are updates, not decisions, and the meeting would end the same way if nobody came.
• The Senior User and Senior Supplier cannot say what they personally committed to, because their responsibilities were never discussed.
• Decisions drift to the project manager because nobody above has asked for them, then land back on the board when something has already gone wrong.
• Board members send delegates who cannot commit their organization.

The fix is dull and effective. At the start, walk through the role descriptions with each person who will sit on the board and agree what they decide, what they are told and what they are asked. PRINCE2 calls this defining roles, responsibilities and relationships, and the organizing practice is where the detail lives. Project assurance, which the board owns, is a separate check that the project is on course and should not be left to the project manager alone.

Tolerances nobody set

Manage by exception only works if there is something to manage against. A tolerance is the permissible deviation above and below a target before the matter must go to the next level. A stage might carry a tolerance of five working days on time and a modest allowance on cost, with no tolerance at all on a scope item that a regulator fixes by date. The board gives those limits to the project manager at the start of the stage, and the project manager gives a work package tolerance to each team manager.

Without tolerances two opposite failures occur. In one the project manager escalates everything, so the board drowns in detail and starts to micromanage. In the other nobody escalates until the plan has already failed, because there was no agreed line to cross. Once a forecast shows a stage heading outside its tolerance, the matter goes up in an exception report, and the board then chooses between a new plan, a change of scope or closing the project early.

Micromanagement is the same pitfall seen from above

Senior managers who lack a clear role often fill the gap by checking everything. This is common among newly promoted managers but appears at every level, and project teams that are constantly checked cannot get absorbed in their work. Management by exception gives senior people a way to stay in control without hovering, because they are alerted only about forecast breaches. A communication management approach that covers the whole team, with regular short meetings, means people raise issues in a scheduled place instead of through endless informal updates.

Why do the business case and stage boundaries turn into paperwork?

A business case written once

The business case is often written to win approval and then filed. Costs change, a competitor moves, a regulation arrives, a benefit turns out to depend on a department that has since been reorganised, and the document still describes the world as it was on approval day. The principle of continued business justification says the opposite: the project has to stay worth doing, and someone must be able to show that at any point.

The working remedy is a standing question at every stage end. Knowing what we know now about cost, risk and benefits, would we start this project today? The Executive owns the case and the Senior User answers for the benefits, so both should be asked. The business case practice also covers the benefits management approach, which says how and when benefits will be measured, including after the project has closed. A project that reaches its end on time with benefits nobody can find has failed the case even if it passed every other test.

Stage boundaries as forms

A management stage is a section of the project the board commits to and plans in detail. At the end of each one, the managing a stage boundary process produces an end stage report, an updated business case and the next stage plan, so the board can decide whether to authorise the next stage, ask for a revision or stop. The pitfall is a boundary meeting of ten minutes where the answer is always yes because nobody prepared a real choice.

Consider a nine-month system rollout run as one single stage. The board approved it, nobody reviewed it until month nine, and by then two suppliers had changed and a third of the benefits had gone. Splitting it into stages of about six to eight weeks would have given the board a planned moment to ask whether the rollout was still justified, with fresh costs and risks on the table. Stage length is a tailoring decision, and too few stages is as damaging as too many documents.

A boundary is also where planning stops pretending. Detailed planning beyond the next stage is guesswork, so the project plan stays high level and the stage plan carries the detail. That keeps timelines realistic and answers the habit of promising a quick delivery to please a client. When the first stage shows the original dates were optimistic, a new version of the project plan is a normal outcome, not an admission of defeat.

How do vague scope and unread lessons creep in, and what stops them?

An unclear goal and the quiet change request

Every good project has a clear goal, and it is easier to assign work and correct problems when everyone knows the end point. Even a small change, like adjusting the colour of a logo, can cause delays, and when little changes go unchecked they can ruin a project. PRINCE2 helps in two ways. The project initiation documentation records objectives, scope and exclusions, and the principle of focusing on products turns scope into products with product descriptions that include quality criteria. If a request does not match a described product, someone must decide it on purpose.

That decision runs through the issues practice. An issue is anything that needs management attention, including a request for change, an off-specification and a problem or concern. Handling follows the same steps for each: capture the issue, examine its impact on the project objectives, propose a course of action, decide, then implement. The project manager can decide small matters within delegated limits, while anything beyond them reaches the board, so scope moves only when a person with authority agrees.

Lessons logged and never read

The principle of learning from experience asks for lessons to be sought at the start, recorded as the project proceeds and passed on at the end. The pitfall is a lessons log that grows quietly and is read by no one, followed by a closing report written for compliance. A cheap remedy is to appoint a person to read the log at every stage planning session and to check earlier projects' lessons during start-up, before the plan is written. If the lesson about supplier lead times was recorded last year and ignored this year, the weakness is in the habit, not in the log.

How can you check a live project for these pitfalls this week?

A review need not take longer than an hour with the project manager and one or two board members. Work through six checks in order, writing down the answer to each.

1. Is the tailoring written down? Find where the project initiation documentation records what was adapted and why. If it is silent, hold a short conversation to record it now.
2. Can each board member state their decision rights? Ask them separately. If the answers differ, the roles were never settled.
3. Which tolerances apply to the current stage? There should be a range for time, cost and the other areas that matter, and the project manager should know who hears first if one is forecast to break.
4. When was the business case last tested? If the answer is the day it was approved, schedule that test at the next stage end and invite the Senior User.
5. Do the products have quality criteria? Pick one deliverable and look at its product description. If nobody can say how acceptance will be judged, scope disputes are coming.
6. Who reads the lessons log? Name the person and the moment. If neither exists, add the review to the next stage plan.

None of these checks adds a document. Each asks whether something that already exists is being used. Run them again at every stage boundary and the pitfalls tend to disappear before they become visible to a sponsor.

What does the PRINCE2 7 Practitioner exam ask about applying the method?

Everything above is the territory of the Practitioner exam, which tests application instead of recall. You are given a scenario and asked what the project manager or the board should do, which means spotting a pitfall in the story and choosing the answer that applies the right principle at the right size. The paper is open book, so what is measured is whether you can find and use the guidance, not whether you can recite it. PeopleCert's page for the PRINCE2 certifications lists the Foundation and Practitioner routes, including the prerequisites for sitting Practitioner.

Item	PRINCE2 Practitioner
Exam	PeopleCert PRINCE2 Project Management Practitioner (Version 7)
Questions	70
Duration	150 minutes
Passing score	60%
Fee	USD 500
Open book	Yes, according to PeopleCert
Vendor	PeopleCert

One detail is worth a sentence. PeopleCert's own page describes the paper as worth 70 marks, so read the 70 above as the paper's size in marks and check the current wording on the vendor page before you book.

A habit that helps for both the exam and the job is to take a project you know and ask which of the seven pitfalls it shows, then find the passage in the guidance that corrects it. Working through the PRINCE2 Practitioner practice exam afterwards shows whether you choose the tailored answer when a scenario tempts you toward the heavier one.

Frequently Asked Questions

How long is the PRINCE2 7 Practitioner exam and what is the pass mark?

The PeopleCert PRINCE2 Practitioner (Version 7) exam is listed at 70 questions in 150 minutes, with a passing score of 60%. PeopleCert describes the paper as worth 70 marks, so confirm the current wording on its exam page before you book.

Is the PRINCE2 Practitioner exam open book?

Yes. PeopleCert states that the Practitioner exam is open book, so you may consult the permitted guidance during the paper. That does not remove the need to prepare, because the questions are scenarios and you must find and apply the right passage quickly.

Do I need Foundation before taking PRINCE2 Practitioner?

PeopleCert lists prerequisites for Practitioner. Completing PRINCE2 Foundation (Version 7) qualifies, and so do certain earlier PRINCE2 editions and other project management credentials that PeopleCert names on its page. Check the current list there before you register for the exam.

How much does the PRINCE2 7 Practitioner exam cost?

The exam is listed at USD 500. Bundles with training materials, mock exams or a free retake cost more and vary by country, so look at PeopleCert's purchase options for your location before you decide which package suits your preparation.

Does the PRINCE2 7 Practitioner certification expire?

PeopleCert marks the Practitioner certification as subject to renewal and states that 60 CPD points are needed to renew it. You can log points through PeopleCert Plus membership or keep the certification current by passing another exam in the same product suite before the renewal date.

Select ratingPoorOkayGoodGreatAwesome

Rating: 4.9 / 5 (85 votes)