Project Management Glossary: 141 Terms Explained

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.

Asynchronous communication

Messages that do not require both parties to be present at the same moment — comments, documents, recorded updates. The reader picks them up when they can.

Why it matters: It is far cheaper in attention than a meeting, and across timezones it is the only thing that actually works.

Audit trail

The automatic record of what changed, when, and who changed it. A tool that keeps one gives you the history for free; a spreadsheet emailed round the team gives you nothing.

Why it matters: It is cheap to have and impossible to reconstruct later. The moment two people remember a decision differently, the audit trail is the only thing in the room that was not there arguing. See 6.2 Issue Resolution and Change Management.

Availability

The share of a person’s working time genuinely free for project work, after operational duties, meetings and leave. Plans built on 100% availability are always late; 50-70% is a more honest starting point for people who also carry a queue.

Why it matters: A schedule built from effort figures and full-time people is a schedule nobody ever agreed to. Ask what fraction of the week someone actually has before you commit to their dates.

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.

Benefits realisation

Checking, some time after delivery, whether the project actually produced the outcome it was funded for. Not whether it shipped on time — whether the thing it promised to change actually changed.

Why it matters: It is the only real test of whether a project succeeded rather than merely shipped. It is also the step most often skipped, because by the time the answer is available everyone has moved on to the next thing.

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.

Bottom-up estimating

Estimating every small piece of work on its own and adding the pieces upward. The total is then a consequence of the parts, rather than a number the parts were quietly squeezed to fit.

Why it matters: It is slower than a figure produced at the top of the plan, and far harder to argue with, because each number belongs to somebody who has to do that work. It also needs the work broken down first, which is why it usually arrives alongside a WBS. See 3.2 Creating a Project Schedule.

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.

Bus factor

How many people would have to become unavailable before critical knowledge is lost with them. Count the people who could keep a given piece of work moving; that number is the bus factor.

Why it matters: A bus factor of one is a single point of dependency with a friendlier name. Holidays expose it rather more often than buses do.

Business as usual (BAU)

A common name for operational work, used especially when it is being contrasted with change or project work in a budget conversation. “BAU capacity” is the share of a team that is not available for projects.

Why it matters: Projects are usually staffed out of whatever BAU leaves behind. If nobody has said out loud how much that is, the plan is being drawn against time that is already spoken for.

Business case

The argument that a project is worth more than it costs, and worth more than the other things the same money and people could be doing instead. On a small project it can be one sentence naming what gets displaced.

Why it matters: A project with no business case never gets cancelled when conditions change, because nobody wrote down which conditions it depended on. See 2.1 Initiation Phase.

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.

Change control board (CCB)

A named group that approves or rejects change requests, used on larger projects where no single person should be making those calls alone.

Why it matters: A board is overhead, and it earns that overhead only when the money committed between decisions is large. On a six-week project it mostly turns a two-minute conversation into a fortnight. See 6.2 Issue Resolution and Change Management.

Change request

The specific, written ask that enters change control: what should change, why, who wants it, and what it is worth. It is the item on the agenda, not the process that handles it.

Why it matters: Writing the request down is what turns a corridor conversation into something that can be costed, scheduled, or declined. Verbal changes get approved by default.

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.

Close-out report

The formal summary of what a project delivered against what it promised, together with its lessons learned. Usually written at the end, usually in a hurry.

Why it matters: It is worth the effort in proportion to who will actually read it. Written for a named audience it is genuinely useful; written for the file it is an expensive way to close a folder.

Closing

The final lifecycle phase: formal acceptance of the deliverables, handover to whoever will live with them, administrative closure of budgets and contracts, a retrospective, and releasing the team.

Why it matters: Closing is the phase most often skipped, because by the time it arrives everyone has already been moved onto the next thing. Skipping it is how an organisation can run fifty projects and learn nothing from any of them. See 2.4 Closing Phase.

Communication plan

An agreement about who receives what information, how often, through which channel and from whom.

Why it matters: One page, or it will not be followed. A plan nobody can remember is a plan nobody uses. See 4.2 Stakeholder Management.

Constraint

A fixed limit the project has to work within — a date, a budget, a regulation, a technology someone else already chose. Constraints shape the plan; they do not bend to it.

