APM PFQ key terms

A temporary piece of work, with a defined start and end, that a team carries out to create a unique product, service or result within agreed limits on time, cost and quality.

The series of phases a project moves through from the initial idea to handover and closure, each ending in a review or decision about whether to continue.

A group of related projects managed together, alongside business-as-usual activity, to deliver outcomes and benefits that could not be achieved by running them separately.

A distinct section of a project life cycle that produces a defined set of outputs and ends at a decision point before the next section begins.

A formal decision point at the end of a phase where authorised people review progress and the business case, then approve, redirect or stop the work.

An approach where the project passes through its phases in a set sequence, with requirements largely defined at the start; suited to stable, well-understood work.

An approach that delivers the project in repeated cycles, allowing requirements and solutions to be refined through feedback rather than fixed fully at the outset.

The change in behaviour, capability or state that happens when people use what the project delivered, and the point at which benefits start to appear.

The document that justifies a project by setting out the reasons for it, the options considered, expected costs, risks and benefits, and is reviewed at key decision points.

A measurable improvement or advantage that a stakeholder sees as positive, arising from the project's outputs and usually realised after the project has closed.

The work of making sure the benefits written into the business case actually happen, by measuring them after delivery and taking action where they fall short.

The measures set at the start of a project that will be used to judge whether it has succeeded, covering areas such as time, cost, quality and benefits.

A log listing each expected benefit with its owner, how it will be measured, when it should appear and how it links to project outputs.

The arrangements an organisation puts in place to direct and control its projects: who has authority, how decisions are made, and how performance is reported and assured.

The senior person who owns the business case, secures resources and funding, gives strategic direction and is accountable to the organisation for the project's success.

The person who plans and runs the project day to day, leads the team, monitors progress against the plan and deals with issues and changes within delegated limits.

A committee of senior stakeholders that meets regularly to give direction, approve plans and major changes, and resolve problems that the project manager cannot settle.

A team that supports projects across an organisation by providing standard methods, templates, reporting, tooling and often assurance reviews.

Independent checks, carried out by people outside the project team, that processes and products meet agreed standards, giving decision-makers confidence that the project is under control.

Anyone who can influence the project, is affected by it, or believes they are affected by it, including customers, users, suppliers and internal groups.

The process of identifying the people and groups around a project and assessing their interest, influence and attitude so that engagement can be planned.

A simple chart that plots stakeholders by how much influence they have and how interested they are, helping decide who to manage closely, keep informed or simply monitor.

A document that sets out what information each audience needs, in what form, how often and from whom, plus how feedback will be captured.

A hierarchical breakdown of everything the project must deliver, dividing the scope into progressively smaller packages of work that can be estimated, scheduled and controlled.

A bar chart that shows activities along a calendar timescale, with bars representing duration, links showing sequence, and progress marked against the plan.

The longest chain of dependent activities through the schedule; it sets the shortest time the project can take, and any delay on it delays the end date.

A significant point in the schedule, such as a delivery, approval or decision, shown with zero duration and used to track progress.

An approved, frozen version of the plan covering scope, schedule and cost, kept unchanged so that actual progress and proposed changes can be measured against it.

The amount of spare time an activity has before it starts to delay the next activity or the project's finish date; activities on the critical path have none.

An uncertain event or set of circumstances that, if it happens, will affect the project's objectives; the effect may be negative (a threat) or positive (an opportunity).

Something that has already happened and is affecting the project now, so it needs a decision or action rather than an assessment of likelihood.

A log of the identified risks, recording for each one its cause, potential effect, likelihood and impact rating, owner and agreed response.

The named person responsible for keeping a particular risk under review and making sure the agreed response is carried out.

The action chosen to deal with an identified risk, for example avoid it, reduce its likelihood or impact, transfer it to someone else, or accept it.

The extent to which a project's products, and the way they are produced, meet stated requirements and are fit for the purpose the users need.

The preventive activities that check and improve the processes used to create products, so that defects are avoided rather than found later.

The checks carried out on finished products, such as reviews, tests and inspections, to confirm they meet the agreed standards and acceptance criteria.

A formal process for recording a proposed change, assessing its impact on scope, cost, time and risk, then having the right people approve or reject it.

A written request to alter something already agreed, such as scope, schedule or cost, which is then assessed and decided through change control.

The specific, testable conditions that a product must meet before the customer or user agrees to accept it at handover.