6.1 The Seven Practices & Tailoring

From Themes to Practices

In PRINCE2 v7 the seven themes from earlier editions were reframed as seven practices, and the Change theme was renamed issues to reflect that change is only one kind of project issue alongside concerns, problems, and new opportunities. A practice is a recurring aspect of project management that the team must address consistently throughout the project lifecycle — not a one-off activity performed at a single gate. Practices are the lens through which the processes are executed; they underpin the processes rather than running in parallel.

Why 'practices' and not 'themes'?

The rename signals a behavioural shift: a practice is something you do habitually and tailor, whereas a theme suggested a static perspective. v7 also integrated the management-product outlines directly into each practice, so the Quality Management Approach, Risk Management Approach, Issue Management Approach, and similar documents are introduced where they are used, not in a separate appendix.

The Seven Practices at a Glance

Each practice has one primary technique that anchors it (for example, product-based planning for the plans practice) plus supporting techniques that flex with the project. A small internal project may use a lightweight risk register while a regulated programme may deploy quantitative risk modelling — the practice is the same, the technique depth changes.

Tailoring Practices via Management Approaches

Practices are tailored to the project and that tailoring is documented in management approaches. A management approach is a living product, created in Initiating a Project and revisited at each stage boundary, that records how a practice will be applied: the tools, the registers, the roles, the review cadence, and the escalation thresholds. Typical management approaches include:

• Quality Management Approach — acceptance criteria, inspection methods, quality records.
• Risk Management Approach — risk categories, risk appetite, escalation thresholds.
• Issue Management Approach — issue categories, change authority, impact analysis steps.
• Communication Management Approach — stakeholders, channels, reporting frequency.

What v7 dropped

Earlier editions listed 'minimum requirements' for each theme — mandatory elements that had to exist regardless of tailoring. v7 removed that wording because it encouraged box-ticking rather than genuine fit-for-purpose tailoring. The expectation now is that every practice is evidenced in a way proportionate to the project's risk, scale, and complexity, and that the management approach makes the tailoring explicit and auditable.

Practices also feed each other: a new issue can trigger a risk re-rating, which can invalidate the business case, which can force a progress re-baseline. Holding the practices together is what gives the method its self-correcting character.

How Practices Interlock With the Processes

Practices are not stages — they run through the seven PRINCE2 processes (Starting Up a Project, Initiating a Project, Directing a Project, Controlling a Stage, Managing a Stage Boundary, Controlling a Stage boundary, Closing a Project). Each process applies all seven practices, but with different emphasis. In Starting Up a Project the dominant practices are business case (outline justification) and organising (appointing the Executive and Project Manager). In Initiating a Project all seven practices are exercised because the full set of management approaches is created. In Controlling a Stage the dominant practices are progress (tolerance monitoring), issues (day-to-day change control), and quality (work-package acceptance). In Managing a Stage Boundary the business case and plans practices dominate because the case is re-verified and the next Stage Plan is built. Knowing which practice dominates in which process is a high-yield exam pattern: Practitioner questions routinely describe a process activity and ask which practice is being applied.

Worked example — a change request flowing through the practices

A supplier proposes a cheaper component substitution mid-stage. The issues practice captures it as a change request and runs the issue and change control procedure. The impact analysis triggers the risk practice (the new component has a different failure profile), which in turn triggers the business case practice (the cost saving is real, but does the project still remain a worthwhile investment if the reliability risk increases?). The plans practice updates the Stage Plan, the quality practice revises the acceptance criteria for the substituted component, and the progress practice checks whether the change pushes the stage outside tolerance. One event, all seven practices touched — this is why the method treats them as inseparable rather than modular add-ons.

Common Exam Traps for the Practices Overview

• Confusing practices with processes. Practices are what you manage (recurring aspects); processes are when you manage them (chronological activities). A question that asks 'which practice' is never answered with a process name.
• Assuming 'issues' equals change only. v7 renamed the theme precisely because issues also cover concerns, problems, and new opportunities. An option that says 'the issues practice handles change requests only' is wrong.
• Expecting minimum requirements. Any answer that invokes a fixed minimum-requirements checklist is trading on v6 wording and is incorrect in v7. Tailoring is documented in the management approach, not measured against a static list.
• Assigning the Executive to every practice. The Executive is the driver of the business case practice specifically; other practices have different owners (the Project Manager for plans and progress, Senior User for quality acceptance in many setups, Senior Supplier for resource commitments).
• Treating management approaches as one-off documents. They are created in Initiating a Project and revisited at every stage boundary — an option that says they are written once and frozen is a trap.
• Counting only six practices. v7 has seven, and v6 also had seven themes — the rename from Change to Issues did not change the count. Miscounts usually come from collapsing Organizing and Plans into one, or from forgetting Progress.