PRINCE2 Foundation 7: Governing Projects with Clear Decisions

PRINCE2 Project Management Foundation (Version 7) introduces a method for directing and managing projects with explicit justification, responsibilities, controls and learning. PeopleCert's current Foundation examination uses 60 multiple-choice questions in 60 minutes, is closed book and requires 60% to pass. Candidates preparing today should follow the Version 7 Foundation syllabus rather than relying on sixth-edition exam materials. This is particularly important when older material refers to themes without explaining how Version 7 organizes its practices and places stronger emphasis on people and sustainability. A successful candidate understands not only the names of PRINCE2 elements but also why a controlled project can be adapted to very different organizations.

Begin with the business case, not the project schedule

A project does not become worthwhile merely because the sponsor has approved a budget or a delivery team can estimate the work. The business case explains the need, expected benefits, likely costs, major risks and continued justification for investment. Consider a local authority replacing an aging application: the visible work may be software procurement, configuration and migration, but the case for investment may be faster resident service, improved accessibility and reduced maintenance risk. Those intended outcomes determine whether alternative solutions are worth considering. They also determine when an emerging problem is serious enough to reconsider the project rather than silently absorb more expense.

PRINCE2's principle of continued business justification means checking the case at sensible decision points, not producing a document that is filed away after authorization. If a mandatory policy changes, a supplier's product is discontinued or a cheaper viable option becomes available, management needs revised evidence. A project manager can monitor assumptions and prepare analysis, but decisions beyond agreed tolerances belong to the appropriate directing level. A schedule can appear green while the project's benefits have evaporated. Foundation preparation should distinguish output, outcome, benefit and dis-benefit: delivering an online portal is an output; residents being able to complete applications without visiting an office is an outcome; lower handling time is a potential measurable benefit.

A convincing justification includes uncomfortable evidence. Cost savings might depend on workforce changes, integration complexity or sustained adoption. Benefits may arrive only after operations take ownership and change their processes. When estimating return, distinguish costs the project controls from operating impacts it merely influences. The related concept of project governance and decision rights helps explain why authorization, accountability and benefit ownership cannot be left to a delivery team alone. PRINCE2 uses this governance logic while providing distinctive roles and stage controls.

Understand principles as constraints on behavior

The seven PRINCE2 principles support a consistent management approach: continued business justification, learning from experience, defined roles and responsibilities, managing by stages, managing by exception, focusing on products, and tailoring to suit the project. They are not interchangeable slogans. Managing by stages creates deliberate investment decisions at stage boundaries, whereas managing by exception gives the project manager room to operate within delegated tolerances. Focusing on products forces clarity about the outputs to be accepted before teams commit to detailed activities. Tailoring prevents the method from becoming paperwork disproportionate to the project's risk and complexity.

Imagine a small project that must install a standardized service at three offices. It could combine several management products and use brief decision records while still identifying the business case, accepting deliverables and escalating exceptions. A national infrastructure project will need deeper controls, perhaps independent assurance, more formal supplier interfaces and explicit reporting cycles. Both can use PRINCE2 if the underlying governance remains. Removing all stage decisions under the banner of agility is not tailoring; it removes a control that lets decision makers reconsider the commitment.

Learning from experience starts before execution by reviewing relevant records and consulting people who carried out comparable initiatives. Lessons may concern contracts, stakeholder behavior, migration timing or the actual effectiveness of risk responses. A lesson only matters if someone uses it to change a current decision. Treating lessons as a final report with no assigned follow-up breaks the intent of the principle. At Foundation level, examine scenarios and ask which principle would prevent the observed failure, rather than searching mechanically for a keyword in the question.

Set up the project organization and escalation paths

PRINCE2 distinguishes directing a project from managing day-to-day delivery. The project board represents business, user and supplier interests; the executive is accountable for continued business justification; the senior user represents the people who will use the results and realize benefits; and the senior supplier represents those delivering required capabilities. The project manager plans, monitors and controls the project within the agreed authority, while team management concentrates on delivering assigned work. Project assurance checks independently that the relevant interests are protected. Project support may provide administration and control services, but its existence does not transfer overall accountability.

Role combinations are possible on smaller undertakings if conflicts are addressed and essential perspectives remain represented. One individual might cover more than one board interest in a straightforward internal change, but it becomes problematic if the same person must approve and independently assure a disputed supplier performance claim. Delegation must have boundaries. The project manager should know who can approve cost changes, who accepts products, who can reallocate resources and when the project board must intervene. Escalation is a governance response to a forecast breach, not an admission that managers have failed.

People are not just role boxes. Version 7 explicitly recognizes that behavior, collaboration, leadership and communication shape delivery. A technically sound plan may collapse if affected operations teams do not agree to release staff for testing. Stakeholder engagement should identify concerns, power, practical constraints and incentives, then adjust the communication approach as new information emerges. Consider how a user representative might challenge a proposed acceptance criterion because it ignores accessibility, and why resolving that challenge early can protect both the business case and stakeholder trust.

Connect practices to the information a manager needs

The seven PRINCE2 practices are business case, organizing, plans, quality, risk, issues and progress. Each answers a different management question. Business case asks whether the project remains worthwhile. Organizing identifies who decides and contributes. Plans establish the route to products. Quality defines what will make those products fit for purpose. Risk addresses uncertainty. Issues handle actual events, changes and concerns requiring decisions. Progress compares actual and forecast performance with agreed controls. A candidate should recognize where related information belongs and how one practice can affect another.

