PRINCE2 Foundation (PRINCE2) key terms

The principle that a project must have a valid reason to exist before it starts, and that this reason must be reviewed and remain sound throughout; if it fails, the project is changed or stopped.

The principle that a project team should deliberately seek out lessons from previous work and from its own progress, then act on them instead of simply recording them.

The principle that a project needs an explicit, agreed structure showing who does what, with clear accountability and authority understood by everyone involved.

The principle of splitting the project into manageable chunks, each with its own plan and decision point, so that commitment grows only as detail and confidence grow.

The principle that a higher level sets boundaries for delegated work and intervenes only when those boundaries are forecast to be exceeded, freeing managers from constant reporting.

The principle that a project should first agree what outputs it will create and the quality they must meet, and only then decide the activities needed to create them.

The principle that PRINCE2 must be adapted in depth, rigour and terminology to fit the project's size, complexity, risk, delivery approach and the organisation's existing ways of working.

Any individual, group or organisation that can affect, be affected by, or reasonably perceive itself to be affected by the project, its outputs or its outcomes.

The continuing work of identifying the people with an interest in the project, judging their influence and interest, and deciding how to involve and communicate with them.

A document setting out how the project will keep people informed: which audiences need which information, in what format, how often and who is responsible for sending it.

The documented justification for the project, covering the reasons for it, expected benefits, costs, timescales and key risks, and reviewed at each stage boundary to confirm it still holds.

A measurable improvement created by an outcome that one or more stakeholders judge to be an advantage; benefits are usually realised after the project has closed.

The changed situation that results once the project's outputs are put to use by the organisation; the project influences it but does not fully control it.

The group accountable for the project, made up of an executive, senior users and senior suppliers, which directs the work and takes the key decisions within its authority.

The single person ultimately accountable for the project, who owns the business case, chairs the project board on behalf of the business and judges whether the project remains worthwhile.

The project board role representing the people who will use or gain from the outputs; this person specifies user needs and later confirms that the expected benefits are achieved.

The person who runs the project day to day within the limits set by the project board, delivering the agreed products at the required quality and escalating when limits are threatened.

The amount of deviation allowed from a plan's target in time, cost, scope, quality, benefit or risk before the matter must be referred to the next level of management.

A forecast that an agreed tolerance will be exceeded, which must be reported upwards so that the level above can decide how the project should respond.

An uncertain event that, if it happens, will affect the project's objectives; it is described through its cause, the event itself and the effect it would have.

The degree of uncertainty an organisation or individual is prepared to accept in pursuit of objectives, which guides how much risk is tolerated and how risks are handled.

A working record of the project's risks, showing how each is assessed, who owns it and what response is planned, kept up to date as the project proceeds.

An event that has already happened, was not planned and needs management action; examples include a request for change, a problem, or a product forecast to fail its requirements.

A situation where a product is expected not to meet one or more of its agreed requirements, which must be raised as an issue and handled through change control.

A statement of what a product must be like: its purpose, composition, quality criteria, the method used to check quality, and who produces and approves it.

The measurable conditions a product must satisfy before the customer will accept it; for the whole project these are set out in the project product description.

Checking that products actually meet their agreed quality criteria, for example through reviews, inspections or tests, and recording the outcome of each check.

The trigger that starts a project: a brief statement from the commissioning organisation giving enough information to justify doing initial start-up work.

A document created while starting up the project that outlines purpose, scope, objectives and an initial business case, giving the basis for planning the initiation work.

The collection of documents produced during initiation that sets out the project's rationale, governance, plans, controls and business case, and forms the basis for the board's authorisation.

The project board's process for making decisions at key points: authorising initiation, authorising the project, each stage or exception plan, giving ad hoc direction, and authorising closure.

The process in which the team manager accepts a work package, carries out the work, keeps progress visible and returns the finished products for approval.

The description of a piece of work given to a team, covering the products to be produced, time, cost, tolerances, constraints and the reporting expected while the work runs.

A regular report from the team manager to the project manager giving progress, status of the assigned work and any issues arising during the reporting period.

A progress report from the project manager to the project board at agreed intervals, summarising stage status and flagging any forecast deviation from agreed tolerances.

A report written at the close of a management stage that summarises performance so far and gives the project board what it needs to decide how to proceed.

A report produced when the project is closed, reviewing performance against the plan and the business case and confirming whether the project's objectives were met.

A running record of lessons identified during the project, together with what should be done differently, used to improve the work as it continues.

A report produced at the end of a stage or of the project that summarises the lessons found and recommends improvements for future projects and the wider organisation.

The process of confirming that products are accepted, reviewing benefits and lessons, and handing over ongoing responsibilities so the project can be ended in a controlled way.