PRINCE2 glossary

A B C D E F G H I K L M O P Q R S T U V W

accept (risk response)

This risk response signifies an organisation’s willingness to take the risk, fully comprehending that if the risk materialises, it will impact the objectives completely.

acceptance

This is the formal recognition that the project has successfully met the agreed acceptance criteria, thereby satisfying the stakeholder requirements.

acceptance criteria

These are a set of prioritised criteria that the final product of the project must fulfil before the customer agrees to accept it. They are measurable definitions of the attributes that make the product set acceptable to key stakeholders.

activity

An activity is a process, function, or task that unfolds over a period, yields identifiable results, and is managed. It’s generally outlined as a component of a process or plan.

agile and agile methods

These are a wide-ranging set of behaviours, frameworks, principles, and techniques that, when combined, enable teams and individuals to work in a manner characteristic of Agile: collaborative, prioritised, iterative, incremental and timeboxed. There are several specific Agile methods, such as Scrum and Kanban. PRINCE2 is entirely compatible with Agile working.

agile behaviours

These behaviours epitomise the Agile way of working, such as collaboration, self-organisation, customer-focus, empowerment, and a culture of trust over blame.

agile plans

Agile plans often present features (or sets of features) in a sequenced order along with their dependencies and are typically formulated collaboratively by the team set to carry out the work. At the delivery-team level, Agile plans are often informal or low-tech, potentially consisting of simple to-do lists or backlogs, but are nonetheless effective. Product-based planning can be applied across all project levels, including product delivery.

Agilometer

The Agilometer tool helps a project team assess the level of risk associated with using agile on a project using PRINCE2. This allows the tailoring of PRINCE2 in ways that best mitigate the level of risk.

approval

This is the formal affirmation that a product is complete and meets its requirements (with any concessions taken into account), as outlined in its product description.

approver

The individual or group (such as a project board) that is recognised as being qualified and authorised to endorse a product (either management or specialist) as complete and fit for purpose.

assurance

These are all the necessary systematic actions that provide confidence that the target (be it a system, process, organisation, programme, project, outcome, benefit, capability, product output, or deliverable) is suitable. Suitability can be subjectively or objectively defined depending on the situation. Assurance is often somewhat independent from what is being assured.

authority

This is the power to assign resources and make decisions, applicable at project, management stage, and team levels.

authorization

This is the moment at which authority is conferred.

avoid (risk response)

This is a risk response to a threat, either removing the potential impact of the threat or ensuring the threat no longer occurs.

Back to top

Backlog

A catalogue of new features to be added to a product. This list might consist of user stories, each articulating the need for a feature and the reason for it. ‘Backlog’ can also be a broad term describing releases, sprints, and products.

backlog item

An entry in a backlog, which may take the form of a user story or task and can be stored in various formats such as spreadsheets or on a whiteboard.

baseline

The reference points against which an entity is monitored and managed.

baseline management product

This refers to a management product defining certain aspects of the project and, once approved, it’s subject to change control.

benefit

The measurable enhancement arising from an outcome, viewed as an advantage by one or more stakeholders.

benefits management approach

A strategy that outlines the management actions and benefits reviews to ensure the project outcomes are achieved, and that the project’s benefits are realised. See benefits management approach.

benefits tolerance

The allowed variation in expected benefits before the deviation needs to be escalated to higher management. This is documented in the business case.

brainstorming

A technique that aids a team in idea generation. During the brainstorming session, ideas aren’t reviewed but are examined at a later stage. This method is often utilised by problem management to identify potential causes.

burn chart

A technique showing progress (such as within a timebox), where completed work and remaining work are depicted with one or more lines that are updated regularly, perhaps even daily.

burn-down chart

This chart visualises the amount of outstanding work.

burn-up chart

This chart shows the amount of work completed.

business ambassador

A role from DSDM that is the main role providing the business view of a project. This role is sometimes known as a requirements engineer or business analyst.

business case

The rationale for a business activity (project), typically including timescales, costs, benefits, and risks, against which ongoing viability is assessed. See business case.

Back to top

centre of excellence

A centralised function within an organisation responsible for providing standardisation, method consistency, process management, knowledge management, assurance and training across portfolios, programmes and projects.

change authority

An individual or group to whom the project board delegates the responsibility of considering requests for changes or off-specifications. The change authority may be given a change budget and can approve changes within that budget.

change budget

