Free PRINCE2 Foundation Exam Flashcards

A PRINCE2 project must have a valid reason to start and must keep that justification throughout its life. If the project stops being desirable, viable, or achievable, it should be changed or stopped rather than continued by habit.

PRINCE2 expects lessons to be sought before the project, captured during work, and passed on at closure. The point is not just recording lessons, but using them to improve decisions while the project is still active.

Everyone involved should know what they are accountable for and what others are expected to provide. PRINCE2 separates business, user, and supplier interests so decisions are not dominated by only one viewpoint.

The project is planned, authorized, monitored, and controlled one management stage at a time. Stage boundaries create decision points where the Project Board can review progress before committing further resources.

Authority is delegated within agreed tolerances. If forecasts stay inside tolerance, the lower management level can continue; if a tolerance is forecast to be exceeded, the exception is escalated for a decision.

PRINCE2 starts by defining what products are needed and what quality criteria they must meet. Activities and schedules should flow from the required outputs, not from vague lists of tasks.

PRINCE2 must be adapted to the project's size, risk, complexity, importance, team capability, and delivery approach. Tailoring changes how the method is applied, not whether the principles are followed.

The Business Case explains why the project is worth doing. It gives decision-makers a basis for judging benefits, costs, risks, time, and strategic fit before and during the project.

The Executive is accountable for ensuring the project remains justified. The Project Manager may help maintain the document, but ownership of business value sits with the Executive.

A strong Business Case shows that the project is desirable for the organization, viable as an investment, and achievable with the available capability and constraints.

Benefits should be defined in measurable terms and linked to who will realize them. Some benefits may occur after project closure, so benefit review responsibilities must be clear.

A dis-benefit is an expected negative outcome of the project, not a risk. It belongs in business justification because decision-makers need to weigh both planned advantages and planned disadvantages.

The Project Board provides direction and major decisions. It represents business, user, and supplier interests through the Executive, Senior User, and Senior Supplier roles.

The Executive represents the business interest, owns the Business Case, and is ultimately accountable for project success. This role balances value for money against risk and continued justification.

The Senior User represents those who will use the project's products or receive the benefits. This role helps define needs, confirms user acceptance, and supports benefit realization.

The Senior Supplier represents the people or organizations that design, build, or provide specialist products. This role is concerned with supplier capability, technical integrity, and feasible delivery.

The Project Manager runs the project day to day on behalf of the Project Board. The role plans, delegates, monitors, controls, reports, and escalates when tolerances are forecast to be exceeded.

A Team Manager accepts, manages, and delivers Work Packages. This role reports progress to the Project Manager and focuses on producing agreed specialist products.

Quality criteria describe the measurable features a product must have to be acceptable. They make acceptance less subjective and help prevent disputes about whether a product is complete.

A Product Description defines a product's purpose, composition, quality criteria, quality methods, and responsibilities. It is central to product-based planning and quality control.

The Quality Register records planned and completed quality activities. It gives the Project Manager evidence that reviews, tests, inspections, or approvals are being performed as planned.

The Project Plan is the high-level plan for the whole project. It supports authorization, gives a baseline for project-level control, and is refined through Stage Plans.

A Stage Plan gives enough detail to manage the current management stage. It is more detailed than the Project Plan because it guides near-term control and reporting.

An Exception Plan replaces a plan that is no longer forecast to stay within tolerance. It is prepared when higher authority asks for a revised way forward after an exception.

A risk is an uncertain event or set of events that would affect objectives if it occurred. PRINCE2 treats threats and opportunities as risks because both can change project outcomes.

The Risk Register records identified risks, assessments, responses, owners, and status. It is the main control record for keeping risk information visible and current.

The risk owner is accountable for managing a risk. A risk actionee carries out specific response actions, but accountability stays with the risk owner.

An issue is an event that has happened, a concern, a request for change, or a problem that requires management action. Unlike a risk, it is no longer merely uncertain.

The Issue Register records issues that need formal management. It supports impact assessment, decisions, ownership, and tracking through to resolution.

A Change Authority may be delegated responsibility for approving certain changes within agreed limits. This prevents the Project Board from having to decide every small change request.

Tolerance is the permitted deviation above or below a plan's targets before escalation is required. It is the practical mechanism that supports management by exception.

PRINCE2 commonly controls time, cost, quality, scope, benefits, and risk through tolerances. A forecast breach in any agreed tolerance area requires escalation to the next management level.

A Highlight Report is the Project Manager's regular progress report to the Project Board. It summarizes status, key achievements, issues, risks, and forecast against tolerances.

A Checkpoint Report is used by a Team Manager to report Work Package progress to the Project Manager. It supports control at the delivery level.

An Exception Report warns that a plan is forecast to exceed tolerance and explains the impact, options, and recommendation. It prompts the higher management level to decide what happens next.

Starting up checks whether the idea is worth initiating. It creates early information such as the Project Brief and helps avoid spending effort on a project that lacks basic justification.

Directing a Project is where the Project Board authorizes initiation, stages, exceptions, and closure. It provides governance without managing daily project work.

Initiating builds a firm foundation before full delivery commitment. It develops the Project Initiation Documentation, detailed strategies, controls, and baselines for managing the project.

Controlling a Stage is the Project Manager's day-to-day control process. It includes authorizing work, monitoring progress, managing issues and risks, reporting, and taking corrective action within tolerance.

Managing Product Delivery controls the link between the Project Manager and delivery teams. Work Packages are accepted, products are created, and completed work is returned for approval.

Managing a Stage Boundary prepares the information the Project Board needs to review the current stage and decide whether to authorize the next one.

Closing confirms whether products have been accepted, evaluates performance, captures lessons, and recommends project closure. It prevents projects from drifting on after their purpose has been addressed.

The Project Brief is created early to describe the project in enough detail for the Project Board to decide whether initiation is worthwhile. It is lighter than the PID.

The PID is the baseline for how the project will be directed and managed. It brings together key information such as business justification, plans, controls, strategies, and roles.

A Work Package defines the work and products assigned to a team or supplier. It should clarify scope, constraints, quality expectations, reporting, and approval arrangements.

The Lessons Log captures useful observations during the project. It supports the learn from experience principle by making lessons available before the final Lessons Report.

The End Stage Report summarizes how a stage performed against its plan. It helps the Project Board judge whether the project remains justified and whether the next stage should be authorized.

The End Project Report compares final results with the approved baselines and records what was delivered, what remains open, and what lessons should be passed on.

PRINCE2 recognizes that projects depend on people, not only processes. Communication, stakeholder engagement, leadership, collaboration, and role clarity affect whether governance works in practice.

Tailoring adjusts the method to fit the project context. It does not mean dropping principles, ignoring governance, or removing controls that are needed to protect business justification and accountability.