Principles in Context
10%of exam
People Management
9%of exam
Practices in Context
51%of exam
Processes in Context
30%of exam
Quick Facts
- Exam owner
- PeopleCert
- Qualification
- Project Management Practitioner Version 7
- Standard time
- 150 minutes
- Questions
- 56 questions and sub-questions
- Available marks
- 70 marks
- Pass mark
- 42 of 70 marks (60%)
- Question types
- Scenario-based standard and matching
- Open-book reference
- Official Version 7 book
- Entry requirement
- One accepted certification
Principles Recall
Justify, learn, assign, stage, delegate, define, tailor.
Stages vs Exception
Manage by stages
- Set management decision points
- Review before further commitment
Manage by exception
- Set limits on delegated authority
- Escalate forecast tolerance breaches
Stage gates and forecast breaches differ
Tailoring Decisions
- Small low-risk project→Simplify management products(Keep required controls)
- Existing corporate reports fit→Reuse reporting format(Keep necessary decision information)
- Limited delivery staff→Consider combining team management roles(Project manager can lead team)
- Using iterative delivery→Align governance with delivery cadence(Keep stage decisions explicit)
- Business justification no longer holds→Seek direction on closure(Review options and viability)
Seven Principles
- Ensure continued business justification
- Recheck the case for investment
- Learn from experience
- Seek, record and apply lessons
- Define roles, responsibilities and relationships
- Agree accountability and stakeholder relationships
- Manage by stages
- Plan and control by stage
- Manage by exception
- Delegate authority within agreed tolerances
- Focus on products
- Agree outputs and quality first
- Tailor to suit the project
- Adapt controls to project context
Adoption vs Change Control
Change management approach
- Addresses organizational transition
- Supports people adopting the outcome
Issue management approach
- Defines issue handling
- Controls changes to approved baselines
Guide adoption and govern baseline changes
People Decisions
- Users resist a new workflow→Plan adoption and support(Change management approach)
- Stakeholders get conflicting updates→Agree channels and feedback loops(Communication management approach)
- Hybrid team lacks trust→Create shared working agreements(Adapt collaboration to locations)
- Team lacks a critical skill→Close the skills gap(Train or bring in expertise)
People and Teams
- Project ecosystem
- People and relationships shaping delivery
- Organizational ecosystem
- Wider network around the project
- Stakeholders
- Include people affected by outcomes
- Leadership
- Influence people toward shared goals
- Management
- Coordinate work and resources
- Team capability
- Identify skills and address gaps
- Cultural intelligence
- Work across different cultures
- Team cohesion
- Build trust across locations
People Management Approaches
- Change management approach
- Plan transition to target state
- Communication management approach
- Define channels, cadence and feedback
- Change impact
- Identify affected groups and needs
- Adoption
- Embed new ways of working
- Two-way communication
- Share information and seek feedback
Seven Performance Targets
Time and cost, scope and quality, benefits, risk, sustainability.
Acceptance vs Quality Specifications
Acceptance criteria
- Apply to overall project product
- Guide user acceptance
Quality specifications
- Apply to individual products
- Guide product quality checks
Identify what is being judged
Tolerance Decisions
- Forecast stays within delegated tolerance→Take authorized corrective action(Keep routine reporting)
- Work package tolerance forecast exceeded→Team manager raises an issue(Inform project manager)
- Stage tolerance forecast exceeded→Project manager escalates to board(Issue report then exception report)
- Project tolerance forecast exceeded→Board escalates to business layer(Seek decision)
- Board requests stage exception plan→Prepare through stage boundary(Even during final stage)
- Exception plan gains authorization→Use the replacement baseline(For the affected plan)
Business Case
- Investment test
- Desirable, viable and achievable
- Business case
- Costs, benefits and associated risks
- Outline business case
- Early justification in project brief
- Full business case
- Basis for project authorization
- Benefits management approach
- Actions and reviews for benefits
- Sustainability management approach
- Project and product lifecycle controls
- Output
- Deliverable produced by work
- Outcome
- Change enabled by outputs
- Benefit
- Measurable improvement from an outcome
- Dis-benefit
- Measurable decline from an outcome
Risk Technique Recall
Identify, assess, plan, implement. Communicate throughout.
Risk vs Issue
Risk
- Uncertain event affecting objectives
- Record threats and opportunities
Issue
- Event requiring management action
- Assess impact and baseline implications
Check whether the event has occurred
Record and Report Picker
- Possible future supplier failure→Risk register(Assign a risk owner)
- Supplier already missed commitment→Issue register(Assess the impact)
- Approved product specification missed→Off-specification(Assess before any concession)
- Stakeholder proposes baseline change→Request for change(Assess impact and authority)
- Need inspection schedule and results→Quality register(Track checks and outcomes)
- Need product approval status→Product register(Check the deliverable record)
- Routine work package update→Checkpoint report(Team manager to project manager)
- Routine board progress update→Highlight report(Project manager to project board)
Organization
- Business layer
- Sets project-level tolerances and commissions
- Project board
- Directs and authorizes the project
- Project executive
- Owns the business caseBusiness
- Senior user
- Represents users and specifies benefitsUser
- Senior supplier
- Represents suppliers and technical integritySupplier
- Project manager
- Manages day-to-day within delegated authority
- Team manager
- Delivers agreed work packages
- Project assurance
- Independent oversight for project board
- Project support
- Provides administrative and tool support
- Commercial management approach
- Sets how suppliers are managed
Risk Owner vs Action Owner
Risk owner
- Oversees one risk
- Monitors the overall response
Risk action owner
- Owns assigned response actions
- Executes the agreed actions
Assign oversight and actions explicitly
Plans
- Product-based planning
- Define deliverables before scheduling activities
- Product breakdown structure
- Hierarchy of products
- Product flow diagram
- Sequence and dependencies of products
- Project product description
- Overall expectations and acceptance criteria
- Project plan
- High-level whole-project view
- Stage plan
- Detailed control of one stage
- Team plan
- Optional team delivery plan
- Work package description
- Agreed products, constraints and reporting
- Exception plan
- Replaces affected plan once authorized
Exception Report vs Exception Plan
Exception report
- Explains forecast tolerance breach
- Presents impacts and options
Exception plan
- Prepared when requested
- Replaces plan only after authorization
Escalate first, then replan if requested
Quality
- Product description
- Individual product specifications and checks
- Acceptance criteria
- Conditions for accepting project product
- Quality specification
- Measurable standard for a product
- Quality management approach
- Standards, methods and responsibilities
- Quality planning
- Define specifications and checks
- Quality control
- Check products against agreed specifications
- Quality assurance
- Independent checks on quality arrangements
- Product register
- Tracks deliverables and approval status
- Quality register
- Tracks quality activities and results
Risk
- Risk register
- Tracks threats and opportunitiesProject log
- Risk management approach
- Defines procedures, thresholds and responsibilitiesPID
- Risk owner
- Oversees the response to risk
- Risk action owner
- Performs assigned response actions
- Probability
- Chance the risk occurs
- Impact
- Effect if the risk occurs
- Proximity
- How soon risk might occur
- Velocity
- How quickly effects emerge
- Risk appetite
- Risk business will accept
- Risk tolerance
- Measurable limit on risk
- Contingent plan
- Response prepared for risk materialization
Issues
- Issue management approach
- Defines issue and change controlsPID
- Issue register
- Tracks formal issues and decisionsProject log
- Issue report
- Assesses impact and recommends action
- Change authority
- Decides changes within delegated limits
- Request for change
- Proposal to modify a baseline
- Off-specification
- Product will miss agreed specifications
- Problem
- Immediate negative impact
- Concern
- Timing and impact need assessment
- External event
- Outside event that may affect project
- Business opportunity
- Unplanned favorable development
Progress
- Checkpoint report
- Team manager to project manager
- Highlight report
- Project manager to project board
- End stage report
- Stage performance for board review
- End project report
- Project performance against baselines
- Exception report
- Escalates forecast breach with options
- Lessons log
- Record lessons as they emerge
- Lessons report
- Share lessons for reuse
- Daily log
- Informal notes and actionsProject log
- Digital and data management approach
- Data handling through project lifecyclePID
- Time-driven control
- At agreed reporting intervals
- Event-driven control
- Triggered by a specific event
- Stage tolerances
- Board delegates to project manager
- Work package tolerances
- Project manager delegates to team
Work Package Recall
Project manager authorizes, team accepts, executes, evaluates, notifies.
Stage Boundary vs Closure
Managing a stage boundary
- Review stage and justification
- Prepare next stage or exception plan
Closing a project
- Confirm acceptance and handover
- Evaluate project and request closure
Board authorizes the next move
Process Picker
- Mandate received, viability untested→Starting up a project(Assemble project brief)
- Initiation authorized, baselines needed→Initiating a project(Assemble initiation documentation)
- Stage approval or strategic direction→Directing a project(Board decision)
- Project manager assigns work→Controlling a stage(Authorize work package)
- Team accepts and delivers work→Managing product delivery(Notify completion)
- Next stage plan needs preparing→Managing a stage boundary(Request board authorization)
- Final product ready for handover→Closing a project(Confirm user acceptance)
- Board directs premature closure→Closing a project(Arrange orderly handover)
Seven Processes
- Starting up a project
- Screen viability before initiating
- Directing a project
- Board authorizes and gives direction
- Initiating a project
- Establish baselines before project authorization
- Controlling a stage
- Assign, monitor and correct work
- Managing product delivery
- Team accepts, executes, delivers work
- Managing a stage boundary
- Evaluate stage and plan ahead
- Closing a project
- Confirm acceptance and request closure
Delivery Control vs Delivery
Controlling a stage
- Project manager authorizes work
- Receives completed work packages
Managing product delivery
- Team manager accepts work
- Notifies project manager of completion
Project manager assigns, team manager delivers
Process Outputs
- Project mandate
- Business trigger for starting up
- Project brief
- Basis for authorizing initiation
- Initiation stage plan
- Plans work needed for initiation
- Project initiation documentation (PID)
- Basis for authorizing the project
- Next stage plan
- Supports next stage authorization
- Updated business case
- Rechecks justification at stage boundary
- Follow-on action recommendations
- Hand over unresolved risks and issues
- Post-project benefit reviews
- Schedule in benefits management approach
- Tailoring decisions
- Record in project initiation documentation
Common Traps
Question Count and Scoring
56 questions and sub-questions ≠ 70 available marks
Forecast Triggers Escalation
Forecast tolerance breach ≠ Already exceeded tolerance
Controls Can Be Tailored
Adapt reporting to context ≠ Drop a principle
Approval Changes the Baseline
Exception plan proposed ≠ Exception plan authorized
Keep Governance Accountable
Executive owns business case ≠ Project manager manages daily work
Registers Serve Different Purposes
Product register tracks deliverables ≠ Quality register tracks checks
Project Closure Is Authorized
Manager requests closure ≠ Board authorizes closure
Benefits Follow Use
Product handed over ≠ Benefit realized
Last Minute
- 1.Use the official Version 7 book
- 2.Apply the method to scenario facts
- 3.Identify the active process first
- 4.Find who holds decision authority
- 5.Escalate forecast breaches promptly
- 6.Check sustainability alongside other targets
- 7.Board authorizes initiation and project separately
- 8.Distinguish checkpoint from highlight reports
- 9.Planned closure: confirm project product acceptance
- 10.Schedule post-project benefit reviews
- 11.Keep all seven principles when tailoring
Explore More PRINCE2 Certifications
Continue into nearby exams from the same family. Each card keeps practice questions, study guides, flashcards, videos, and articles in one place.
More From This Family
Videos and articles for deeper review.