The funds allocated to the change authority, which can be used to implement authorised requests for changes.

change control

The process ensuring that all changes potentially affecting the project’s agreed objectives are identified, evaluated and then approved, rejected, or deferred.

change control approach

A description of how the project’s products will be managed and safeguarded, and by whom. See change control approach.

checkpoint report

A progress report given by a team to the project manager at a checkpoint, providing reporting data as defined in the work package. See checkpoint report.

class of service

A broadly defined category for different types of work, influencing selection decisions as different classes of service often have qualitatively different risk profiles, especially regarding schedule risk and the cost of delay. Four generic classes of service are widely recognised: ‘standard’, ‘fixed date’, ‘expedite’, and ‘intangible’.

closure recommendation

A recommendation prepared by the project manager for the project board to issue a project closure notification when they are satisfied that the project can be closed.

communication management approach

A description of the method and frequency of communication between the project and its stakeholders. See communication management approach.

concession

An off-specification that is accepted by the project board without the need for corrective action.

configuration item

An entity subject to change control. The entity could be a component of a product, a product, or a set of products in a release.

configuration item record

A record detailing the status, version and variant of a configuration item, along with important relationships between them. See configuration item record.

configuration management

Administrative and technical activities dealing with the controlled change of a product.

configuration management system

A set of processes, tools and databases used to manage configuration data. In most cases, a project will utilise the configuration management system of either the customer or supplier organisation.

constraints

These are the limitations or restrictions that the project must operate within.

contingency

Something reserved, typically to address time and cost deviations or risks. PRINCE2 does not encourage the use of contingency, as estimating deviations is managed by setting tolerances, and risks are managed through suitable risk responses (including a fallback response contingent on the risk occurring).

contingent plan

A plan designed for use only if necessary (e.g., if a risk response is unsuccessful). Often referred to as a fallback plan.

corporate, programme management or customer standards

These are overarching standards the project must comply with. They influence the four project approaches (communication management, change control, quality management and risk management) and the project controls.

corrective action

A set of measures to resolve a threat to a plan’s tolerances or a defect in a product.

cost tolerance

The permissible variation in a plan’s cost before the deviation needs to be escalated to the next level of management. Cost tolerance is documented in the respective plan.

customer

The person or group who initiated the work and will benefit from the end results.

customer’s quality expectations

A statement describing the expected quality of the project product, captured in the project product description.

customer subject matter expert

A role assigned to the delivery team to act as a representative for all customer stakeholders, ensuring that the project product (and its components) is understood and is accurate at a detailed level. Also known as customer SME.

Back to top

daily log

This is a record maintained to keep track of informal issues or concerns that fall under the jurisdiction of the project manager. See daily log.

definition of ‘done’

A collection of criteria established to verify whether a task or a group of tasks is concluded. It categorizes tasks as either ‘done’ or ‘not done’.

definition of ‘ready’

Criteria employed to evaluate if a task is prepared to be initiated.

deliverable

See output.

delivery approach

This is a specialized strategy implemented to facilitate the production of deliverables.

demo

Short for ‘demonstration’, this is an occasion where a product or an interim product, regardless of its readiness, is presented to an individual or a group (like a customer) to solicit feedback and illustrate progress. The product showcased could be static (such as a paper design) or dynamic (like a working prototype).

DevOps

This is a synergistic approach that merges development and operations with the objective of producing a product or service where the two spheres of work, and potentially the teams as well, unite as seamlessly as possible.

discovery (phase)

Refer to sprint zero.

disruptive

Generally, this term signifies situations laden with considerable uncertainty (like product innovation) and where the product under development is anticipated to significantly disrupt (whether intentionally or unintentionally) the existing environment or marketplace (like 3D printing).

dis-benefit

A quantifiable degradation arising from an outcome deemed negative by one or more stakeholders, thereby diminishing one or more organizational objectives.

Dynamic Systems Development Method (DSDM)

This is an agile project delivery framework designed and owned by the DSDM consortium.

Back to top

early adopter

This term refers to a customer who is among the first to purchase or use a product. They often have a penchant for innovative products and hence, may be ready to pay a premium for them, despite these products potentially not achieving the quality that subsequent customers will receive. Such customers are immensely useful for obtaining early feedback on the product.

emergent