Why it matters: A constraint written down at the start becomes a design decision. The same constraint discovered in month four becomes a replan. See 3.0 Foundations of Project Planning.

Context switching

The cost of moving between unrelated tasks. Two half-days on one thing produce less than one full day, which is why project time chopped into fragments under-delivers against its own arithmetic.

Why it matters: It is why splitting one person across three projects does not give you three thirds of a person. Consolidate someone’s time before concluding they are slow.

Contingency reserve

Time or money deliberately held back for uncertainty you know is there but cannot yet name. Held at project level, with a named owner who decides when it is released — the formal version of the buffer above.

Why it matters: Contingency kept in the open can be spent as a conscious decision. Contingency hidden inside individual task estimates is spent anyway, just without anyone noticing. Same money, entirely different project.

Cost of change

The observation that fixing a defect or a misunderstanding gets dramatically more expensive the later in the lifecycle it is found — roughly an order of magnitude per stage. It is the economic argument for planning and early review.

Why it matters: It is why an hour spent clarifying a requirement is not overhead. The same misunderstanding found after go-live costs days, a rebuild, and an apology.

CPD (continuing professional development)

The learning you log to keep a professional credential current — courses, conference sessions, mentoring, and often the project work itself. Most certifying bodies ask for a set number of hours or credits inside a fixed renewal cycle.

Why it matters: Nobody thinks about it until the renewal email arrives. Logged as you go it is an afternoon of admin; left to the last fortnight it is a scramble, and the habit was supposed to be the point.

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.

Cycle time

How long an item takes from the moment work starts on it to the moment it is done. Measured across recent items, it tells you the rate this team actually delivers at.

Why it matters: It predicts future delivery better than an estimate does, for the unglamorous reason that it is measured rather than guessed. See 6.1 Monitoring Deliverables.

D

Dashboard

A live view of project state that people pull from when they want it, rather than a document pushed at them on a schedule.

Why it matters: It replaces the data-transfer half of reporting and none of the interpretation. Somebody still has to say what the numbers mean. See 6.1 Monitoring Deliverables.

Decision log

The single running list of decisions taken on a project — what was decided, when, by whom, and on what reasoning. The individual entries are decision records; the log is where they all live so nobody has to go hunting.

Why it matters: One list beats twelve inboxes. When a decision is challenged months later, the question is settled in the time it takes to open the log — provided somebody actually kept it.

Decision record

A short note of what was decided, what was rejected, and why. A few lines is usually enough, provided the “why” is honest.

Why it matters: It is cheap when written at the time and impossible to reconstruct afterwards. Six months on, nobody remembers the option you turned down — only that the current design looks odd.

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.

Deliberate practice

Working specifically on the thing you are bad at, with feedback, instead of repeating the parts you already do well. For a project manager that usually means running the awkward conversation, not producing another schedule.

Why it matters: Ten years of experience and ten years of improvement are different quantities, and plenty of people have the first. Deliberate practice is what converts one into the other.

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.

Delivery lead

A common title for the person accountable for getting a body of work delivered, used widely in organisations that have quietly retired the phrase “project manager”. The work is much the same: sequencing, unblocking, and being honest about dates.

Why it matters: Titles vary far more than the job does. Read the accountabilities rather than the label — in job adverts, and in your own remit when somebody hands you one.

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.

Engagement plan

Per stakeholder: what they need, in what format, how often, and who owns sending it. It is the output of stakeholder analysis, and the part usually skipped.

Why it matters: Analysis that stops at a grid changes nothing. The plan is where knowing who matters turns into someone actually being told. See 4.2 Stakeholder Management.

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.

Escalation path

The agreed route a problem takes when it cannot be resolved where it arose, and how quickly it should travel.

Why it matters: Agreed in advance, or improvised under pressure. The second version is how a solvable issue reaches the sponsor a fortnight late. See 6.2 Issue Resolution and Change Management.

Estimate

A considered guess at how much effort or time something will take, made with the information available at the time. It is a range with a confidence attached, not a promise.

Why it matters: Estimates turn into commitments the moment they are repeated to someone senior, and the caveats never survive the journey. Say how confident you are when you give one, and say it in writing. See 3.2 Creating a Project Schedule.

Exception report

A report sent only when something crosses an agreed threshold — a date slipping past its tolerance, a cost passing a limit — rather than at a fixed interval.

