Project Management Glossary: 70 Terms in Plain English

Project Management Glossary

Every profession has a private vocabulary, and project management has more than most. This page explains the terms you will actually hear in a status meeting — what each one means, why it matters, and which chapter of the guide covers it properly.

You do not need to read this page top to bottom. Bookmark it, and come back when someone says “we’re re-baselining because the critical path shifted” and you want to know whether to be worried. (You probably should be. See critical path.)

Start here: the three terms everything else hangs off

Most project vocabulary is a variation on three ideas: what you are delivering (scope), by when (time), and with what (cost). Change one and at least one other has to move. That relationship has a name — the triple constraint — and it is the closest thing project management has to a law of physics.

A

Acceptance criteria

The specific, checkable conditions a deliverable must meet before the customer or sponsor will sign it off. Good acceptance criteria are written before the work starts and are phrased so that two people looking at the same result would reach the same verdict.

Why it matters: “Is it done?” is the most expensive argument on any project. Acceptance criteria settle it in advance. Without them, “done” becomes a negotiation at exactly the moment you have no time left to negotiate. See 7.1 Deliverables Handover.

Agile

A family of delivery approaches built on short cycles, working output at the end of each cycle, and the expectation that requirements will change. Scrum and Kanban are the two most common flavours. Agile is not “planning less” — it is planning in smaller, more frequent increments.

Why it matters: Agile suits work where the destination is genuinely uncertain. It suits fixed-scope, fixed-date, heavily regulated work far less well. Choosing wrongly here costs more than any tool decision you will make. See 5.2 Agile vs. Waterfall.

Analogous estimating

Estimating a task by comparing it to a similar task from a past project. “The last migration like this took six weeks, so budget six weeks.” Fast, cheap, and only as good as the similarity of the two situations.

Why it matters: It is the estimate you can produce in a meeting, which makes it the estimate people accidentally treat as a commitment. Label it as a rough order of magnitude when you give it. See 3.2 Creating a Project Schedule.

Assumption

Something you have treated as true in order to plan, but have not verified. “The vendor API will be available in March.” “Two designers will be free from week 4.”

Why it matters: Every assumption is a risk wearing a disguise. Writing them down converts invisible fragility into a list you can actually manage — and gives you the receipts when one turns out to be false.

B

Backlog

An ordered list of everything the team could work on, with the most important item at the top. In Scrum, the product backlog holds the whole product; the sprint backlog holds only what the team committed to this cycle.

Why it matters: A backlog is a prioritisation device, not a storage cupboard. If everything in it is “high priority”, you do not have a backlog — you have a wish list.

Baseline

The approved version of the plan — scope, schedule, and budget as agreed at a point in time — frozen so you can measure drift against it. When change is approved formally, you re-baseline: you create a new official version rather than quietly editing the old one.

Why it matters: Without a baseline, “we’re three weeks late” is meaningless, because late against what? The baseline is what makes delay measurable rather than a feeling.

Blocker

Anything that stops work progressing and cannot be resolved by the person holding the task. A missing decision, an unavailable environment, an approval sitting in someone’s inbox.

Why it matters: Blockers are the highest-leverage thing a project manager touches. An hour spent unblocking someone often buys back days. Ask about them daily; escalate them the same day.

Buffer (contingency)

Deliberately reserved time or money, held to absorb the things you know will happen but cannot name yet. Best held centrally at the project level rather than sprinkled invisibly into each task estimate.

Why it matters: Buffer hidden inside individual estimates gets consumed silently — work expands to fill it (Parkinson’s Law). Buffer held visibly at project level can be spent as a conscious decision.

Burndown chart

A line chart showing remaining work against remaining time. The ideal line falls steadily to zero on the final day; the actual line shows whether you will make it.

Why it matters: It answers “will we finish?” earlier and more honestly than a percentage-complete figure, because it exposes flat stretches where nothing actually closed.

C

Change control

The agreed process for evaluating, approving, and recording changes to an approved baseline. Typically: request raised → impact assessed on scope, schedule and cost → decision made by a named person or board → baseline updated.

Why it matters: Change is not the enemy; unrecorded change is. Change control does not exist to say no. It exists to make sure everyone sees the price tag before saying yes. See 6.2 Issue Resolution and Change Management.

Project charter