In the context of agile, this refers to the process of formulating solutions and making decisions in a manner that gradually culminates in a precise solution without extensive preparatory work. The antithesis would be to expend time and attempt to predict future events. An example would be ’emergent architecture’ where the approach could either be to plan how the product will be built in advance, or begin work on the product and let the optimal architecture evolve as the product progresses.

embedding (PRINCE2)

The process of integrating something as a core part of a larger entity. An organization needs to do embedding to incorporate PRINCE2 as its company-wide project management method and foster its widespread adoption.

empirical/empiricism

Decision-making based on observable evidence as opposed to reasoning or intuition.

epic

An overarching description of a requirement that hasn’t been adequately refined or comprehended yet. Eventually, an epic will be delineated and broken down into multiple user stories or requirements.

end project report

This is a report presented by the project manager to the project board, confirming the delivery of all products. It updates the business case and evaluates the performance of the project against the original Project Initiation Documentation (PID). See end project report.

end stage assessment

The project board and the project manager review the end stage report to decide on approving the next stage plan. Depending on the project’s size and criticality, the review can be either formal or informal. The decision to proceed should be officially documented.

end stage report

This is a report delivered by the project manager to the project board at the conclusion of each management stage of the project. It informs about the project’s performance during the management stage and the project status at the stage end. See end stage report.

enhance (risk response)

This is a risk response to an opportunity where proactive measures are undertaken to increase both the likelihood of the event happening and the impact of the event if it transpires.

event-driven control

This is a control activated when a specific event takes place. This could be, for instance, the conclusion of a management stage, the completion of the PID, or the generation of an exception report. It can also include organizational events that may influence the project, such as the end of the fiscal year.

exception

This situation arises when it is projected that there will be a deviation beyond the tolerance levels agreed upon between the project manager and the project board (or between the project board and corporate, programme management or the customer).

exception assessment

This is a review by the project board to approve or reject an exception plan.

exception plan

This is a plan that typically follows an exception report. For a stage plan exception, it covers the timeframe from the present to the end of the current management stage. If the exception is at the project level, it would replace the project plan.

exception report

This report details the exception situation, its impact, available options, recommendation, and the impact of the recommendation. It is prepared by the project manager for the project board. See exception report.

executive

This is the individual vested with the overall responsibility to ensure that a project achieves its objectives and delivers the projected benefits. They should ensure that the project maintains its business focus, that it has clear authority, and that the work, including risks, is actively managed. The executive chairs the project board, represents the customer, and is responsible for the business case.

experiment

This is an investigation into a concept that is executed in a series of specific steps (which may involve research) to prove or disprove a theory or idea. This can be utilized to validate an idea or to attempt to enhance something such as the functioning of a team.

exploit (risk response)

This is a risk response to an opportunity. It means seizing the opportunity to guarantee its occurrence and realizing its impact.

Back to top

feature

A general term often used to delineate something a product can do or how it does something. The level of detail in a feature can vary extensively (e.g., it is waterproof, it emits a sound when switched off) and can be linked to a specific requirement, user story, or epic. Another synonymous term is ‘function’.

flow-based

This methodology steers clear of dividing work into timeboxes and instead manages work using a queue. Work is consistently pulled into the system (which might be a high-level timebox in itself) and progresses through various states until its completion.

follow-on action recommendations

These are proposed actions related to unfinished tasks, ongoing issues and risks, and any other tasks needed to move a product to its next life phase. These are summarized and included in the end stage report (for phased handover) and end project report.

Back to top

Gantt chart

This is a widely used technique for scheduling work activities against time using horizontal lines or bars to display when the tasks start and end. This can further be used to schedule dependencies between the tasks. It is more relevant in the context of project management than agile delivery.

gap analysis

This is a process that compares two data sets and identifies the differences. Gap analysis is frequently used to compare a set of requirements with actual delivery.

Glad! Sad! Mad!

This is a feedback method that can be utilized by a team during a retrospective. Each team member writes on one or more sticky notes and places them in the appropriate column. This allows others to understand what made them ‘glad’, ‘sad’, or even ‘mad’ during the last timebox.

governance (corporate)

This refers to the continuous activity of maintaining a robust system of internal control whereby the directors and officers of an organization ensure that effective management systems, including financial monitoring and control systems, have been established to protect assets, earning capacity, and the organization’s reputation.

governance (project)

These are aspects of corporate governance that are specifically tied to project activities. Efficient governance of project management guarantees that an organization’s project portfolio aligns with the organization’s goals, is delivered efficiently, and is sustainable.

