PRINCE2 2017 Common Misconceptions and Foundation Reasoning Guide
Strengthen understanding by separating concepts that sound similar but perform different management functions: risk versus issue, Board versus Project Manager, assurance versus quality assurance, reports versus records, tolerance versus target and output versus benefit.
Executive summary
Reason by purpose
When two terms appear similar, ask what management decision or interface each exists to support.
Follow authority
Many errors disappear when you identify who delegated tolerance and who owns the Business Case, stage, Work Package or product approval.
Track lifecycle timing
Project Brief, PID, stage reports and closure products exist at different points; placing the right information in the right process is central.
Do not memorise labels alone
Understand how principles, themes, processes and management products connect; the same concept may appear in several places but retains one management purpose.
How the supplied assessment material was used
The supplied sample questions and rationale were used as a cross-check for the concepts emphasised in the main 2017 training material. This article does not reproduce the wording of those questions or provide a copied answer key. Instead, it explains recurring distinctions that a practitioner should understand in order to apply the method consistently.
Many misconceptions are caused by recognising a familiar word but ignoring its management purpose. “Report”, “plan”, “assurance”, “issue”, “tolerance” and “approval” each have precise roles in the project system. The most reliable way to reason is to ask: what has happened, which management level is involved, what authority applies, what information is needed and which process is active?
The distinctions below are therefore useful beyond assessment preparation. They are practical safeguards against weak governance and confused accountability.
1. Output, outcome and benefit are not synonyms
An output is the specialist product delivered by the project. An outcome is the result of using that output. A benefit is a measurable improvement perceived as advantageous by relevant stakeholders. Delivery of an output does not automatically prove that the benefit occurred.
This distinction affects closure and the Business Case. The project can close after accepted products are handed over while post-project benefit reviews continue. The Benefits Management Approach identifies how benefits will be measured and who owns them after the temporary project team is gone.
Reasoning test: if the statement is about what the team builds, think product/output. If it is about changed operational behaviour, think outcome. If it is about measurable improvement such as reduced cost or improved service, think benefit.
2. Tolerance is delegated authority, not a target
Tolerance defines how far performance may vary before the next management level must become involved. Project tolerance constrains the Project Board, stage tolerance constrains the Project Manager and Work Package tolerance constrains the Team Manager.
A team should not aim for the outer limit simply because it is “allowed”. Nor should a Project Manager wait until the stage has actually breached tolerance. Escalation is triggered by the forecast that the limit will be exceeded. The purpose is to give the higher level time to decide while recovery options remain available.
Reasoning test: first identify whose plan is forecast to fail. Then identify who set that tolerance. Escalate one level up; do not jump directly to the highest authority unless the project structure specifically requires it.
3. Work Package issue versus project/stage exception
A Team Manager controls a Work Package within Work Package tolerance. If it is forecast to exceed that tolerance, the Team Manager raises the matter to the Project Manager as an issue. The Project Manager assesses whether corrective action can keep the stage within stage tolerance.
An Exception Report is used when the Project Manager forecasts a stage or project exception that requires higher authority. The Project Board may then request an Exception Plan. This is different from the Team Manager independently “raising an exception plan”.
Reasoning test: ask which management level currently lacks authority. The escalation mechanism follows the delegation chain.
4. Checkpoint, Highlight and Exception Reports serve different controls
| Product | Typical trigger | Interface |
|---|---|---|
| Checkpoint Report | Time-driven/periodic | Team Manager → Project Manager, Work Package progress. |
| Highlight Report | Time-driven/periodic | Project Manager → Project Board, concise project/stage progress. |
| Exception Report | Event-driven forecast of tolerance exception | Project Manager → Project Board or Board → commissioning authority as appropriate. |
The Daily Log is a working record of actions, informal issues and observations; it is not interchangeable with these progress-control reports. The End Stage Report is event-driven at the management-stage boundary and works with the next Stage Plan to support a Board decision.
5. Risk and issue are separated by uncertainty and time
A risk is an uncertain future event or set of events that may affect objectives. An issue is a relevant event or situation that has happened and requires management. A risk that materialises can create an issue, and an issue can generate new risks, but the management procedures remain distinct.
The Risk procedure is Identify, Assess, Plan, Implement and Communicate. The issue/change procedure is Capture, Assess, Propose, Decide and Implement. If something has already occurred, continuing to score its probability as if it were uncertain is conceptually wrong.
Reasoning test: ask “has the event happened?” If no, it can be managed as risk. If yes, manage the actual condition as an issue and consider any remaining future uncertainty separately.
6. Project assurance is not quality assurance
Project assurance is a Project Board responsibility inside the project governance structure and independent of the Project Manager. It provides confidence from business, user and supplier perspectives that the project is being conducted appropriately.
Quality assurance is an organisational management function outside the project-management team. It checks wider quality systems, standards and policies. Project support is different again: it provides administrative or specialist support to the Project Manager and team.
Reasoning test: if the activity represents Board interests and checks the project independently of the Project Manager, think project assurance. If it is an external organisational quality-system function, think quality assurance. If it maintains tools, records or administration, think project support.
7. Business Case accountability stays with the Executive
The Project Manager may develop, maintain and update the Business Case, but the Executive is accountable for it. This preserves business ownership of the investment decision. The Senior User supports benefit definition and realisation; the Senior Supplier protects technical/supplier feasibility.
Post-project benefits also should not be left with a Project Manager whose temporary role ends at closure. The Benefits Management Approach should assign continuing benefit responsibilities to the relevant permanent organisation.
Reasoning test: separate “who prepares the information?” from “who is accountable for the investment justification?” They can be different roles.
8. Project Product Description and Product Description are different
The Project Product Description concerns the overall project product and customer acceptance. It includes customer quality expectations, overall acceptance criteria, acceptance method/responsibility and project-level quality tolerance.
An individual Product Description concerns one controlled product and contains purpose, composition/derivation and detailed quality criteria, tolerance, methods, skills and production/review/approval responsibilities. Product Descriptions support quality review and product-based planning.
Reasoning test: if the question is “will the customer accept the project’s overall result?”, think Project Product Description. If it is “how will this particular product be produced, checked and approved?”, think Product Description.
9. Project Plan, Stage Plan, Team Plan and Exception Plan are not peers
Project, Stage and optional Team Plans form three management levels. The Exception Plan is a replacement plan created when a higher authority asks for a revised baseline after a forecast exception.
The Project Plan is high level and supports Board control. The Stage Plan is detailed for the current management stage and supports Project Manager control. A Team Plan, where useful, supports a Team Manager. An Exception Plan replaces the affected Stage Plan or Project Plan; it does not create a fourth management level.
Reasoning test: ask “whose control baseline is this?” and “is this normal planning or recovery from a forecast loss of tolerance?”
10. Management stages and technical stages solve different problems
Management stages are governance sections for resource commitment, authority to spend and Board review. They cannot overlap. Technical stages or delivery steps organise specialist work and may overlap. The two structures may align but do not have to.
For example, design and build can overlap technically while the project still operates inside one authorised management stage. Conversely, one technical phase can cross a management boundary if the organisation needs a formal investment decision before committing further resources.
Reasoning test: if the boundary is about Project Board authorisation and tolerance, it is a management stage. If it is about specialist lifecycle or skills, it is technical.
11. Starting Up a Project is not Initiating a Project
Starting Up a Project is a brief pre-project filter. It turns the mandate into enough information to decide whether initiation is worth funding: key appointments, lessons, outline Business Case, project approach, Project Brief and Initiation Stage Plan.
Initiating a Project performs the deeper work: tailoring, four management approaches, project controls, Project Plan, detailed Business Case, Benefits Management Approach and PID. Board authorisation of initiation therefore comes before Board authorisation of the full project.
Reasoning test: if the information is still outline and the decision is “should we invest in defining this project properly?”, think start-up. If the decision is “do we now understand enough to commit to delivery?”, think initiation.
12. Directing a Project is not constant Board involvement
The Project Board remains accountable throughout the lifecycle but delegates day-to-day management. It authorises initiation, the project, stages/Exception Plans and closure, and provides ad hoc direction. Routine Work Package coordination and stage monitoring stay with the Project Manager.
Manage by exception is not “no communication”. Highlight Reports provide routine visibility, and ad hoc advice is legitimate. It means the Board intervenes in decisions that require its authority rather than controlling every task.
Reasoning test: ask whether the matter is a key authorisation, governance decision, project-level exception or strategic direction. If not, it likely belongs at Project Manager or team level.
13. Quality planning precedes quality control
Quality planning defines expectations, acceptance criteria, product quality criteria, tolerances, methods and responsibilities. Quality control executes the tests, reviews and inspections and records the evidence. A late inspection cannot repair unclear acceptance criteria.
Approval of an individual product also differs from overall project-product acceptance. The Team Manager may obtain product approvals as part of Managing Product Delivery; closure confirms customer/user acceptance of the overall project product.
Reasoning test: “what should quality be and how will we check it?” is planning; “does this product meet the criteria?” is control.
14. Continued business justification means the project can stop
Continued business justification is not satisfied merely because a project was once approved. The Business Case is reviewed as new information emerges, particularly at stage boundaries and exceptions. If the project is no longer desirable, viable or achievable, the method supports controlled termination.
Money already spent is not a reason to spend more if the future case is no longer valid. Premature closure still requires handover/salvage, lessons, open risk/issue ownership, records and formal Board authorisation.
Reasoning test: ask whether the decision considers future value and current information rather than defending past investment.
A five-question reasoning method
Locate lifecycle
Are we pre-project, initiating, delivering, at a boundary or closing?
Locate authority
Board, Project Manager or Team Manager—who owns the current tolerance/decision?
Classify information
Baseline, approach, record or report—what function is needed?
Check trigger
Periodic status, event-driven decision, issue, risk or forecast exception?
Return to purpose
Which principle/theme/process purpose best explains the management action?
Use understanding instead of keyword matching
Keyword matching is fragile because the same product can appear in several processes. The Business Case is developed during initiation, updated at boundaries and reviewed during exceptions; that does not make all those processes interchangeable. Similarly, a risk can be reported in several reports, but the Risk Register remains the detailed record.
When uncertain, draw the delegation chain and product flow. Identify the Board, Project Manager and Team Manager; mark project, stage and Work Package tolerances; then ask where the relevant information moves. Many apparent ambiguities become obvious once authority and lifecycle are visible.
Finally, keep the scope of this guide in mind. It reflects the supplied 2017 training and assessment materials. It is intended as a conceptual handbook for that source set, not as a statement of later method editions or current certification arrangements.
Practical verification checklist
- Distinguish output, outcome and benefit before reasoning about value or closure.
- Identify the management level and delegated tolerance before choosing an escalation route.
- Separate periodic reports from event-driven controls.
- Treat materialised uncertainty as an issue while recording remaining future uncertainty as risk.
- Keep project assurance, quality assurance and project support distinct.
- Remember Executive accountability for the Business Case even when the Project Manager maintains it.
- Use Project Product Description for overall customer acceptance and Product Descriptions for individual product control.
- Treat Exception Plans as replacement baselines, not a fourth plan level.
- Separate management-stage governance from technical delivery stages.
- Use process purpose and lifecycle timing rather than memorised keywords.
Common mistakes to avoid
- Memorising isolated definitions without understanding who uses them and when.
- Assuming similar words such as assurance, approval and acceptance are interchangeable.
- Jumping escalation directly to the Project Board without checking the Work Package/stage authority chain.
- Treating all reports and registers as generic status documents.
- Assuming a project that has started must continue to completion.
- Using later-edition knowledge to silently reinterpret the supplied 2017 source.