PMGT-BC key terms

A temporary effort undertaken to create a unique product, service, or result, with a defined start and end and limited resources. It contrasts with ongoing operations, which are repetitive and continuous.

The interdependent balance among scope, time, and cost that shapes a project's quality outcomes. Changing any one of these three typically forces adjustment in at least one of the others.

The sequence of phases a project passes through from initiation to closure. Phases may be predictive, iterative, or adaptive, and each ends with a review or deliverable.

A review point at the end of a project phase where stakeholders decide whether to continue, revise, or stop the work. It provides governance control before resources are committed to the next phase.

Any individual, group, or organization that can affect, be affected by, or perceive itself to be affected by a project decision or outcome. Engagement levels must be planned and monitored.

A document listing project stakeholders along with their roles, interests, influence, and engagement needs. It is created early and updated as the stakeholder landscape changes.

Any unique, verifiable product, service, or result produced to complete a project or phase. Deliverables are tangible outputs that can be inspected and accepted by the customer or sponsor.

A significant point or event in a project with zero duration, used to mark progress or completion of a key achievement. Milestones carry no effort but signal decision or reporting points.

A document that formally authorizes a project and gives the project manager authority to apply resources. It records high-level scope, objectives, and the sponsor's approval.

The person or group providing resources and support for a project and accountable for its success. The sponsor champions the project, approves the charter, and resolves escalated issues.

The approved combination of the project scope statement, work breakdown structure, and WBS dictionary. It is the reference used to detect and evaluate scope changes.

A hierarchical decomposition of the total scope of work into manageable, deliverable-oriented components. The lowest levels, called work packages, support estimating, scheduling, and control.

A formal process for reviewing, approving, or rejecting modifications to project baselines. It ensures that changes are documented, assessed for impact, and authorized before implementation.

The practice of identifying, tracking, and controlling versions of project documents, products, and baselines. It ensures that only approved versions are used and that changes are traceable.

A document defining who needs what information, when, in what format, and through which channel. It guides how project information flows among stakeholders throughout the life cycle.

The longest sequence of dependent activities through a network diagram that determines the shortest possible project duration. Any delay on this path delays the whole project unless compressed.

A graphical representation of project activities and their logical dependencies, such as finish-to-start relationships. It supports schedule development and identification of the critical path.

A relationship in which one activity depends on another for its start or finish. Dependencies may be mandatory, discretionary, internal, or external, and they constrain scheduling options.

A technique for shortening the project schedule without reducing scope, using fast tracking or crashing. Both approaches typically introduce added risk, cost, or rework.

A bar chart showing scheduled activities against a calendar timeline, including durations and sometimes dependencies. It gives a visual overview of planned versus actual progress.

A technique that integrates scope, schedule, and cost to measure project performance against a baseline. It compares planned value, earned value, and actual cost to forecast outcomes.

The approved, time-phased budget used to measure and monitor project cost performance. It excludes management reserves but includes contingency reserves for known risks.

A budget or time allowance set aside for identified risks with accepted responses. It is part of the cost or schedule baseline and is released by the project manager as needed.

A document recording identified risks, their analysis, owners, and planned responses. It is reviewed and updated throughout the project as risk conditions change.

A planned action taken to address an identified risk, such as avoiding, mitigating, transferring, or accepting it. The chosen strategy depends on whether the risk is a threat or an opportunity.

The process of comparing planned performance with actual performance to identify deviations. It helps teams understand causes of differences and decide whether corrective action is needed.

A deliberate adjustment made to bring future project performance back in line with the plan. It responds to an identified deviation rather than changing the baseline itself.

The planned, systematic activities that ensure a project uses the right processes to meet quality requirements. It focuses on process improvement rather than inspecting finished outputs.

The process of inspecting and testing outputs to verify they meet specified quality standards. It identifies defects and triggers corrective action or rework before acceptance.

A statement of four core values and twelve principles that favor individuals, working software, customer collaboration, and responsiveness to change over rigid plans and documentation. It underpins most adaptive frameworks.

A fixed-length iteration, commonly one to four weeks, in which a Scrum team produces a potentially shippable product increment. Scope is protected once the sprint begins.

An ordered, evolving list of everything that might be needed in the product, maintained by the product owner. Items near the top are refined and ready for upcoming iterations.

The Scrum role responsible for maximizing product value by managing and ordering the product backlog. This person represents customer and stakeholder needs and sets priorities.

A short, plain-language description of a feature from the user's perspective, often written as who, what, and why. Stories include acceptance criteria that define when they are complete.

A shared checklist of criteria that a product increment must satisfy before it is considered complete. It creates a consistent quality bar across the team and across iterations.

The sum of completed product backlog items produced during an iteration, delivered in a usable condition. Each increment builds on previous ones and must meet the definition of done.

A recurring team meeting at the end of an iteration to inspect how the team worked and choose improvements. It focuses on process, collaboration, and tools rather than product scope.

An ongoing effort to incrementally enhance products, processes, and team practices through regular reflection and small experiments. It is a recurring theme in adaptive and quality-focused approaches.

A visual workflow tool that shows work items moving through columns representing process stages. It uses work-in-progress limits to expose bottlenecks and improve flow.

A cap on how many items may occupy a workflow stage at one time. Limiting work in progress reduces multitasking, shortens cycle time, and makes bottlenecks visible.

The elapsed time from when work begins on an item until it is completed. It is a flow metric used to forecast delivery and to evaluate process improvements.

A short, repeating time box in which a team plans, builds, and reviews a portion of the product. Iterations enable frequent feedback and incremental delivery of value.

The practice of gathering needs from stakeholders through techniques such as interviews, workshops, observation, and surveys. The goal is to uncover both stated and unstated needs.

The ability to link requirements forward to design, build, and test artifacts and backward to their source. It supports impact analysis, coverage checks, and change management.

A document justifying a project or investment by comparing expected benefits against costs and risks. It supports the decision to initiate, continue, or terminate work.

The conditions a product, feature, or story must satisfy to be accepted by the customer or stakeholder. They make requirements testable and reduce ambiguity about completion.