Back to top

handover

This is the transfer of ownership of a product set to the respective user(s). The set of products is known as a release. A project may experience more than one handover in its lifecycle (phased delivery). The final handover occurs in the closing a project process.

highlight report

This is a periodic report from the project manager to the project board on management stage progress. See highlight report.

Back to top

impact (of risk)

The outcome of a particular threat or opportunity happening, or the anticipation of such an outcome.

information radiator

A general term describing the use of walls or boards containing information that can be readily accessed by those working on the project. It can contain any information, although it typically shows work to do and how work is progressing.

initiation stage

The time period from when the project board authorizes initiation to when it authorizes the project (or decides not to proceed with it). Detailed planning and the establishment of the project management infrastructure are covered by the initiating a project process.

issue

A relevant event that has occurred, wasn’t planned, and requires management action. It can be any concern, query, request for change, suggestion, or off-specification raised during a project. Project issues can be about anything related to the project.

issue register

A register used to capture and maintain information on all formally managed issues. The issue register should be regularly monitored by the project manager. See issue register.

issue report

A report containing the description, impact assessment, and recommendations for a request for change, off-specification, or a problem/concern. It is only created for issues that need formal handling. See issue report.

Back to top

Kaizen

A Japanese philosophy that translates to ‘good change’ but is widely interpreted as continual improvement. It involves everyone contributing regularly to make many small beneficial changes that build up over time to improve the efficiency of a team or organization’s operations.

Kanban

A method to enhance flow and trigger system improvement through visualization and control of work in progress. In kanji (Chinese characters), it translates to ‘sign’ or ‘large visual board’. In hiragana (Japanese characters), it translates to ‘signal cards’. In technical presentations of the mechanics of Kanban systems, it usually means the latter. Informally, it refers to the use of Kanban systems (visual or otherwise) and the Kanban method.

Kanban board

A tool used in Kanban to visually depict work in the system (or timebox). It typically consists of a series of columns and possibly rows where work items move from left to right as they move through various states to completion.

Kanban method

An evolutionary approach to change described by David J. Anderson via Six Core Practices and Four Foundational Principles.

Kanban system

A ‘pull system’ implemented by limiting the number of Kanban (cards) in circulation.

Kano

A model, developed by Professor Noriaki Kano, used to help understand customer preferences. The Kano model classifies product or service attributes into areas such as basic factors, excitement factors, and performance factors.

Back to top

lead time/cycle time

While these terms sometimes generate different interpretations within the Kanban community, they essentially refer to the duration a work item spends moving through the system or timebox. Hence, although their specific interpretations can vary, they fundamentally represent the same concept.

Lean

An approach that emphasizes process improvement by maximizing value and eliminating waste, such as unproductive time and effort.

Lean Startup

Initially a strategy for creating and managing startup companies, it’s now applied to all types of businesses to help quickly deliver products to customers.

lessons log

An informal collection of lessons that are relevant to the current project or future projects. See lessons log.

lessons report

A document that records any lessons that could be beneficially applied to other projects. The objective of the report is to incite action so that the positive lessons from a project become integrated into the organization’s standard practices, and the organization can prevent the recurrence of negative lessons in future projects. See lessons report.

level of quality

The comprehensive quality level of a product, as defined by the project product description (customer’s quality expectations and acceptance criteria).

Back to top

manage by exception

A technique where variances from a plan that surpass a predetermined control limit are escalated for resolution (e.g., when expenditure exceeds the budget by 10%).

minimum viable product (MVP)

Within a PRINCE2 Agile context, the term MVP generally aligns with the Lean Startup perspective that it is a ‘form of the final product that enables maximum validated learning with minimal effort’. This shouldn’t be confused with the project’s overall viability. Typically, an MVP would be delivered as soon as possible during the project. An MVP is about learning and may not be operationally used; it could take the form of a simple experiment or prototype.

management product

A product required for managing the project and maintaining quality (e.g., highlight report, end stage report). These management products remain constant, regardless of the project type, and can be utilized as described, or with relevant modifications, for all projects. There are three types of management products: baselines, records, and reports.

management stage

A segment of a project that the project manager oversees on behalf of the project board at any given time. At the end of each management stage, the project board reviews the progress to date, the state of the project plan, the business case, risks, and the next stage plan to decide whether to continue with the project.

maturity