The short document that formally authorises the project. It names the purpose, the high-level scope, the sponsor, the project manager, the budget envelope, and the success criteria — usually in two pages or fewer.

Why it matters: The charter is your mandate. When someone six weeks in asks “who decided this?”, the charter is the answer. See 2.1 Initiation Phase.

Critical path

The longest chain of dependent tasks through the project. Its length is the project’s minimum duration. Tasks on the critical path have zero float: delay any one of them by a day and the whole project moves by a day.

Why it matters: It tells you where your attention is worth the most. Speeding up a task that is not on the critical path buys you exactly nothing. See 3.2 Creating a Project Schedule.

Crashing

Shortening the schedule by adding resources to critical-path tasks — more people, overtime, paid expedite. Always increases cost, and often increases risk.

Why it matters: Crashing has sharply diminishing returns. Nine women cannot deliver a baby in one month, and nine developers cannot always halve a four-week task.

D

Definition of Done

A team-wide checklist that applies to every item of work: coded, reviewed, tested, documented, deployed. Distinct from acceptance criteria, which are specific to one deliverable.

Why it matters: It is the cure for the “90% done” task that stays 90% done for three weeks. See 6.1 Monitoring Deliverables.

Deliverable

A tangible, verifiable output the project produces — a document, a system, a trained team, a migrated database. Not an activity: “run workshops” is a task, “approved requirements document” is a deliverable.

Why it matters: Progress measured in completed tasks flatters you. Progress measured in accepted deliverables tells the truth.

Dependency

A relationship where one task’s timing constrains another’s. The common type is finish-to-start (B cannot begin until A ends), but start-to-start, finish-to-finish and start-to-finish all exist.

Why it matters: Missed dependencies are the single most common reason a schedule that looked fine on Monday is broken by Friday. They are also the reason one small delay becomes five.

Duration vs. effort

Effort is how much work a task takes (16 person-hours). Duration is how long it occupies the calendar (4 days, because the person is only on it half-time and there is a weekend).

Why it matters: Confusing the two is the classic first-time-PM schedule error. Summing effort and calling it a timeline produces a plan that was never achievable.

E

Earned Value Management (EVM)

A technique that compares three numbers: what you planned to have done by now, what you have actually completed (its budgeted value), and what you actually spent. From these you get a schedule performance index and a cost performance index — both roughly “1.0 is on plan”.

Why it matters: It is the only widely-used method that catches the project which is on budget purely because it is behind schedule and has not spent the money yet.

Escalation

Deliberately raising an issue to someone with the authority to resolve it, when the project team cannot. A defined escalation path names who, for what, and how quickly.

Why it matters: Escalation is not failure and it is not tattling — it is a routing decision. Teams that treat it as an admission of defeat sit on problems until they are unfixable.

F

Fast tracking

Compressing the schedule by overlapping tasks that were planned to run in sequence — starting build before design is fully signed off, for instance.

Why it matters: Unlike crashing it costs no extra money, but it buys speed with rework risk. Use it where the upstream task is stable enough that late changes are unlikely.

Float (slack)

How long a task can be delayed without pushing out the project end date. Tasks on the critical path have zero float by definition.

Why it matters: Float tells you where you have room to absorb bad news. Knowing which tasks have three weeks of float and which have none changes how you respond when someone calls in sick.

G

Gantt chart

A horizontal bar chart of the schedule: tasks down the left, dates across the top, one bar per task showing when it starts and ends. Dependencies appear as arrows, milestones as diamonds.

Why it matters: It is the fastest way for a whole team — including people who do not read plans — to see how their work connects to everyone else’s. See 5.1 Using Gantt Charts.

Governance

The structure of decision rights: who approves what, which forums meet when, what has to be reported and to whom.

Why it matters: Most projects that feel “stuck” are not short of effort. They are short of a named person who is allowed to decide.

H

Handover

The formal transfer of finished deliverables to whoever will own and operate them, together with the documentation, training, and support arrangements that make ownership real.

Why it matters: A deliverable nobody knows how to run has not really been delivered. See 7.1 Deliverables Handover.

I

Issue vs. risk

A risk might happen. An issue already has. Risks get probability and impact scores; issues get an owner and a due date.