Why it matters: A report that arrives every week whether or not anything happened teaches people to stop opening it. One that arrives only when it means something gets read. See 6.1 Monitoring Deliverables.

Execution

The lifecycle phase in which the planned work is actually carried out and steered. The loop is short and repeats: observe what happened, compare it to the baseline, decide, tell people.

Why it matters: Execution is not the phase where you stop managing and start doing. A plan nobody compares reality against is a document, not a plan. See 2.3 Execution Phase.

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.

Hindsight bias

The habit of believing an outcome was obvious all along, once you know how it turned out. It quietly rewrites how uncertain things genuinely felt at the time.

Why it matters: It is what turns a retrospective into a blame exercise. The useful question is never “why did nobody see it” but “what did we know then, and what would have shown us more”.

Hybrid approach

Running some parts of a project sequentially and others iteratively, deliberately — a fixed hardware delivery alongside software built in two-week slices, say.

Why it matters: This is the usual real-world answer, and it only causes trouble when it is unstated and nobody knows which half of the project they are standing in. See 5.2 Agile vs. Waterfall.

Hybrid delivery

Running a project with a mix of predictive planning and iterative delivery: a plan and a baseline for the parts that are well understood, short cycles and a backlog for the parts that are not. As of the mid-2020s this is the majority of real practice, not a compromise position.

Why it matters: Most teams are already working this way without having said so. Naming it lets you decide, deliberately, which half of the project gets a baseline and which gets a backlog, instead of arguing about methodology. See 5.2 Agile vs. Waterfall.

I

Increment

The usable output of an iteration: something that works, rather than a partially finished layer of something that does not.

Why it matters: “The database is finished” is not an increment. It is a claim nobody outside the team can check. See 5.2 Agile vs. Waterfall.

Information radiator

An always-visible display of project state — a board, a wall chart, a dashboard — that people pull from rather than being told.

Why it matters: It replaces most routine status reporting. Anyone who wants to know where things stand can simply look, which is faster than asking and harder to spin. See 6.1 Monitoring Deliverables.

Initiation

The first lifecycle phase, in which a request is defined well enough to be approved, deferred or declined. Its output is the project charter.

Why it matters: Initiation is the last point at which a project can be stopped cheaply. Every week it is skipped makes “no” more expensive to say. See 2.1 Initiation Phase.

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.

Knowledge transfer

Deliberately moving what a project learned out of individual heads and into a form a future team can find and use: documents, runbooks, recorded walkthroughs, or simply sitting with the people who will take it on.

Why it matters: It only happens if someone schedules it. Left to goodwill it competes with delivery work, and delivery work wins every time.

Known issues

The list of defects and limitations shipped deliberately, each with its workaround. Everything you already know is wrong and released anyway.

Why it matters: Honesty here costs a conversation; its absence costs trust. People forgive a documented limitation far more readily than one they discover for themselves.

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.

KPT (Keep, Problem, Try)

A simple retrospective format that asks three questions: what should we keep doing, what caused problems, and what should we try next.

Why it matters: The scaffolding does the work. Making “Problem” a named category turns raising one into filling in a box, rather than making a complaint.

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.

Leading indicator

A measure that moves before the outcome does — how old the review queue is, how many items are blocked, how long approvals are taking.

Why it matters: It is more useful than a measure that confirms what has already happened. A missed milestone tells you the truth a month after you could have done anything about it. See 6.1 Monitoring Deliverables.

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

Matrix organisation

A structure where people report to a line manager while also working on projects led by someone else.

Why it matters: Efficient on paper, and the origin of most priority conflicts in practice. When both bosses want Tuesday, somebody has to decide, and it is rarely the person holding the calendar. See 4.1 Building a Project Team.

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.

Mitigation

Action taken to make a risk less likely to happen, or less damaging if it does. To count as mitigation it needs a task with a date and an owner, not an intention.

Why it matters: “We’ll keep an eye on it” appears in the mitigation column of a great many risk registers, and has never once reduced a risk. See 3.4 Risk Management Plan.

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.

O

Operations

Repeating work that keeps an existing service running — support, payroll, order processing, monitoring. It has no planned end, and it is improved by making it more consistent rather than more novel. Projects create things; operations run them.