A measure of the reliability, efficiency, and effectiveness of a process, function, organization, etc. The most mature processes and functions are formally aligned with business objectives and strategy and are supported by a framework for continual improvement.

maturity model

A method of assessing organizational competence in a specific skill area.

milestone

A noteworthy event in a plan’s schedule, like the completion of key work packages, a development step, or a management stage.

MoSCoW

A technique used to classify items such as requirements or tasks into one of the four following categories based on how they relate to a deadline:
– Must have
– Should have
– Could have
– Won’t have for now.

Back to top

off-specification

Something that the project should deliver but currently isn’t (or is forecasted not to be). It might be a missing product or a product not meeting its specifications. It is one type of issue.

operational and maintenance acceptance

A specific type of acceptance by the individual or group who will support the product after it has been handed over into the operational environment.

outcome

The result of change, usually impacting real-world behaviour and/or circumstances. Outcomes are desired when a change is initiated. They are achieved as a result of the activities carried out to bring about the change.

output

A specialist product that is delivered to a user (or users). Note that management products are not outputs but are created exclusively for managing the project.

Back to top

performance targets

A plan’s goals for time, cost, quality, scope, benefits, and risk.

plan

A detailed proposition for doing or achieving something that outlines the what, when, how, and by whom it will be accomplished. In PRINCE2, the types of plan are: project plan, stage plan, team plan, and exception plan. See plan.

Plan-Do-Check-Act (PDCA)

A four-stage cycle for process management, attributed to W. Edwards Deming. Plan-Do-Check-Act, also known as the Deming Cycle, involves the following stages: Plan (design or revise processes that support the IT services); Do (implement the plan and manage the processes); Check (measure the processes and IT services, compare with objectives, and produce reports); Act (plan and implement changes to improve the processes).

planning horizon

The timeframe for which accurate planning is possible.

planned closure

The PRINCE2 activity to terminate a project.

portfolio

The totality of an organization’s investment (or a segment thereof) in the changes required to achieve its strategic objectives.

premature closure

The PRINCE2 activity to terminate a project before its planned closure. The project manager must ensure that ongoing work is not simply abandoned, but that the project salvages any value created to date, and checks that any gaps left by the project’s cancellation are raised to corporate, programme management, or the customer.

PRINCE2 principles

The guiding obligations for good project management practice that constitute the basis of a project being managed using PRINCE2.

PRINCE2 project

A project that applies the PRINCE2 principles.

probability

The evaluated chance of a specific threat or opportunity occurring, including a consideration of the frequency with which this may arise.

problem

A type of issue (other than a request for change or off-specification) that the project manager needs to resolve or escalate. Also known as a concern.

process

A structured set of activities designed to achieve a specific objective. A process takes one or more defined inputs and transforms them into defined outputs.

product

An input or output, whether tangible or intangible, that can be predefined, created, and tested. PRINCE2 identifies two types of products: management products and specialist products.

product breakdown structure

This term describes a hierarchical division of all the products that a plan is set to produce.

product description

This refers to a detailed depiction of a product, outlining its purpose, composition, derivation, and the criteria for its quality. This description is initially formulated for the major products during the initiation stage, and for other products when planning a subsequent stage. See product description.

product flow diagram

This is a visual representation that illustrates the sequence and dependencies of the products listed in a product breakdown structure.

product owner

This role involves the management of the product backlog. The person in this role ensures maximum value is extracted from the backlog by ordering and prioritizing it.

product roadmap

This document or visual aid displays the proposed development pathway for a product. Typically, it’s a long-term plan spanning several months or even years. While it exists outside the project context, it may trigger project work.

product status account

This is a report that outlines the status of different products. These products can be specified by their identifier or by the part of the project in which they were developed. See product status account.

product-based planning

A technique that leads to a detailed plan, based on the creation and delivery of necessary outputs. It takes into consideration the prerequisite products, quality requirements, and dependencies between products.

programme

This temporary, flexible organizational structure is created to coordinate, oversee, and direct a set of related projects and activities. The purpose is to deliver outcomes and benefits that align with the organization’s strategic objectives. A programme often spans several years.

project

A temporary organization created with the purpose of delivering one or more business products according to a mutually agreed business case.

project approach

A depiction of how the project work is to be undertaken. For instance, whether a product is being built from scratch or an existing product is being purchased.

project assurance

