PRINCE2 7 Practitioner key terms

A principle requiring that a project has a valid, documented reason to start and to continue, reviewed at every decision point so that work stops when the justification no longer holds.

A principle requiring everyone in the project to seek out, record and act on lessons as work proceeds, rather than only at the end, so good practice is repeated and mistakes are avoided.

A principle requiring a clear organization structure with agreed roles, accountabilities and reporting lines, so that everyone knows what they must do and who is empowered to decide.

A principle that divides the project into manageable periods separated by decision points, letting the project board review progress, confirm justification and authorize the next stage of work.

A principle of delegating authority within agreed limits and requiring people to escalate a forecast breach to the next management level instead of waiting for it to happen.

A principle that defines the project by the products it must deliver, agreeing each product's purpose, quality criteria and acceptance before work starts, so plans and quality activity follow the outputs.

A principle that PRINCE2 should be adapted to the project's size, complexity, risk, delivery approach and environment; elements may be combined or adjusted, but the principles are never dropped.

Any individual or group with an interest in, or influence over, the project and its outcomes, including the people affected by the change as well as those who sponsor or deliver it.

The planned work of identifying stakeholders, analysing their interest and influence, and communicating with them appropriately so they understand, support and are not surprised by the project.

The directing level of the project, accountable for it and made up of the executive, senior user and senior supplier, which authorizes stages, makes key decisions and controls by exception.

The single accountable owner of the project on the project board, who secures funding and resources, ensures continued business justification and balances user needs against supplier capability.

The project board role representing the people who will use the project's products; specifies user needs, secures user resources and is accountable for realizing the benefits defined in the business case.

The project board role representing the parties that design, develop and deliver the products, accountable for delivery quality and for the supplier resources committed to the project.

The role accountable for day-to-day management of the project within the tolerances set by the board, including planning, monitoring, controlling, risk and issue management, and reporting progress.

The role responsible for producing the products assigned in a work package, directing the team's work and reporting progress, quality and issues to the project manager.

Independent monitoring carried out on behalf of the project board to check that the project follows its agreed standards and controls, giving the board confidence without taking part in day-to-day management.

The first process, which turns the initial mandate into a project brief by appointing the board and project manager, capturing lessons and defining how initiation will be carried out.

The project board's process for authorizing initiation, each stage and closure, giving ad hoc direction and controlling by exception, rather than managing the project's day-to-day work.

The process that builds the project's baseline, including the business case, plans, controls and organization, and obtains the board's authority to begin delivering the products.

The project manager's process for authorizing work packages, monitoring progress and quality, dealing with issues and risks, reporting to the board and deciding when a stage is finished.

The team's process for accepting, executing and delivering a work package, confirming products meet their descriptions and quality criteria, and reporting progress and issues upwards.

The process at the end of a stage where the project manager reports actual performance, updates the business case and plans, and prepares the next stage plan for board approval.

The process that confirms products are accepted and handed over, puts benefit-review arrangements in place, captures lessons and disbands the team so the project ends in a controlled way.

The description agreed between the project manager and a team manager of a piece of work to be done, covering products, tolerances, constraints, reporting needs and acceptance criteria.

The documented justification for the project, setting out reasons, options, expected benefits, costs, timescales and risks, used by the board to judge whether the project remains worthwhile.

A document defining how and when the business case's benefits will be measured and reviewed, who is responsible, and what will happen after the project closes.

The set of documents produced while initiating the project that defines its baseline, including business case, plans, organization, controls, risk and quality arrangements, and is used to authorize delivery.

A statement of a product's purpose, composition, quality criteria, quality method and acceptance evidence, used to agree what is to be delivered and how it will be judged acceptable.

A log of the quality activities planned for the project, such as reviews, tests and acceptance steps, with dates, responsibilities and results, used to check that quality is being achieved.

An uncertain event that, if it occurs, will affect the project's objectives, recorded with cause, event, effect, owner, probability, impact and response so that it can be managed proactively.

The amount of risk an organization or person is willing to accept in pursuit of a benefit, used to set tolerances and to guide how much risk is accepted, shared or reduced.

The person accountable for a specific risk, responsible for choosing and implementing its response, monitoring it and escalating it when it moves beyond their authority.

A relevant event that has already happened and needs management action: a problem or concern, a change request, or an off-specification where a product will not meet its requirements.

The permissible limits of deviation from the plan, in time, cost, scope, quality, risk and benefits, within which a management level can act without escalating to the level above.

A report produced when a forecast breach of tolerance is identified, describing the situation, available options and a recommended action so that the next management level can decide.

A periodic report from the project manager to the project board summarizing achievement against the stage plan, tolerance position, issues, risks and work expected in the next period.

A record of lessons identified throughout the project, whether from earlier projects or found during this one, used to inform decisions and passed on for future work.

Deliberately adapting how PRINCE2 practices, processes, roles and documents are applied to fit the project's size, complexity, risk and environment, without dropping any principle.

The longer-term work of making PRINCE2 part of how an organization routinely runs projects, through training, support, tooling and consistent use, so good practice becomes normal.

The internal and external context in which a project runs, including culture, standards, commercial arrangements, delivery approach, regulation and location, which shapes how PRINCE2 is tailored.