PeopleCert · Certificazione professionale
Tutto ciò che ti serve per prepararti alla certificazione Foundation: composizione dell'esame, programma di studio settimanale e molto altro.
Sezioni disponibili
Materiali disponibili dopo il riscatto del voucher
Certificazione · PeopleCert
Struttura ufficiale del syllabus — 60 domande · 60 minuti · soglia 60%
eLearning PeopleCert · 30–60 min/giorno
Piano strutturato su 8 settimane — spunta i task man mano che avanzi
2 mesi · eLearning PeopleCert · 30–60 minuti al giorno
PeopleCert · PRINCE2 Foundation v7
17 moduli — clicca su un modulo disponibile per accedere al contenuto
Module 02c · Chapter 12 of the manual — Processes Overview
I 7 processi PRINCE2 — il ciclo di vita del progetto dall'avvio alla chiusura
Ogni attività di ogni processo ha una RACI table che definisce le responsabilità:
Aiutano a gestire il progetto — non sono la consegna finale ma gli strumenti per arrivarci.
Es: Project Plan, Business Case, Risk Register, Communication Management Approach, End Stage Report. Descritti nell'Appendice A del manuale.
Sono il risultato del progetto — ciò che il cliente si aspetta. Hanno vita operativa dopo la chiusura del progetto.
Es: nuovo sito web, database aggiornato, edificio costruito, reparto riorganizzato. Non descritti in appendice: dipendono dal tipo di progetto.
Module 02b · Chapter 4 of the manual — Practices Overview
Le 7 pratiche di PRINCE2 — aspetti del project management applicati lungo tutto il ciclo di vita
Per ogni pratica, le domande d'esame si concentrano principalmente su:
Le pratiche non sono sequenziali — si applicano in modo costante lungo tutti i processi, dall'avvio alla chiusura del progetto.
I processi (7) definiscono cosa si fa e quando; le pratiche definiscono come si gestisce ogni aspetto.
Module 02 · Chapter 1 of the manual — Overview
Cos'è un progetto, i 5 elementi integrati e i concetti fondamentali
Output — il prodotto consegnato dal progetto
Outcome — il cambiamento generato dall'uso dell'output
Benefit — il miglioramento misurabile nelle performance di business. Non necessariamente finanziario (es. riduzione CO₂, awareness).
Non basta che il Business Case sia valido all'inizio — deve essere rivalutato ad ogni fine fase.
Se la giustificazione scompare, il progetto va fermato. Il mercato cambia, la strategia cambia: il BC si adatta.
Tradizionale (sequenziale) — i benefit arrivano solo al termine del progetto.
Iterativo/incrementale (Agile) — consegne parziali con early ROI, possibilità di correzione in corsa.
Ibrido — combinazione dei due approcci.
È il garante del Value for Money e del Return on Investment.
È accountability per i benefit — non solo per la consegna degli output. Troppi project manager si concentrano sugli output dimenticando i benefit.
Uno dei 7 principi. Si applica in due modi:
→ Lezioni da progetti precedenti (Lessons Log)
→ Retrospettiva a fine fase (stage boundary) per influenzare la fase successiva
Le persone sono al centro dei 5 elementi integrati. Comprendere gli stakeholder — chi sono, come sono influenzati dal cambiamento, come comunicare — è fondamentale.
Senza gestione del cambiamento, gli output vengono consegnati ma le unità operative non sono pronte: i benefit non si realizzano. (Cap. 3 del manuale)
Il gain atteso deve superare il pain in ogni fase. Il Business Case si rivaluta formalmente ad ogni stage boundary. Se la giustificazione scompare → il progetto si ferma.
Da progetti precedenti (Lessons Log) e da retrospettive a fine fase (stage boundary). L'apprendimento è continuo, non solo iniziale.
Struttura di governance chiara con ruoli ben definiti. Business, utenti e fornitori rappresentati nel Project Board. Nessuna ambiguità su chi decide cosa.
Il progetto è suddiviso in fasi sequenziali. Il Project Board autorizza fase per fase. Ad ogni stage boundary: retrospettiva + aggiornamento BC + pianificazione fase successiva (rolling wave planning).
Ogni livello opera entro tolleranze predefinite su 7 dimensioni: costo, tempo, qualità, rischio, scope, benefit, sostenibilità. Dentro tolleranza → autonomia. Fuori tolleranza → escalation.
Prima si definiscono i prodotti con criteri di qualità misurabili, poi le attività. Non si lavora "a caso" — si sa esattamente cosa si produce. Es: "pavimento legno + pareti bianche" invece di "rifare la stanza".
PRINCE2 è un mezzo, non il fine. Va adattato al contesto: dimensione, formalità, nomi dei ruoli. Es: "Executive" → "Senior Responsible Owner" (UK pubblico) o "Project Sponsor" (privato).
Module 01 · Chapter 1 of the manual — Introduction
Obiettivi del corso · Materiali di studio · Struttura dell'esame Foundation
Module 03 · Chapter 3 of the manual — People
People are central to the method — Leading successful change · Leading successful teams · Communication
Module 06 · Chapter 5 of the manual — Practice
Perché stiamo facendo questo progetto? Desirable, Viable, Achievable — il ciclo di vita del Business Case
Il documento centrale della pratica. Si sviluppa da Outline BC (nel Project Brief) a Full BC (nel PID), mantenuto e aggiornato per tutta la durata del progetto.
Definisce come, quando e chi misurerà i benefit — sia durante il progetto sia oltre la sua chiusura. Parte integrante del PID. Include la baseline "as-is" per confronto.
Gestisce gli obiettivi di sostenibilità del progetto (es. riduzione CO₂, documentazione cartacea). Chi misura, come si misura, quando. Anch'esso parte del PID.
PRINCE2 defines a four-step technique for managing the business case throughout the project lifecycle: Develop · Check · Maintain · Confirm.
An alternative organisational procedure may be used instead — but this must be documented as a tailoring decision in the PID.
Explore options and get the right information upon which investment appraisal decisions can be made. The project mandate activates Starting Up a Project, which produces the outline business case (in the project brief). During Initiating a Project the outline BC is refined into the full business case (in the PID).
Assess whether the project is (still) desirable, viable and achievable. Performed by the Project Board as a minimum at:
Keep the business case updated with actual progress and current forecasts (including forecast benefits). The PM reviews the impact of new risks and issues on the BC's continued viability, then updates the BC at the end of each stage as part of Managing a Stage Boundary.
Assess whether the intended benefits have been (or will be) realised. Confirming benefits mostly takes place after the project has closed, though benefits may be confirmed during the project when products are delivered iteratively.
Adjusting the input factors to model the point at which the output factors no longer justify the investment. It tests the robustness of the business case by revealing how sensitive it is to changes in key assumptions.
Evaluates investments from multiple perspectives rather than focusing solely on financial return. A robust investment must satisfy ALL perspectives.
When using an iterative-incremental approach (Agile), scope is flexible. Benefits should be expressed as a range (not a single target), relating to the amount of scope delivered. Three scenarios: Best case · Expected case · Worst case.
| Business Case Management Technique | Develop → Maintain → Check → Confirm. Fig 5.2 multi-investment model: investment perspective, options analysis, ROI (NPV, payback, IRR), risk analysis, sensitivity analysis. |
| Options analysis | Usually 3 options: do nothing, do the minimum, do the recommended option. Each option evaluated for desirability, viability, achievability. |
| Sensitivity analysis | Tests how the BC changes if assumptions change — e.g. if benefits are 20% lower, is the project still viable? |
| Organizational context | BC aligns to corporate strategy. In a programme: project BC aligned to programme BC. Benefits usually managed by the programme. |
| Commercial context | Customer and supplier each need their own aligned BC. Executive ensures compatibility. Supplier BC may be private. |
| Delivery method | Agile: BC may show best/expected/worst case for scope (Must/Should/Could). Benefits evolve through iterations. Higher uncertainty → test assumptions quickly. |
| Sustainability | Sustainability targets (e.g. carbon reduction, UN SDGs) documented as sustainability tolerances in the BC and sustainability management approach. |
| Business Case | Documents business justification: reasons, benefits, risks, costs, timescales, investment appraisal, options. Lives in PID. |
| Benefits Management Approach | How benefit measurement will be managed. Includes benefit tolerances, review schedule, responsibilities. Updated throughout project. |
| Sustainability Management Approach | Actions and controls for sustainability targets. May include ESG, UN SDGs, net zero commitments. |
| Business Layer | Sets mandate + standards for BC | Holds Senior User accountable for post-project benefits. Sets project-level benefits tolerance. |
| Executive | Accountable for BC throughout | Approves Benefits Management Approach. Ensures project remains desirable, viable, achievable. Secures funding. |
| Senior User | Accountable for specifying desired outcomes and benefits | Agrees Benefits Management Approach. Provides benefits tolerance. Confirms post-project benefit reviews. |
| Senior Supplier | Reviews BC to confirm supplier costs represent value for money | Provides realism on cost, feasibility, and timing. |
| PM | Prepares and maintains BC and Benefits Management Approach | Highlights BC impacts from issues/risks. Produces End Project Report evaluating against BC. |
| Project Assurance | Checks BC against project progress | Confirms BC validity to PB. Reviews exception reports for BC impact. |
| Ensure continued BJ | Creating and maintaining a BC to assess desirability, viability, achievability | Confidence that investment is worthwhile |
| Learn from experience | Using lessons to inform business justification | BC built on proven foundations |
| Define roles | Clarifying responsibilities for developing and maintaining BC | Clear expectations for BC and benefits management |
| Manage by stages | Checking BJ at each stage boundary | Confidence investment remains justified |
| Manage by exception | Measuring impact of issues/risks on BC; escalating when forecast to exceed tolerances | Clear understanding of potential BC impacts |
| Focus on products | Ensuring products lead to required outcomes and benefits | Achievable project benefits |
| Tailor to suit | Formality of BC development appropriate to project type/size/complexity | Governance fit for purpose |
Module 08 · Chapter 8 of the manual — Practice
Document user requirements of project products and establish the means by which they will be met — fit for purpose, first time
| Quality Review Technique | Structured product review: prepare, review meeting, follow-up actions. Roles: producer, reviewer, chair, administrator. |
| Product Description | Defines purpose, composition, derivation, quality criteria, quality method, quality responsibilities (producer/reviewer/approver). App. A10. |
| Testing | Functional, performance, user acceptance. Common in IT projects. |
| Walkthrough / Inspection | Peer review of documents or code. Less formal than quality review. |
| Statistical sampling / audit | Used in manufacturing or large-scale compliance projects. |
| Organizational context | Existing quality management systems (ISO 9001, etc.) may influence the quality management approach. Lessons from past projects inform quality planning. |
| Commercial context | Supplier quality standards must be checked for compatibility with project quality requirements. Acceptance criteria must be shared with suppliers. |
| Delivery method | Agile: quality embedded in iterations (Definition of Done). Quality review at sprint/timebox end. Less reliance on end-gate review. |
| Scale | Large projects: formal QMS, dedicated QA team. Small projects: PM may combine with Project Support. Quality activities proportional to risk. |
| Sustainability | Sustainability targets become quality criteria in product descriptions (e.g. carbon footprint per unit, recyclability percentage). |
| Quality Management Approach | Describes the quality techniques and standards to be applied and the roles and responsibilities for achieving the required quality specifications and acceptance criteria. Contains: scope, quality management procedures, responsibilities, tools/techniques, standards, references. Part of PID. | Created in IP · Approved by PB · Reviewed at each SB |
| Product Descriptions | One per product. Contains: identifier, version, purpose, composition, format, derivation, quality specifications, quality tolerance, quality methods, quality skills required, responsibilities (producer / reviewer / acceptance authority). Basis for work packages and acceptance. App. A10. | Created in plans process · Approved by Senior User · One per product |
| Quality Register | Part of the Project Log. Summarises all quality management activities that are planned or have occurred. Used by PM and Project Assurance as part of reviewing progress. Contains: quality identifier, product identifier, quality method, planned/actual dates, responsibilities, result (pass/fail), records. | Maintained by Project Support throughout the project |
| Product Register | Part of the Project Log. Lists all products required of a plan and their status. Contains: product identifier, dates (description approval + acceptance), status (in development / accepted), version number, reference to product description. | Maintained by Project Support · Updated as products progress |
| Business Layer | Provides details of the business quality management system and applicable standards. Sets project-level quality tolerance. Provides quality assurance expertise. | Quality standards / tolerance set at project level |
| Executive | Approves the project product description. Approves the quality management approach. Sets stage-level quality tolerance. Confirms acceptance of the project product. | Approval of key quality planning outputs + final acceptance |
| Senior User | Provides user's quality expectations and acceptance criteria. Approves project product description. Agrees quality management approach. Approves product descriptions for specialist products. Provides people/resources for user quality activities and product acceptance. Accepts the project product — accountable for acceptance. | Primary driver of quality requirements · accountable for product acceptance |
| Senior Supplier | Approves project product description (if appropriate). Agrees quality management approach. Agrees product descriptions for key specialist products. Agrees quality techniques and tools adopted in product development. Provides people/resources for supplier quality activities. | Technical quality standards and feasibility |
| PM | Consults stakeholders to capture user's quality expectations and acceptance criteria. Consults stakeholders to prepare the quality management approach and product descriptions. Ensures team managers implement agreed quality control measures. Develops product descriptions for key products. | Quality planning and control across the whole project |
| Project Assurance | Reviews that quality planning is correct and appropriate. Confirms QMA is being applied correctly. Checks product descriptions for completeness. Audits quality activities on behalf of the PB. | Independent assurance that quality is being managed correctly — on behalf of PB |
| Project Support | Maintains the quality register. Administers quality review meetings. Distributes products for review. | Quality register maintenance + admin support for quality activities |
| Team Manager | Assists PM with preparing and maintaining product descriptions and work package descriptions. Produces products consistent with their product descriptions. Implements quality management procedures agreed in work package descriptions. Updates quality register. Notifies PM of quality issues. | Execution of quality control at work package level |
| Ensure continued BJ | Designing and delivering products that meet quality specs required by the BC | Products achieve desired outcomes aligned with business strategy |
| Learn from experience | Incorporating lessons from quality control into planning for subsequent stages | Recurring improvement of quality management approach |
| Define roles | Establishing roles and responsibilities for quality within the project | Clear accountability for quality planning, control, and assurance |
| Manage by stages | Aligning quality controls and techniques with stages and stage boundary controls | Early identification of quality issues; avoiding cost of rework |
| Manage by exception | Establishing quality tolerances approved by PB in PID | Efficient means for PM to take decisions and report exceptions |
| Focus on products | Basing all quality planning and control activities on the project products | Effective communication; avoidance of conflicts over user quality expectations |
| Tailor to suit | Requiring only quality activities appropriate to delivery method and product characteristics | Right balance between quality, delivery activities, and resources |
Module 09 · Chapter 9 of the manual — Practice
Identify, assess and control uncertainties — it is better to manage the risk than have to resolve the issue
| 5-step risk management procedure (Fig 9.2) | Identify (risk cause, event, effect) → Assess (probability, impact, proximity) → Plan (select response) → Implement (assign owner/actionee) → Communicate (throughout). |
| Threat responses | Avoid · Reduce · Transfer (share) · Accept · Prepare contingency. ARTAP mnemonic. |
| Opportunity responses | Exploit · Enhance · Share · Reject. EESR mnemonic. |
| PESTLE analysis | Political, Economic, Social, Technological, Legal, Environmental — for identifying external risks. |
| Pre-mortem | Imagining the project has already failed; working backwards to identify causes. |
| Probability/impact matrix | Visual risk prioritisation tool. |
| Organizational context | Risk management approach aligns with corporate risk frameworks. Existing risk registers or lessons logs inform risk identification. |
| Commercial context | Supplier risks (financial viability, capability) must be assessed. Contractual risk transfer (insurance, warranties) documented. |
| Delivery method | Agile: risks may be captured in the product backlog or sprint planning. Risk review at timebox end. Higher tolerance for small risks in iterative delivery. |
| Scale | Large projects: dedicated risk manager, formal risk workshops. Small projects: PM manages risk register informally. Risk budget proportional to risk exposure. |
| Sustainability | Sustainability risks (regulatory, reputational, environmental) captured in risk register. Sustainability tolerance may trigger risk escalation. |
| Risk Management Approach | Describes how risk management will be applied: procedures, risk tolerance, roles, risk budget, reporting frequency. Part of PID. |
| Risk Register | Living record of all identified risks: cause, event, effect, probability, impact, status, owner, actionee, response. Part of Project Log. |
| Executive | Sets project risk tolerance | Accountable for risk management approach. Approves risk budget. |
| Senior User | Identifies risks from user perspective | Ensures user-side risks (adoption, benefit realisation) are managed. |
| Senior Supplier | Identifies risks from supplier/technical perspective | Provides technical risk assessment. Manages supplier risk. |
| PM | Creates and maintains risk management approach and risk register | Reviews and updates risks regularly. Takes corrective action within stage tolerance. Raises exceptions for risks forecast to exceed tolerance. |
| Team Manager | Identifies and reports risks at work package level | Raises issues to PM when WP risks forecast to exceed WP tolerance. |
| Project Assurance | Reviews risk management approach for appropriateness | Checks BC impact of risks. Assures PB that risk management is being applied. |
| Ensure continued BJ | Assessing whether identified risks have a material impact on the BC | Increased confidence that investment is worthwhile and risks acceptable |
| Learn from experience | Using lessons to inform risk identification and management | Responses based on effective foundations from previous experience |
| Define roles | Clarifying responsibilities for identifying, managing, and reporting risks | Clear expectations for risk management responsibilities |
| Manage by stages | Ensuring stage boundary decisions are informed by risks | De-risking project by using stages as formal stop-go decision points |
| Manage by exception | Empowering those best placed to own risks; escalating risks forecast to exceed tolerances | Threats and opportunities managed at the appropriate level |
| Focus on products | Understanding risks associated with defining, developing, and delivering products | Clear understanding of threats and opportunities for each product |
| Tailor to suit | Risk management approach appropriate to type, size, complexity of project | Efficient management of threats and opportunities aligned to organisational standards |
Module 10 · Chapters 16 & 17 of the manual — Processes
CH16 (CS) — the Project Manager's day-to-day cycle · CH17 (MP) — the Team Manager's delivery cycle
Module 11 · Chapter 18 of the manual — Process
The project manager's end-of-stage process — review, replan, update and request next stage authorisation
Module 12 · Chapter 10 of the manual — Practice
Collect and assess issues · control changes to the project baseline · encompassing change control
| 1. Capture | Determine issue type. Assess severity/priority. Register in issue register (or daily log if informal). |
| 2. Assess | Assess impact on BC and project risk profile. Check severity/priority. Determine who has authority to decide. |
| 3. Recommend | Identify options. Evaluate options. Recommend options (PM or Change Authority). |
| 4. Decide | Escalate if beyond delegated authority. Approve, reject, defer, or ask for more information. |
| 5. Implement | Take corrective action. Update records and project baseline if necessary. |
| Organizational context | Existing change management procedures may inform the issue management approach. Lessons from past projects on types of issues commonly encountered. |
| Commercial context | Changes affecting commercial suppliers require careful handling — change requests may trigger contract amendments, additional costs. |
| Delivery method | Agile: changes incorporated into product backlog, reprioritised each sprint. Change budget may be time rather than cost. Off-specs resolved in timebox reviews. |
| Scale | Large: formal Change Authority with defined budgets. Small: PM handles all issues informally via daily log. Change budget proportional to project complexity. |
| Sustainability | Issues that impact sustainability targets require escalation. Off-specs against sustainability criteria need PB decision. |
| Issue Management Approach | Describes how issues will be captured, assessed, managed and resolved. Includes change budget, change authority composition. Part of PID. |
| Issue Register | Records all formal issues: type, severity, impact, status, resolution. Part of Project Log. |
| Issue Report | Produced for significant issues requiring PB/Change Authority decision. Includes analysis, options, recommendation. |
| Executive / PB | Sets change budget and authority levels | Approves Issue Management Approach. Makes decisions on issues beyond PM authority. |
| Change Authority | Approves changes within delegated budget | Keeps issue register updated. Reports to PB on change budget usage. |
| PM | Manages day-to-day issues and corrective action | Maintains issue register. Raises Exception Report to PB when stage tolerance forecast to be exceeded. |
| Team Manager | Identifies and reports WP-level issues to PM | Raises issues (not Exception Reports) when WP tolerance at risk. |
| Project Assurance | Reviews change management approach for compliance | Checks that baselines are maintained and changes are properly controlled. |
| Project Support | Maintains issue register and project baseline documentation | Assists in distributing issue reports and tracking resolutions. |
| Ensure continued BJ | Assessing impact of issues and changes on BC viability | Issues and changes managed to protect investment justification |
| Learn from experience | Using issue logs and lessons from past projects to anticipate and manage issues | Better preparation for known issue types |
| Define roles | Clarifying responsibilities for issue identification, assessment, and resolution | No ambiguity over who decides what, at what level |
| Manage by stages | Reviewing open issues at stage boundaries as part of SB assessment | Issues properly tracked and formally closed at stage boundaries |
| Manage by exception | Escalating issues only when they exceed delegated tolerance | Right issues escalated to right level; PB not overwhelmed with trivia |
| Focus on products | Ensuring changes to scope (product baseline) are formally controlled | Scope creep prevented; product baseline maintained |
| Tailor to suit | Formality of issue and change control proportional to project size, risk, and commercial context | Efficient change management without unnecessary bureaucracy |
Module 13 · Chapter 11 of the manual — Practice
Measure actuals against estimates · forecast continued viability · control deviations through managed exception
| Exception management procedure | Issue (WP level) → Exception Report (stage level) → Business Layer referral (project level). Fig 11.3. |
| Earned value management | Compares planned value, earned value, and actual cost to forecast schedule and cost performance. |
| Burn-down / burn-up charts | Agile: shows remaining vs completed work per timebox. Fig 11.5. |
| Kanban board | Agile: visualises work in progress. Fig 11.6. |
| Peer review / retrospective | Team-level review of progress, quality, and process improvements. |
| Organizational context | Reporting formats and frequencies aligned with organisational standards. Digital tools (dashboards) may replace formal reports. |
| Commercial context | Contractual reporting obligations may define format and frequency of progress reports. Supplier progress monitored at WP level. |
| Delivery method | Agile: Highlight Report may use pull system (PB reviews burndown/Kanban rather than receiving pushed document). Sprint reviews replace some formal reporting. |
| Scale | Large: formal reporting hierarchy, multiple TMs, dedicated progress systems. Small: informal checkpoints via email or standup. |
| Sustainability | Sustainability tolerance reported alongside other tolerances. Progress on sustainability targets tracked in Project Log. |
| Checkpoint Report | TM → PM. Time-driven. WP progress at frequency defined in WP description. |
| Highlight Report | PM → PB. Time-driven. Stage status summary at intervals defined by PB. |
| Exception Report | PM → PB. Event-driven. Raised when stage tolerances forecast to be exceeded. Requests PB decision. |
| End Stage Report | PM → PB. Event-driven. Performance against stage plan. Triggers SB decision point. |
| End Project Report | PM → PB. Event-driven. Performance against original PID + all approved changes. |
| Daily Log / Lessons Log | Maintained throughout by PM. Daily: trivial informal items. Lessons: maintained dynamically, compiled into Lessons Report at closure. |
| Business Layer | Sets overall reporting expectations | Confirms reporting format/frequency with PB. Receives project status/exception reports. |
| PB / Executive | Reviews Highlight Reports | Makes decisions on exceptions. Issues Exception Plan Request or Premature Close Notice. |
| Senior User | Reviews Highlight Reports from user perspective | Ensures benefits progress is being captured and reported. |
| PM | Produces Highlight Reports from Checkpoint data | Manages issues within stage tolerance (corrective action). Raises Exception Report when tolerance forecast exceeded. |
| Team Manager | Produces Checkpoint Reports to PM | Raises issues (not Exception Reports) when WP tolerances at risk. |
| Project Assurance | Confirms progress reporting is accurate | Checks stage progress against agreed tolerances. Reviews exception reports for BC impact. |
| Project Support | Assists in maintaining progress records | Compiles checkpoint data. Maintains registers. Assists in distributing reports. |
| Ensure continued BJ | Checking BC viability periodically at stage boundaries and for exceptions | More appropriate decisions on ongoing project viability |
| Learn from experience | Identifying lessons from progress management output; applying forecasting techniques | Lessons applied; more accurate predictions for future stages |
| Define roles | Clarity on reporting requirements and responsibilities | Timely and effective decisions on verified information |
| Manage by stages | Dividing project into stages; authorising one stage at a time | Clear points to assess progress and viability before committing to next stage |
| Manage by exception | Controlling project through tolerance levels and escalation at each management level | Right decisions made at the right level; no micromanagement |
| Focus on products | Measuring and reporting progress in terms of products delivered | Tangible, measurable progress rather than activity metrics |
| Tailor to suit | Adapting reporting format and frequency to project context, delivery method, and scale | Efficient progress management without unnecessary reporting overhead |
Module 13 · Chapter 11 of the manual — Practice
Measure actual vs planned · provide forecasts · control deviations · Deming cycle (plan-do-check-act)
The project is managed by exception between four management levels. Each level receives a tolerance from above and delegates part of it downward. Reporting goes upward; authority cascades downward.
Module 14 · Chapter 19 of the manual — Process
A fixed point at which acceptance of the project product is confirmed — planned or premature, always orderly
Module 15 · Chapter 14 of the manual — Process
"Eyes on, hands off" — the Project Board's process. Runs from after Starting Up through to project closure.
DP is the only process that runs for the entire project lifecycle. The Project Board makes decisions at key points; everything else runs via the PM who keeps them informed through highlight reports.
Module 07 · Chapter 7 of the manual — Practice
Facilitate communication and control · define what, when, who, how, where and how much · product-based planning
All PRINCE2 plans have the same fundamental structure (Appendix A9). What differs is purpose, scope, and level of detail.
Products are nouns / end states, not activities. Instead of "decorate the room" → specify painted walls · painted doorways · wood-block flooring. Measurable and testable outputs — not vague instructions.
The top-level definition of the final output the customer expects to receive from the project. Before defining any work, define what the customer actually wants.
Break the project product into its constituent parts — a hierarchy of products. Stop decomposing when each item could be allocated as a work package to a team manager. No dependency order implied — just "what does it consist of?"
An individual product description for each product — the basis for the work package description given to the team manager. Defines exactly what must be delivered before any work starts.
Shows the sequence and logical dependencies between products. The PBS shows "what it consists of" — the PFD shows "in what order products flow toward the end result". Finish-Start relationships: you can't start product E until products A and B are both complete.
Once products (nouns) are defined, identify the activities (verbs) needed to deliver each product. Group into work packages.
For each activity: resources needed (people, equipment, services) and duration. Discuss with team managers — collaborative planning produces better estimates.
| Fig 7.3 — Planning technique | 7 steps: Define & Analyse Products → Organise Work Packages → Prepare Estimates → Prepare Schedule → Analyse Risks → Prepare Budget → Document the Plan. |
| Fig 7.4 — Define & Analyse Products | Project plan only: Write Project Product Description. All plan levels: Create PBS → Write Product Descriptions → Create Product Flow Diagram. |
| Work Breakdown Structure (WBS) | Hierarchy of all work to be done. Links PBS to work packages. Basis for estimating and scheduling. |
| Gantt chart | Activities against timeline. Easy to show slippage, today's date. Most common format. |
| Network diagram / Critical Path | Shows dependencies and bottlenecks. Critical path = longest path. Float identifies scheduling flexibility. |
| MoSCoW prioritisation | Must/Should/Could/Won't. Used for scope tolerance, especially in agile. |
| Organizational context | Existing planning tools, templates, or standards may define plan format. PMO may provide planning support. |
| Commercial context | Contract milestones may define stage boundaries. Supplier plans must align with project plan. WP descriptions serve as commercial sub-contracts. |
| Delivery method | Agile: product backlog may serve as team plan equivalent. Sprint plans within timebox. Rolling wave more naturally suited to iterative delivery. MoSCoW for scope tolerance. |
| Scale | Large: detailed project plan with multiple stage plans; PM produces stage plans with specialist involvement. Small: one-stage plan may suffice for simple projects. |
| Sustainability | Sustainability targets appear as plan tolerances. Sustainability milestones planned into the stage plan. Supplier sustainability requirements in WP descriptions. |
| Project Plan | High-level plan: major products, stage boundaries, WPs at high level. Created in IP. Lives in PID. Approved by PB. Reviewed at each SB. |
| Stage Plans | Detailed per-stage plan. Initiation stage plan in SU. Subsequent stage plans in SB. Approved by PB at each stage boundary. |
| Team Plans (optional) | Per work package. Created by Team Manager in MP. Approved by PM. Used when team is complex or third-party. |
| Exception Plan | Replaces current stage/project plan. Produced in SB on PB's Exception Plan Request. Approved by PB. Same structure as any plan (App A9). |
| Work Package Description | Not a plan but part of the plans practice. Passes work formally to TM. Product descriptions form its core. App A15. |
| PB / Executive | Approves project plan and each stage plan | Sets project tolerances. Makes stage authorisation decisions at SBs. |
| Senior User | Contributes user requirements to planning | Confirms product descriptions meet user needs. Confirms acceptance criteria in Project Product Description. |
| Senior Supplier | Contributes specialist expertise to planning | Confirms technical feasibility and estimates. Agrees WP descriptions with PM. |
| PM | Creates project plan (in IP), initiation stage plan (in SU), subsequent stage plans (in SB) | Collaborates with TMs on WP descriptions. Maintains and updates plans throughout. |
| Team Manager | Creates team plans (optional, in MP) | Agrees WP descriptions with PM. Provides estimates for WP activities. |
| Project Assurance | Reviews plans for viability and alignment with BC | Advises PM and PB on plan quality. Reviews stage plans for completeness. |
| Project Support | Provides planning support and tools | Maintains project plan baseline. Assists PM with scheduling and reporting. |
| Ensure continued BJ | Aligning plan's performance targets to BC objectives; providing estimates to confirm viability | Plans remain aligned with business strategy within defined tolerances |
| Learn from experience | Using lessons to inform planning; sharing planning lessons for future projects | Improved capability to plan and deliver; more accurate estimates |
| Define roles | Establishing roles and responsibilities specific to a plan; organising through WPs and teams | Clear accountability for plan performance; efficient decision-making |
| Manage by stages | Breaking lifecycle into stages aligned to planning horizons and key decision points | Stages planned appropriately to business needs and realistic estimates |
| Manage by exception | Defining levels of plan and establishing targets and tolerances for each | Efficient decision-making and escalation at the appropriate plan level |
| Focus on products | Basing all plans and planning activities on identifying required products first | Effective communication; avoidance of unnecessary work and scope creep |
| Tailor to suit | Requiring only planning activities and plans appropriate to the project context | Right balance between project management, delivery activities, and resources |
Module 04 · Chapter 6 of the manual — Practice
Define the project structure in terms of accountability and responsibility — who is doing what
Three interests must be represented on the Project Board. Remember: BUS — Business · User · Supplier.
These are roles, not jobs or individuals. One person can hold multiple roles. A role can be shared across individuals.
| 5-step technique | Understand organisational ecosystem → Design project ecosystem → Develop project ecosystem → Manage ongoing changes → Transition into organisational ecosystem. |
| Step: Understand | Map current-state stakeholders, roles, relationships, culture, and external context. |
| Step: Design | Define project management team structure. Assign roles. Define role descriptions. Identify gaps. |
| Step: Develop | Onboard team members. Build relationships. Establish communication patterns and working practices. |
| Step: Manage changes | Review team structure at stage boundaries. Adapt roles as skills and context change. |
| Step: Transition | Ensure operations can absorb the change. Handover people and knowledge to BAU. |
| Organizational context | Existing org structures may define which people are available for project roles. PMO may provide PM and PA. Governance standards may prescribe PB composition. |
| Commercial context | Third-party suppliers require formal Senior Supplier role. Commercial Management Approach must define procurement and contract management responsibilities. |
| Delivery method | Agile: self-organising teams may sit within the team manager layer. Scrum Master could be aligned to TM. Product Owner to Senior User. Structure must still reflect BUS interests. |
| Scale | Large: multiple Senior Users/Suppliers; delegated PA; formal Change Authority. Small: Executive + PM may suffice. PB of one person possible in tiny internal projects. |
| Sustainability | Executive accountable for ESG targets. Role descriptions must define sustainability responsibilities. Sustainability champions may be added to the project ecosystem. |
| Commercial Management Approach | How commercial relationships with third-party suppliers will be managed: procurement, contracts, performance, disputes. Part of PID. |
| Project Management Team Structure | Chart showing who holds each role, their relationships, reporting lines, and governance arrangements. Part of PID. |
| Role Descriptions | Defines each role's authority, responsibilities, who they are accountable to, and whether roles are combined. Part of PID. |
| Business Layer | Appoints Executive (and possibly PM) | Sets communications standards. Provides information to project per communication management approach. |
| Executive | Appoints PM (if not done by BL) | Confirms organisational design. Approves team structure, commercial/comms/change approaches. Reviews delivery model for ESG compatibility. |
| Senior User | Ensures appropriate user community involvement | Agrees commercial, comms, and change approaches. Provides user resources. Ensures sustainability targets are embedded in role descriptions. |
| Senior Supplier | Provides specialist resources | Agrees procurement approach. Contributes to organisational design for delivery. |
| PM | Designs and maintains team structure | Creates and updates role descriptions and management approaches. Reviews team performance at stage boundaries. |
| Project Assurance | Reviews team structure for completeness and independence | Confirms PA independence from PM is maintained. Reviews role descriptions. |
| Project Support | Maintains team structure documentation | Assists with onboarding and communication arrangements. |
| Ensure continued BJ | Assigning someone from the business as Executive with sufficient authority and availability | Project adapts to changing business needs; appropriate decisions aligned with BC |
| Learn from experience | Using lessons to inform project management team structure and healthy project ecosystem | Right people in right roles at right time |
| Define roles | Developing an explicit project management team structure with clear responsibilities | No duplication or gaps; positive relationships across the project ecosystem |
| Manage by stages | Assessing and adapting team structure, role descriptions, and management approaches at stage boundaries | Project evolves with changing needs; appropriate skills at each stage |
| Manage by exception | Empowering those best placed to make decisions at the appropriate point | Effective and timely decision-making; increased accountability and ownership |
| Focus on products | Ensuring product users are represented on the team and change management is understood | Products accepted by users and brought into operational use; benefits delivered |
| Tailor to suit | Creating a project management team appropriate to the project's needs and the organisations' capabilities | Structure that is fit for purpose without unnecessary overhead |
Module 05 · Chapters 13 & 15 of the manual — Processes
From idea to PID — pre-project research + setting up the project properly
All projects start with an idea (a project mandate). The key question before committing significant resources is: "Is this viable and worthwhile?" PRINCE2 answers this in two deliberate steps.
Module 02a · Chapter 2 of the manual — Principles
Universal · mandatory · non-negotiable. The guiding obligations that determine whether a project is genuinely being managed using PRINCE2.
PRINCE2 Foundation v7 · Audio
Ascolta i riepiloghi audio degli argomenti chiave — perfetti per ripassare in mobilità
podcast/index.json — nessuna modifica alla pagina necessaria per aggiungere nuovi file.
Settimana 2 · Flashcard interattive
Business Case · Organisation · Quality — clicca la card per girare
PRINCE2 Foundation v7 · Glossario ufficiale
Termini e definizioni dal manuale ufficiale — cerca o sfoglia per categoria
PeopleCert · Foundation Exam style
Select a topic, choose how many questions, then hit Start