The project board’s responsibility to ensure the project is conducted correctly. Each project board member focuses on a specific area for project assurance, including business assurance for the executive, user assurance for the senior user(s), and supplier assurance for the senior supplier(s).

project brief

A description of a project’s purpose, cost, time, performance requirements, and constraints. Created before the project begins, it’s used during the initiating process to create the PID and its components. After the PID is created, the project brief is no longer maintained. See project brief.

project closure notification

Advice from the project board that informs all stakeholders and host sites that project resources can be released and support services demobilized. It should indicate a closure date for project-related charges.

project initiation documentation (PID)

A logical collection of documents that compile key information required to start a project on solid grounds and communicates this information to all involved parties. See project initiation documentation.

project initiation notification

Advice from the project board to inform all stakeholders and host sites about project initiation and to request logistical support sufficient for the initiation stage.

project kick-off

Typically, a singular event where visioning activities occur, and the team comes together for the first time. Preparation is crucial to use time as effectively as possible during this event, which may include one or more workshops.

project lifecycle

The span of time from a project’s initiation to the acceptance of the project product.

project management

The act of planning, delegating, monitoring, and controlling all aspects of a project, along with motivating those involved, to achieve the project’s objectives within the set performance targets for time, cost, quality, scope, benefits, and risk.

project management team

The comprehensive management structure of a project, including the project board, project manager, team manager, project assurance, and project support roles.

project management team structure

An organizational chart displaying the individuals assigned to the project management team roles, showing their delegation and reporting relationships.

project manager

The individual tasked with the authority and responsibility to manage the project on a day-to-day basis, delivering the required products within the agreed-upon constraints with the project board.

project mandate

An external product produced by the authority commissioning the project, which triggers the start-up of a project.

project office

A temporary office established to support the delivery of a specific change initiative being delivered as a project. If used, the project office takes on the responsibility of the project support role.

project plan

A high-level plan that outlines the major products of the project, their delivery timeline, and costs. An initial project plan is part of the PID, and it’s revised as actual progress information becomes available.

project product

The final deliverable that the project must produce for acceptance.

project product description

A unique type of product description used to agree on the project’s scope and requirements, define the customer’s quality expectations, and establish the acceptance criteria for the project. See project product description.

project support

An administrative role within the project management team. Project support can include advice and help with project management tools, guidance, administrative services such as filing, and the collection of actual data.

prototype

A prototype is a preliminary model of something, created to test or validate an idea, or to better understand a situation (like the customer’s needs). It could either evolve into an actual product or be discarded after use.

proximity (of risk)

This refers to the temporal aspect of risk, i.e., when the risk may occur. The severity of a risk’s impact may vary depending on when the risk transpires.

pull system

A method of operation where work is initiated or ‘pulled’ from upstream as and when capacity is available. In Kanban systems, which are pull systems, the availability of capacity and the ability to pull work is indicated by the gap between current work in progress and the corresponding limit.

push system

The practice of assigning work to a system or activity without considering its available capacity.

Back to top

quality

The extent to which a product, service, process, person, organization, system or resource meets the required standards or specifications.

quality assurance

A process conducted by an independent body (separate from the project team) to verify that a product or service will meet the set requirements or standards.

quality control

A process that involves monitoring project results to ensure they comply with the set standards, and identifying methods to address any unsatisfactory performance.

quality criteria

These are the standards or specifications that a product must meet, along with the measurements that will be used to evaluate the final product.

quality inspection

A methodical, structured evaluation of a product, performed by a selected review team in an organized and documented manner.

quality management

The coordinated activities that guide and control an organization with respect to quality.

quality management approach

This approach determines the quality techniques and standards to be used and identifies responsibilities for achieving the required quality levels throughout a project. See quality management approach.

quality management system

A comprehensive system of quality standards, procedures, and responsibilities for a specific entity or an entire organization.

quality records

Documented evidence demonstrating that the required quality assurance and quality control activities have been executed.

quality register

A record containing summary details of all planned and completed quality activities. It is used by the project manager and project assurance as part of reviewing progress. See quality register.

quality review

This term is identical to quality inspection.

quality review technique

A structured technique, with defined roles, designed to assess if a document (or similar product) is complete, meets set standards, and fulfills the agreed quality criteria.

quality tolerance

The range of acceptable values for a product’s quality criterion, documented in the project product description and each product’s description.

Back to top

records

Dynamic documents that keep track of project progress.

reduce (risk response)