Why it matters: Teams that log everything as an “issue” have no early warning system. Teams that log everything as a “risk” never actually fix anything. See 6.2 Issue Resolution and Change Management.

Iteration

One fixed-length cycle of work that produces something reviewable. In Scrum it is called a sprint and typically runs one to four weeks.

Why it matters: The fixed length is the point. It creates a regular, unavoidable moment where reality gets compared to expectation.

K

Kanban

A flow-based method: work moves across a board of columns (To Do → In Progress → Done), and each column has a limit on how many items it may hold at once.

Why it matters: The column limits are the mechanism, not the board. Limiting work in progress is what forces a team to finish things instead of starting things.

Kickoff

The meeting that formally starts the project with everyone present: purpose, scope, roles, timeline, ways of working, and how decisions will get made.

Why it matters: It is the cheapest hour on the project. Misalignment that survives kickoff tends to surface in month three, priced in weeks.

KPI

A key performance indicator — a measure chosen in advance to show whether the project is achieving its purpose, not just completing its tasks.

Why it matters: Delivering on time and on budget is not success if the thing delivered does not move the number it was built to move.

L

Lag and lead

Lag is enforced waiting between dependent tasks (concrete must cure for three days). Lead is permitted overlap (start drafting the manual two weeks before build finishes).

Why it matters: Schedules that ignore lag are optimistic fiction; schedules that ignore lead are longer than they need to be.

Lessons learned

Recorded insight from what went well and badly, captured in a form the next project can actually use.

Why it matters: A lesson that lives only in a closed document is not a lesson, it is an anecdote. It counts when it changes a template, a checklist, or an estimate. See 7.3 Learning for the Next Project.

M

Milestone

A zero-duration marker for a significant point: an approval, a go-live, a phase gate. It consumes no time itself — it records that something meaningful has been reached.

Why it matters: Milestones are what stakeholders actually track. Choose ones that represent real, verifiable state changes rather than calendar dates you hope to hit.

MoSCoW

A prioritisation method sorting requirements into Must have, Should have, Could have, and Won’t have (this time).

Why it matters: The “Won’t have” column is the valuable one. Explicitly deciding what you are not doing is the single best defence against scope creep.

P

Parametric estimating

Estimating by multiplying a measured unit rate by a quantity: 20 pages at 1 hour per page equals 20 hours.

Why it matters: More defensible than gut feel, and it scales cleanly — but only when your unit rate comes from real historical data rather than optimism.

PERT / three-point estimating

Estimating with three numbers instead of one: optimistic (O), most likely (M), and pessimistic (P). The PERT expected value is (O + 4M + P) / 6.

Why it matters: Single-point estimates hide uncertainty. Three points make the range visible, which changes the conversation from “is it six weeks?” to “how much of the range are we willing to carry?” See 3.2 Creating a Project Schedule.

Phase

A distinct stage of the project lifecycle — initiation, planning, execution, closure — each with its own goals and exit criteria.

Why it matters: Phases give you natural checkpoints to stop and ask whether continuing is still the right call. See 2.0 The Project Lifecycle.

PMO

A Project (or Portfolio) Management Office — the central function that sets standards, maintains templates, and reports across projects.

Why it matters: A good PMO removes work from project managers by supplying reusable structure. A bad one adds reporting overhead and calls it governance.

Portfolio, programme, project

A project delivers one specific outcome. A programme coordinates related projects toward a shared benefit. A portfolio is all of an organisation’s programmes and projects, managed together for strategic fit.

Why it matters: Applying project-level control to a programme produces micromanagement; applying programme-level control to a project produces drift.

Predecessor / successor

In a dependency, the predecessor is the task that must move first and the successor is the one waiting on it.

Why it matters: This is the vocabulary every scheduling tool uses. Getting it backwards produces a plan that silently inverts your logic.

Q

Quality assurance vs. quality control

QA is about the process — are we working in a way that tends to produce good results? QC is about the product — is this specific output acceptable? QA is preventive; QC is detective.

Why it matters: Teams that only do QC find the same class of defect over and over, because nothing upstream ever changes.

R

RACI matrix

A grid mapping tasks to people using four labels: Responsible (does the work), Accountable (answers for the outcome — exactly one per task), Consulted (asked before), Informed (told after).

Why it matters: The rule that there is precisely one A per row is what makes it useful. Two accountable people means nobody is. See 4.1 Building a Project Team.

