Applying the principles in scenarios

The seven principles are the part of PRINCE2 that never changes. Every practice, process and tailoring decision should be traceable to them, which makes them a powerful tool in Practitioner questions. When two options both look reasonable, the one that keeps a principle intact is usually right, and an option that quietly breaks one is usually a distractor. This lesson goes through the principles one at a time, with what each requires, how it shows up in scenarios and how a breach usually looks, then practices them on the Harbor City and Ridgeline projects.

The seven principles at a glance

Continued business justification

This principle asks whether the project is still desirable, viable and achievable, not just whether it was when it started. In scenarios it appears when circumstances change: benefits shrink, costs rise, the organization's strategy shifts or a better option appears. The right response is to update the business case and let the board decide whether to continue. Common distractors argue that the project should continue because most of the money has been spent (sunk cost), or that a mandatory project needs no justification.

Example: midway through the digital card project, the provincial or state library network announces a free shared digital card for all member libraries, launching in eight months. The PM should update the business case with this option and the board should decide whether to continue, change scope (for example, keep only family linking and online sign-up) or close the project. Simply continuing because 60 thousand has been spent breaks the principle.

Learn from experience

Lessons are sought at the start, recorded and applied throughout, and passed on at closure. In scenarios, look for whether lessons from previous projects have been used in planning, whether the lessons log is updated when something goes wrong, and whether lessons are shared with the organization. Ridgeline's lead service line project used the smart metering project's lesson about realistic installation rates; its plan set crew productivity from metered data, not supplier claims. A scenario in which a project repeats a mistake that a previous project recorded points straight at this principle.

Define roles, responsibilities and relationships

The project management team must represent the business, user and supplier interests, with clear accountability and a single executive. In scenarios, this principle catches boards with no user representative, supplier representatives making customer-only decisions, project managers who take decisions reserved for the board, and assurance held by the person being assured. It also covers relationships beyond the team: stakeholders, the business layer, suppliers' own management.

Example: on the treatment plant upgrade, the board wants the plant superintendent to be both senior user and project assurance for users. That is acceptable in principle, since the senior user is responsible for user assurance and may do it personally, but Ridgeline has appointed the operations engineer to do it so that the superintendent's time goes to decisions. Either arrangement keeps the principle. Making the project manager responsible for user assurance would not.

Manage by stages

The project is planned, monitored and controlled stage by stage, with the board deciding at each boundary whether to continue. In scenarios, look for stage boundaries at sensible decision points, detailed plans for the next stage only, and no work in a stage before authorization. A classic distractor suggests starting the next stage's work early to save time, without board authorization. Another proposes fewer, longer stages for convenience on a risky project, which reduces the board's control exactly where it is needed.

Manage by exception

Authority is delegated through tolerances: the business layer sets project tolerances, the board sets stage tolerances, the project manager sets work package tolerances. Each level escalates only when a breach is forecast. In scenarios, this principle explains why a project manager should not ask the board about small decisions within tolerance and authority, and why the board should not micromanage. It also explains why an exception report is needed when a forecast breach appears, even if the project manager is confident of recovering later.

Focus on products

Projects deliver products, so PRINCE2 defines what is to be delivered, and its quality criteria, before deciding how. In scenarios, look for product descriptions with measurable quality criteria, a project product description agreed with users, and acceptance based on those criteria. The principle catches plans that list only activities, quality criteria that cannot be measured ('easy to use') and disputes that arise because acceptance criteria were never agreed. In agile scenarios, well-written user stories with acceptance criteria satisfy the principle.

Tailor to suit the context

This principle is the subject of the first half of this course. In scenarios, it shows up in two directions. Sometimes a scenario describes a project applying the full method to a small or simple piece of work, and the right answer is to tailor down. Sometimes it describes tailoring that removed something essential, and the right answer is that the tailoring breaks another principle. The test from lesson 1, whether the purpose is still met, settles most of these questions.

evidence = [   # (statement from a scenario, principle it relates to, supports=True / breaches=False)
    ("business case updated after the shared-card announcement", "justification", True),
    ("plan uses crew rates from the previous project's lessons", "learning", True),
    ("vendor's account director approves the vendor's own variation", "roles", False),
    ("team starts stage 3 design before board authorization", "stages", False),
    ("PM handles a 2k overspend within tolerance and reports it", "exception", True),
    ("acceptance criterion for sign-up: 'should be fast'", "products", False),
    ("PID records sprint-based highlight reports", "tailoring", True),
]
from collections import defaultdict
tally = defaultdict(lambda: [0, 0])
for text, p, ok in evidence:
    tally[p][0 if ok else 1] += 1
for p, (good, bad) in tally.items():
    flag = "  <- check" if bad else ""
    print(f"{p:<13} supports {good}  breaches {bad}{flag}")

justification supports 1  breaches 0
learning      supports 1  breaches 0
roles         supports 0  breaches 1  <- check
stages        supports 0  breaches 1  <- check
exception     supports 1  breaches 0
products      supports 0  breaches 1  <- check
tailoring     supports 1  breaches 0

Three statements breach principles: a supplier approving its own variation (roles), work starting before authorization (stages) and an unmeasurable quality criterion (products). In an exam, any option proposing one of these would be a strong candidate for elimination, and any option that fixes one would be a strong candidate for the right answer.

Public-sector scenarios in the United States often add council or board approval steps and local procurement codes. These do not change the principles; they change who the business layer is and how authority is delegated, which affects how manage by exception and defined roles are applied.

Principles in tension

Sometimes two principles seem to pull in different directions, and Practitioner questions like to exploit that. Tailoring to suit the context might suggest fewer stages on a short project, while manage by stages requires at least two. Manage by exception suggests the project manager should handle problems without bothering the board, while continued business justification may require the board's view when benefits shift, even if no tolerance is breached. The resolution is that each principle sets a floor that the others cannot lower. Tailoring can shorten stages but not remove the boundary between initiation and delivery. Manage by exception keeps the board out of routine decisions, but a material change to the business case is not routine and goes to the board through the business case and the boundary process.

In an exam, an option that resolves a tension by abandoning a principle is wrong, however attractive the time saving. The right option usually keeps both principles by changing the form or frequency of something: a shorter boundary review, a lighter business case update or a combined role that still preserves separation where it matters.

A practical way to rehearse this is to take each option in a question and ask which principle it would weaken. If an option weakens none and solves the problem, it is very likely the answer. If every option seems to weaken something, look again at the scenario's stated tailoring and authorities: one option is usually allowed by the specific arrangements the scenario describes.