Why it matters: Operational work responds to standardisation, not to milestones and plans. Project-managing it adds ceremony without adding certainty. See 1.3 Projects vs. Daily Operations.

Overallocation

A person committed to more hours than they actually have in a given period. It is almost never deliberate: it happens when two plans each quietly assume the same person, so it is only visible from a view that spans both projects.

Why it matters: Each plan looks reasonable on its own, which is exactly why checking them one at a time never finds the problem. The person usually notices first, and rarely by saying so.

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.

PDU (Professional Development Unit)

PMI’s unit of continuing-education credit. One PDU is roughly one hour of qualifying learning or giving back, and a PMP holder needs 60 of them in every three-year renewal cycle.

Why it matters: They are far easier to collect than people expect — a webinar, a chapter meeting, mentoring a colleague all count — and far harder to collect in the last month of a cycle.

Percent complete

A self-reported estimate of how much of a task is done, and by implication how much of it remains.

Why it matters: It is systematically optimistic near the end — the last 10% that takes as long as the first 90 — which is why it needs a verifiable measure standing beside it. See 6.1 Monitoring Deliverables.

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.

Phase gate

A decision point between two phases, where someone with the authority to do so confirms whether the project continues, changes shape, or stops. Also called a stage gate or a toll gate.

Why it matters: The whole point of a gate is that stopping is a real option. A gate that has never once ended a project is not a gate; it is a meeting. See 2.0 The Project Lifecycle.

PMI (Project Management Institute)

The professional body behind the PMBOK Guide and the PMP certification. Its definitions are the closest thing the field has to a shared vocabulary, which is why they turn up in almost every introduction to the subject.

Why it matters: Knowing where a definition came from tells you how much weight it carries in an argument. PMI wording is the version most people will recognise — including whoever is marking your exam.

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.

PMP (Project Management Professional)

PMI’s flagship certification and the most widely recognised project management credential internationally. It is experience-gated: 36 to 60 months of leading projects depending on your education, plus 35 contact hours of formal training, before you may sit the exam.

Why it matters: It will not make you a better project manager by itself, but in a great many markets it is the filter that decides whether your CV is read at all. The experience requirement also means it cannot be crammed in a fortnight.

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.

Post-mortem

A review held after something went wrong, usually focused on a single incident: what happened, why, and what would stop it happening again.

Why it matters: It is not the same thing as a retrospective, which covers a whole project regardless of outcome. A post-mortem is triggered by a failure; a retrospective happens anyway.

Power/interest grid

A two-by-two sort of stakeholders by their ability to affect the project and the attention they are paying to it, used to decide how much engagement each one receives.

Why it matters: The dangerous quadrant is high power with low interest — the person who is not watching until, quite suddenly, they are. See 4.2 Stakeholder Management.

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.

PRINCE2

A structured project method built from a set of principles, practices and processes, with defined roles and a defined set of management documents. It is certified at Foundation and Practitioner level by PeopleCert; PRINCE2 7 is the current version, and it remains close to the default in UK government work.

Why it matters: Its real value is that everyone using it means the same thing by the same document. Its cost is the paperwork, which is meant to be scaled down to fit small projects and very often is not.

Product manager

The person accountable for what gets built and why — the problem, the users, the priorities. A project manager is accountable for getting an agreed thing delivered. The two roles overlap constantly and are not the same job.

Why it matters: Where both roles exist and nobody has drawn the line, priority disagreements turn personal. Where neither exists, the loudest stakeholder becomes the product manager by default.

Project

A temporary effort that produces a unique product, service or result. Both halves matter: “temporary” rules out ongoing operations, “unique” rules out repeated procedures. Size is irrelevant — a two-week internal tool build qualifies; a five-year support contract doesn’t.

Why it matters: It is the test that decides how much apparatus the work deserves. Fail either half and you are holding operations or a checklist, both of which want lighter handling. See 1.1 Defining a Project.

Project lifecycle

The sequence of phases a project passes through from beginning to end. The most common version has four: initiation, planning, execution and closing.

Why it matters: Knowing which phase you are in tells you which question you are supposed to be answering. “Should we do this at all?” is a different job from “are we on track?”, and projects go wrong when the two get mixed up. See 2.0 The Project Lifecycle.

Project team

The people doing a project’s work, usually borrowed from their normal roles for its duration and returned at the end. Distinct from the wider set of people affected by it.