A risk is something uncertain that may happen; an issue is something that has happened or has been raised for attention. A possible failure of a migration tool may be recorded as a risk, while discovering that the tool cannot process a required database format becomes an issue. Both may influence stage tolerances and the business case. A risk owner is not always the same person as someone who carries out a response action. The issue-management approach should distinguish an off-specification, a request for change and a problem or concern without treating all deviations as automatically approved changes.

Quality planning begins with explicit acceptance criteria and appropriate methods of verification. A product may require inspection, demonstration, testing, regulatory assessment or an external certificate. Merely completing a task does not show the product is acceptable. Quality in project management is therefore not a final-phase inspection; quality needs to inform product descriptions, acceptance methods and rework assumptions before delivery begins. Where an output must connect to a complex existing service, specify interfaces, data rules, performance and security expectations rather than accepting an attractive prototype as sufficient evidence.

Manage products, stages and exceptions without bureaucracy

Product-based planning asks what must be delivered before deciding in detail how to deliver it. A product description can specify purpose, composition, derivation, quality criteria, quality methods and responsibilities. This reduces disagreement among sponsors, users and suppliers. For example, “training complete” is vague; an accepted training product might require materials for named roles, recorded attendance, demonstrated competency and a clear process for maintaining content after go-live. A product breakdown structure and product flow diagram can reveal dependencies that an activity list obscures.

Stages divide project management into manageable commitments. At a boundary, the board reviews performance, revised risk and business justification before authorizing further work. Work packages provide team-level expectations, including products, constraints, resources, reporting and acceptance. Managing by exception uses tolerances such as time, cost, quality, scope, benefits, risk and sustainability to clarify how far delegated managers may go. A tolerance should be measurable enough to predict a breach before it becomes unavoidable. An exception report is not a routine status report; it gives decision makers information and options when the approved boundary is threatened.

Suppose a delivery team forecasts that its remaining work will finish two weeks late but the agreed stage tolerance allows only one week. The relevant manager should escalate the forecast through the defined mechanism, even if no milestone has yet actually slipped. By contrast, a minor reprioritization within tolerances can often be handled locally, documented and communicated appropriately. This principle prevents senior management from micromanaging routine choices while ensuring genuinely material problems reach the people authorized to resolve them.

Recognize the lifecycle and how the method is tailored

PRINCE2's seven processes span starting up a project, directing a project, initiating a project, controlling a stage, managing product delivery, managing a stage boundary and closing a project. Starting up checks whether the proposed endeavor deserves the investment of initiation. Initiating establishes a sufficiently credible management baseline. Directing covers project-board decisions and authorization. Controlling a stage makes delegated management operational. Managing product delivery governs the interface with the team. Boundary management informs the next investment decision, and closure confirms accepted results and a responsible handover.

The processes interact rather than occurring as isolated steps. A board may authorize an initiation stage before it authorizes the full project. A product can be delivered, quality checked and accepted within a management stage while new risks change the forecast at the same time. Near closure, the project manager must distinguish unfinished follow-on work from accepted scope and ensure operational ownership, support arrangements and benefit-review responsibilities are clear. Closing a project with no plan to measure benefits can leave its purpose unproven long after the team is disbanded.

Version 7 can coexist with iterative or agile delivery when decision boundaries, product acceptance and escalation remain explicit. The PRINCE2 Practitioner stage of study emphasizes how these controls are adapted to practical scenarios rather than memorized in isolation. Foundation candidates should already test their understanding against small cases: a fixed regulatory deadline, uncertain software requirements, a multi-supplier integration or a public-facing project with difficult stakeholder expectations. The controls should support good decisions in each setting, not simply produce a stack of documentation.

Prepare by interpreting scenarios, not by collecting definitions

Start with the current official Version 7 syllabus and work through its principles, practices, processes, roles and people considerations. After studying each part, explain a plausible business decision in plain language. Why would the board reconsider a stage? What does the project manager need before approving a work package? Who must accept the product? Which record captures a threat that has not yet occurred? Answering those questions without jargon tests whether the ideas have become usable.

Create a small example project and carry it through startup, initiation, one controlled delivery stage, a decision at a boundary and closure. Write concise product descriptions, stage tolerances, a risk response and an issue requiring approval. Give each artifact an actual purpose. Then introduce a disruption: a supplier changes its lead time or users reject an acceptance criterion. Follow the consequences for plans, risk, quality, governance and the business case. Comparing PRINCE2 Foundation with the more applied Practitioner level is useful only when the distinction changes how you prepare, not as a list of credentials to collect.

Foundation exam practice should focus on understanding the intent of each question and why an appealing alternative is wrong. Because the current exam is closed book, fluent terminology matters, but memory without context is fragile. Recheck the current PeopleCert specification when booking; historical PRINCE2 6 study packs can still teach some familiar concepts, yet they are not an authoritative replacement for Version 7 materials. The practical objective is to recognize when a project needs justification, clear responsibility, product acceptance or a properly escalated decision—and to choose the control that protects delivery without slowing it unnecessarily.