A proactive risk management strategy that aims to decrease the probability or impact of a risk event.

release

A set of products included in a handover, managed, tested, and deployed as a single entity.

requirement

A description of what a product will do and/or how it will do it. A requirement can also be expressed as a user story.

retrospective

A routine event that reviews and improves the process of work execution. It promotes continuous improvement in alignment with agile principles.

reports

Documents that provide a status update on certain aspects of the project.

request for change

A proposal for a change to an established baseline. It is a type of issue.

risk

An uncertain event or set of events that, if they occur, will influence the achievement of objectives. Risks are measured by the combination of the probability of occurrence and the magnitude of their impact.

risk actionee

An assigned individual responsible for executing an action to address a risk. They are required to keep the risk owner updated on the situation.

risk appetite

An organization’s unique stance towards risk-taking, which determines the level of risk it deems acceptable.

risk estimation

The process of assessing the probability and impact of a risk, considering pre-set standards, target risk levels, interdependencies, and other relevant factors.

risk evaluation

The process of understanding the cumulative effect of identified threats and opportunities on a project.

risk exposure

The current level of risk that an organization is subject to.

risk management

A systematic approach that involves identifying and assessing risks, planning and implementing risk responses, and communicating risk management activities to stakeholders.

risk management approach

An approach that describes the goals of risk management, the procedure to be followed, the roles and responsibilities, risk tolerances, the timing of risk management interventions, the tools and techniques to be used, and the reporting requirements. See risk management approach .

risk owner

A designated individual who is responsible for managing, monitoring, and controlling all aspects of a specific risk, including the implementation of chosen responses.

risk profile

A summary of the types of risk an organization faces and its level of exposure to these risks.

risk register

A log of identified risks associated with a project, including their current status and history. See risk register.

risk response

Actions taken to bring a situation to a level where risk exposure is acceptable to the organization.

risk response category

A classification of risk responses. For threats, these categories include avoid, reduce, transfer, share, accept, or prepare contingency plans. For opportunities, they include exploit, enhance, transfer, share, accept, or prepare contingency plans.

risk tolerance

The risk exposure levels that can be exceeded with proper approvals, but which will trigger a response (such as reporting to senior management) if exceeded.

risk tolerance line

A line on the summary risk profile, above which risks cannot be accepted without referring them to a higher authority. For a project, these risks would be referred to the project board.

Back to top

SAFe (Scaled Agile Framework)

A comprehensive framework facilitating the use of agile methodologies across an entire organization.

safe-to-fail

An experiment designed with such safeguards that even in the event of failure, the impact on the overall system or plan remains minimal.

schedule

A visual layout, such as a Gantt chart, illustrating a plan consisting of a sequence of tasks, resource allocations, and so on. In PRINCE2, schedules are included in project, stage, or team plans. Daily actions are recorded in relevant project logs.

scope

For a plan, it encompasses all its products and their detailed requirements. It’s illustrated by the product breakdown structure for the plan and associated product descriptions.

scope tolerance

The permissible variance in a plan’s scope before it necessitates escalation to the next level of management.

Scrum

An iterative approach to product delivery that provides a framework to address complex, adaptive problems while creatively and efficiently delivering products of maximum value.

Scrum master

A role in Scrum responsible for ensuring that the Scrum principles, practices, and rules are understood and followed by the team.

Scrumban

The application of Kanban principles and practices within a Scrum context.

senior supplier

A role within the project board that provides expertise related to the primary discipline(s) involved in the production of the project’s output(s). The senior supplier represents supplier interests within the project and offers supplier resources.

senior user

A project board role responsible for ensuring that user needs are accurately specified, and that the final solution satisfies those needs.

sensitivity analysis

A technique used to test the robustness of a calculation or a model by examining the impact of variations in the input.

spike (or spiking)

A short-term work initiative aimed at gaining more insight about a specific situation, often used to reduce uncertainty from a technical or customer viewpoint.

share (risk response)

A risk response that involves applying a win/lose formula to both a threat or opportunity: both parties share the reward if costs are less than the planned cost, and both share the cost if the planned cost is exceeded.

specialist product

A product that is the focus of the plan. It is project-specific (e.g., an advertising campaign, a car park ticketing system, etc.). Also known as a deliverable.

sponsor

The primary driving force behind a program or project. In PRINCE2, the sponsor is likely to be the executive on the project board, or the individual who appointed the executive.