Why it matters: Borrowed people have another job waiting, and their line manager has not forgotten it. Naming the team makes that competition explicit instead of a surprise in week six. See 4.1 Building a Project Team.

Psychological safety

The shared belief that raising a problem, asking an obvious question, or admitting a mistake will not be held against you.

Why it matters: It is the input-quality control on every review a team runs. Without it, your retrospectives, risk registers and status reports all collect the same thing: whatever people felt safe saying.

Q

QCD (Quality, Cost, Delivery)

Shorthand for the three things a project is judged on, and the three that trade against each other. Common in manufacturing and operations; closely related to the triple constraint.

Why it matters: It is the same trade-off your operations colleagues already argue about, under a different name. Recognising that saves a translation step in the meeting.

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.

RAG status

Red, amber, green labelling of project health, applied either to a project as a whole or to each workstream.

Why it matters: It means something only if the three labels are defined in terms of the date and agreed in advance. Otherwise amber means “I am worried” and green means “I would rather not discuss it”. See 6.1 Monitoring Deliverables.

Re-baselining

Formally replacing the plan you measure against, because the scope, dates or budget that were agreed have changed and the old baseline no longer describes what anyone signed up to.

Why it matters: Done once with the reason recorded, it is legitimate housekeeping. Done quietly every time the variance looks bad, it is how a project stays green until the week it ships. See 6.2 Issue Resolution and Change Management.

Resource allocation

Deciding who and what is committed to which piece of work, and when. It is the step that turns a schedule from a wish into a commitment.

Why it matters: A plan with dates but no names attached is a forecast. Until someone specific is booked for specific weeks, nothing has actually been promised. See 4.1 Building a Project Team.

Resource levelling

Moving tasks within their available float to smooth out peaks in demand, so nobody is asked for three weeks of work in one week.

Why it matters: It is free when the tasks sit off the critical path, and impossible when they sit on it. That single distinction decides whether an overload is a scheduling problem or a staffing one. See 3.2 Creating a Project Schedule.

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

An uncertain event that would affect the project if it happened. Stated properly it has a cause, an event and an effect — “vendor risk” is a topic, not a risk statement.

Why it matters: A risk nobody can state in full is a risk nobody can own, price or respond to. Writing the sentence out is most of the work. See 3.4 Risk Management Plan.

Risk matrix

A grid of likelihood against impact, used to sort risks by how much attention each one deserves. It is a prioritising tool, not a measurement: the difference between a 12 and a 15 is noise.

Why it matters: It answers “what do we talk about first?” quickly and well. It stops being useful the moment someone starts defending a score to two decimal places.

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.

Rolling wave planning

Planning near-term work in detail and distant work in coarse blocks, then refining each block as it comes closer. Everything gets planned properly; not everything gets planned now.

Why it matters: It sidesteps both of the standard failures — refusing to plan past next month, and writing a day-by-day schedule for work eighteen months out that will be wrong by Tuesday. See 3.0 Foundations of Project Planning.

Root cause

The underlying reason an issue occurred, as opposed to the symptom you noticed first. The failed release is the symptom; the test environment nobody owns is the cause.

Why it matters: Worth the effort when the same issue keeps coming back. Not worth it for a one-off you have already fixed. See 7.2 Project Retrospective and Evaluation.

Runbook

Written instructions for performing a task someone else normally does — the steps, the access, the bit that always goes wrong halfway through.

Why it matters: The cheapest partial insurance against a single point of dependency. Partial, because a runbook carries the procedure and not the judgement. See 7.3 Learning for the Next Project.

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.

Scope statement

The document holding a project’s objective, deliverables, acceptance criteria, exclusions, assumptions and constraints in one place. It is the thing you point at when someone asks “is that part of this?”

Why it matters: It turns the project boundary from something people remember differently into something they can read. See 3.1 Defining Scope.

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.

Sign-off

A named person’s explicit confirmation that a deliverable is accepted. Not a nod in a corridor, and not silence on an email thread — a name and a date.

Why it matters: Sign-off is the moment “done” stops being an opinion and becomes a fact. It also records who agreed to what, which matters most on the day somebody remembers it differently. See 7.1 Deliverables Handover.

Single point of dependency

A piece of work only one person can do.