Retrospective

A structured team review of how the work went — not what was built, but how the building felt and what to change next cycle.

Why it matters: A retrospective that produces no committed change is a therapy session. Leave with at most two actions, each with an owner. See 7.2 Project Retrospective and Evaluation.

Risk register

The living list of identified risks, each with a probability, an impact, a response strategy (avoid, reduce, transfer, accept), and a named owner.

Why it matters: A risk register reviewed monthly is a management tool. One written at kickoff and never opened again is a compliance artefact. See 3.4 Risk Management Plan.

S

Scope

The full definition of what the project will deliver — and, just as importantly, what it will not.

Why it matters: Scope is the only constraint you control directly at the start. See 3.1 Defining Scope.

Scope creep

The gradual expansion of scope through small additions that individually seem trivial and collectively consume the schedule. Each one arrives as “while you’re in there, could you just…”

Why it matters: Scope creep rarely kills a project with one blow. It kills by a thousand accepted favours, none of which was ever costed.

Scrum

A specific Agile framework with fixed roles (Product Owner, Scrum Master, Developers), fixed events (sprint planning, daily standup, review, retrospective), and fixed artefacts (product backlog, sprint backlog, increment).

Why it matters: Scrum is prescriptive by design. Adopting the events without the roles — a common half-measure — usually produces meetings without decisions.

Sponsor

The senior person who owns the business case, holds the budget, and has authority to resolve what the project team cannot.

Why it matters: An engaged sponsor is the strongest single predictor of project success. If you cannot name yours, that is the first problem to fix.

Stakeholder

Anyone who affects the project or is affected by it — sponsors, users, regulators, adjacent teams, the people whose workflow your deliverable will change.

Why it matters: The stakeholder you forgot is the one who objects at the final review. See 4.2 Stakeholder Management.

Standup (daily scrum)

A short daily sync — fifteen minutes or less — covering what moved, what is next, and what is blocked.

Why it matters: It is a coordination event, not a status report to the manager. The moment it becomes the latter, people start optimising their answers.

Steering committee

The governance forum of senior stakeholders that reviews progress, resolves escalations, and approves significant change.

Why it matters: Bring decisions, not narratives. A steering pack that reports without asking for anything trains the committee to stop reading it.

Story point

A relative unit of size combining effort, complexity and uncertainty. Deliberately not hours — the point is comparison, not conversion.

Why it matters: The moment an organisation publishes a points-to-hours conversion, story points become hours with extra steps and their usefulness ends.

T

Timebox

A fixed period allocated to an activity, where the deadline is immovable and the output flexes to fit.

Why it matters: Timeboxing is how you stop open-ended investigation from eating a schedule. “Two days to research options, then we decide with what we have.”

Triple constraint

The interlocking relationship between scope, time and cost, with quality in the middle. Change one and at least one other must move.

Why it matters: It gives you a calm, non-confrontational way to answer a request for more scope: “Yes — from time, or from budget?”

V

Velocity

The amount of work a team actually completes per iteration, averaged over recent cycles. Used to forecast how much of the backlog fits into the remaining time.

Why it matters: Velocity is a planning input, never a performance target. The instant it is used to compare teams, it gets inflated and stops forecasting anything.

W

Waterfall

A sequential approach where each phase completes and is approved before the next begins: requirements, design, build, test, deploy.

Why it matters: Waterfall gets an unfair reputation. Where requirements are genuinely stable and change is genuinely expensive — construction, regulated hardware, compliance work — it remains the right choice. See 5.2 Agile vs. Waterfall.

Work Breakdown Structure (WBS)

A hierarchical decomposition of the total scope into progressively smaller pieces, until each bottom-level item (a work package) is small enough to estimate and assign confidently.

Why it matters: The WBS is the backbone of everything downstream — the schedule, the budget, the assignments, and the progress measure all derive from it. Anything not in the WBS is, by definition, out of scope. See 3.1 Defining Scope.

Work in progress (WIP) limit

A cap on how many items may sit in a given state at once, used in Kanban to force completion before new work starts.

Why it matters: High WIP feels productive and is not. Everything is started, nothing is finished, and every item carries the cost of being repeatedly picked up and put down.

Where to go next

← Back to the full Project Management Essentials contents