sprint

A pre-set period (usually 2-4 weeks) designated for creating selected features from the product backlog.

sprint zero

An initial sprint designed to handle many upfront activities such as forming a team, defining the vision, outlining the architecture, etc.

stage

See management stage.

stage plan

A detailed plan that serves as a basis for project management control throughout a management stage.

stakeholder

Any individual, group, or organization that can affect, be affected by, or perceive itself to be affected by a project or initiative.

stand-up meeting

A brief meeting to assess progress, often lasting 15 minutes or less, where work done, work to be done, and any challenges encountered are discussed.

start-up

The activities conducted by the executive and the project manager before the project begins, aimed at producing the outline business case, project brief, and initiation stage plan.

supplier

The individual or group responsible for the delivery of the project’s specialist products.

supplier subject matter expert

A role within the delivery team that provides technical skills to create and initially quality-check the project product. Also known as the supplier SME.

SWOT analysis

An acronym for ‘strengths, weaknesses, opportunities, and threats’. A technique used to identify favorable and unfavorable factors related to a business change or current state.

Back to top

tailoring

The process of adapting a method or process to suit the situation in which it is being used.

team dynamics

The interaction between team members, relating to their attitudes and the team’s culture. These dynamics require careful management as they can either drive the team forward when healthy or cause breakdowns when negative.

team manager

An individual responsible for the creation of products as assigned by the project manager. This role reports to the project manager. If a team manager is not assigned, the project manager assumes these responsibilities.

team plan

An optional plan used for team management control during the execution of work packages.

test-driven

The approach of writing tests or quality checks before creating the product or its parts, instead of after.

theme

An aspect of project management that requires consistent attention and specific treatment for the PRINCE2 processes to be effective.

threat

An uncertain event that could negatively impact the objectives or benefits.

time tolerance

The permissible deviation in a plan’s time before it needs to be escalated to the next level of management.

time-driven control

A type of management control that is scheduled regularly, allowing higher authority to monitor progress.

timebox

A finite time period dedicated to achieving a specific goal or objective. The deadline is fixed, with work within it being prioritized. Lower-level timeboxes are days or weeks long (like sprints), while higher-level ones contain multiple lower-level timeboxes (like stages).

tolerance

The permissible deviation above and below a plan’s target for time and cost before it needs to be escalated to the next level of management. There may also be tolerance levels for quality, scope, benefits, and risk.

transfer (risk response)

A risk response that involves a third party assuming some of the financial impact of a threat, such as through insurance or specific contractual clauses.

trading (or swapping)

The act of managing change by replacing one or more requirements with others of similar size in terms of effort.

transparency

A key agile behavior that involves making as much information visible as possible to facilitate effective work. It encompasses progress display, frequent product delivery, and attributes like openness and honesty.

trigger

An event or decision that initiates a PRINCE2 process.

Back to top

user

The individual or group who will use one or more of the project’s products.

user acceptance

Specific approval given by the individual or group who will use the product after it is handed over to the operational environment.

user story

A technique for writing a requirement in the form of who, what, and why.

Back to top

validated learning

The process of learning through carefully designed, scientific experiments that validate whether the experiment was successful or not.

value

The benefits acquired in proportion to the resources used to achieve them.

velocity

The rate at which a team is progressing. For instance, if a team completes 20 user stories per week, this is their velocity. It can be used to forecast their future rate of progress, given that the conditions remain constant.

vision

The statement that describes a desired future state.

visioning

An activity or phase that aims to understand the overall goal of a project, answering questions like: Why is this work happening? Who is it for? What might it look like?

Back to top

waterfall method

A development approach that is linear and sequential, with each phase having distinct goals. Once a phase is completed, the process moves to the next one without revisiting the previous stages.

work package

A set of information necessary for the creation of one or more products. It includes a description of the work, product descriptions, any production constraints, and confirmation of agreement between the project manager and the person or team manager implementing the work package. See work package.

work in progress (WIP)

Work that has begun but not yet delivered from the system or timebox. It can also indicate the status of incidents, problems, changes, etc.

work-in-progress (WIP) limit

A constraint on the amount of work in progress allowed in a specific part of the system at any one time. Typically represented as a number, it forms the concept of a pull system.

workshop

An event where participants come together to achieve a specific objective, such as creating a list of requirements or solving a problem. It emphasizes interaction and creativity for quick and accurate work.

Back to top