Why it matters: Invisible while they are present, and the most reliable predictor of where a schedule will break. The holiday calendar repays reading as a risk register.

Single source of truth

One place that holds the authoritative state of the work — the plan, the status, the open issues — which everybody reads from and writes to.

Why it matters: Two places means neither is authoritative, and reconciling them quietly becomes somebody’s job. Usually yours, usually on a Friday. See 6.1 Monitoring Deliverables.

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.

Sprint

Scrum’s name for a fixed-length iteration, usually one to four weeks, ending in something reviewable and a retrospective.

Why it matters: The length is fixed and the scope flexes, never the other way round. A sprint that gets extended to fit the work has stopped measuring anything.

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.

Stakeholder register

The list of stakeholders with their interest, influence, what they need and who owns the relationship.

Why it matters: Alive if it is reviewed on a schedule; a document if it is not. 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.

Status report

A periodic summary of progress, risks and the decisions somebody needs to make.

Why it matters: Valuable when it interprets — here is what changed and what it means. Wasted when it lists what a tool already shows on its own. See 6.1 Monitoring Deliverables.

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.

Survivorship bias

Drawing lessons only from the projects, teams or companies that made it through, because the ones that failed are no longer around to be studied. The advice that comes out is usually confident and frequently wrong.

Why it matters: “Every successful team we looked at did X” means nothing until you know how many failed teams also did X. Ask what is missing from the sample before you copy anybody.

T

Tacit knowledge

What people know without having written it down: judgement, context, the history behind an odd decision, who to ask when something breaks.

Why it matters: It is the largest and most perishable store a project has. It leaves with the person, quietly, and the gap is usually noticed some weeks later by somebody else.

Task

The smallest unit of tracked work: owned by one person, small enough to estimate, and capable of being finished.

Why it matters: A task nobody can tell is finished is a note, not a task. “Improve onboarding” will still be sitting on the board in March. See 3.2 Creating a Project Schedule.

Throughput

How much work a process completes per unit of time. The headline metric for operations, and a poor one for projects, where finishing the right thing beats finishing many things.

Why it matters: Measuring a project on throughput rewards whoever closes the most trivial tasks. Count accepted deliverables instead.

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.”

Trigger

The observable event that says a risk is turning into reality and the planned response should start now. Good triggers contain a number and need no judgement call.

Why it matters: A response plan without a trigger gets used late, once the damage is obvious to everyone. “If the test environment slips past the 14th” starts on time; “if things look bad” never quite does. See 3.4 Risk Management Plan.

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?”

T-shaped

Shorthand for someone with genuine depth in one discipline and enough working knowledge of the neighbouring ones to talk to those specialists properly. The vertical stroke is the depth; the horizontal stroke is the breadth.

Why it matters: Teams of pure specialists spend their lives queueing behind each other; teams of pure generalists produce work nobody trusts. A few T-shaped people are what keeps things moving when someone is on leave.

Tuckman’s stages

The forming–storming–norming–performing description of how new groups settle.

Why it matters: Most useful as reassurance that the awkward, argumentative middle phase is a phase rather than a casting error. See 4.1 Building a Project Team.

V

Variance

The gap between what the plan said and what actually happened, measured in time, cost or scope. Normally written as a plus or minus against the baseline.

Why it matters: Variance is information, not blame. Treat it as blame and it stops being reported accurately, at which point you have lost both the information and the trust. See 6.1 Monitoring Deliverables.

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

Warranty period

An agreed window after handover during which the delivering team still answers questions and fixes defects, with no ambiguity about whose problem it is.

Why it matters: Its value is that it has an end date. Support that trails on indefinitely quietly becomes somebody’s second job.

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.

Watermelon report

A status that stays green on the outside while the project goes red underneath, then flips without warning a fortnight before the deadline.

Why it matters: It is usually a symptom of undefined labels rather than dishonesty. People report green because nobody ever told them what amber was supposed to mean. See 6.1 Monitoring Deliverables.

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.

Work package

The smallest item at the bottom of a work breakdown structure — a piece of scope small enough to estimate, hand to one owner, and track to completion.

Why it matters: It is where a plan stops being an intention and becomes someone’s week. If you cannot name who owns a work package and what finishing it looks like, the decomposition has not gone far enough.

Where to go next

← Back to the full Project Management Essentials contents