PMP Glossary: 100 Terms Every Candidate Needs

I have always thought one of the most underrated PMP study tools is a tight, useful glossary. Not the bloated 500-term dictionaries in the back of textbooks, but a focused list of the terms you will genuinely encounter on the exam and in real project work. The vocabulary is what makes everything else fit together. Once you internalise the language of project management, the frameworks, the formulas, the agile concepts, and the situational questions all become easier to navigate.

In this guide I have curated 100 essential PMP terms, grouped by knowledge area and supplemented with critical concepts from agile, hybrid, and earned value management. Each entry includes a one-sentence definition plus a brief practical example so you understand not just what the term means but how it shows up in real projects. Use this as a reference while you study, a quick refresher before exams or interviews, and a vocabulary checklist as you tackle PMBOK 7. By the end you will have a working glossary that earns its place on your desk.

I recommend reading through this glossary once in order. Then come back to it any time you encounter a term in a practice question or a PMBOK section that you cannot define cleanly in your own words. The glossary is not a substitute for working through the underlying concepts, but it makes the surface-level vocabulary problem disappear so you can focus on the harder work of judgement and application.

A few tips for getting the most from it:

• Read definitions out loud. Speaking activates a different memory channel than reading.
• Tag your weak terms. Mark the ten or twenty terms you forget most often and revisit them daily.
• Pair with practice questions. When you get a practice question wrong, identify the vocabulary you tripped on and re-read that entry.
• Apply to real projects. When you encounter a term, ask yourself how it manifests on a project you have actually worked on.

The goal is fluency, not memorisation. You should be able to recognise these terms in context and use them comfortably in conversation.

1. Project charter. A document authorising the project, naming the sponsor and project manager, and outlining high-level objectives. Example: a one-page charter for a new ERP project signed by the COO.

2. Project management plan. The integrated document that combines all subsidiary plans (scope, schedule, cost, etc.) and defines how the project will be executed. Example: a 60-page plan covering all knowledge areas for a USD 10M programme.

3. Change request. A formal proposal to modify scope, schedule, cost, or other baselines. Example: a change request to add two new features to a software release.

4. Change control board. A group authorised to review and approve change requests. Example: a five-person board meeting fortnightly to triage requests.

5. Configuration management system. A subsystem of the PMIS that tracks deliverables and their versions. Example: an artefact repository with version control for design documents.

6. Lessons learned register. A living document capturing insights as the project progresses. Example: a monthly log of what worked and what did not.

7. Project closure. Formal acceptance of project deliverables and release of resources. Example: a signed acceptance form from the sponsor and an archived project file.

8. Scope. The total work required to deliver a product or service with its specified features and functions. Example: the complete set of features in a new mobile app.

9. Product scope. The features and functions of the product itself. Example: search, login, checkout for a retail app.

10. Project scope. The work that needs to be done to deliver the product. Example: design, build, test, deploy activities.

11. WBS (Work Breakdown Structure). A hierarchical decomposition of project work into smaller, manageable components. Example: a four-level WBS for a construction project.

12. WBS dictionary. A document providing detail about each WBS element. Example: a description of acceptance criteria for each work package.

13. Scope baseline. The approved version of the scope statement, WBS, and WBS dictionary. Example: the version 1.0 baseline locked at the start of execution.

14. Scope creep. Uncontrolled expansion of scope without adjustments to time, cost, or resources. Example: a stakeholder adds features without going through change control.

15. Gold plating. The team adding features beyond what was requested. Example: a developer adds animations the customer never asked for.

16. Requirements traceability matrix. A document linking requirements to deliverables and tests. Example: a spreadsheet linking each requirement to its corresponding test case.

17. Activity. A discrete unit of work to be performed in a project. Example: "Install network cabling on floor 3".

18. Milestone. A significant point or event in a project, typically zero duration. Example: "Phase 1 complete".

19. Critical path. The longest path through a network diagram; determines the shortest possible project duration. Example: a 14-week critical path through a 40-week project schedule.

20. Float (slack). The amount of time an activity can be delayed without delaying the project. Example: a non-critical activity with 5 days of float.

21. Lead. Acceleration of a successor activity. Example: starting testing 3 days before development is fully complete.

22. Lag. Delay of a successor activity. Example: waiting 2 days for concrete to cure before next activity.

23. Crashing. Adding resources to shorten the schedule, usually increasing cost. Example: adding a second developer to compress a coding task.

24. Fast-tracking. Performing activities in parallel that were originally sequential. Example: starting design of phase 2 while phase 1 is still in build.

25. PERT (three-point estimate). Weighted average of optimistic, most likely, and pessimistic estimates. Example: (3+4*5+10)/6 = 5.5 weeks.

26. Schedule baseline. The approved version of the project schedule. Example: the version 1.0 schedule against which performance is measured.

27. Cost baseline. Time-phased budget used to measure and monitor cost performance. Example: a monthly spend curve totalling USD 5M.

28. Contingency reserve. Budget set aside for known risks. Example: 10 percent reserve for identified risks in the risk register.

29. Management reserve. Budget set aside for unknown risks; managed by management, not the project manager. Example: 5 percent reserve held by the executive sponsor.

30. BAC (Budget at Completion). The total budget for the project. Example: USD 5M.

31. AC (Actual Cost). What has been spent to date. Example: USD 2.4M spent through month 6.

32. PV (Planned Value). The budgeted cost of work scheduled. Example: USD 2.5M planned through month 6.

33. EV (Earned Value). The budgeted cost of work performed. Example: USD 2.3M earned through month 6.

34. ROI (Return on Investment). Net benefit divided by cost. Example: 250 percent ROI on a digital transformation programme.

35. NPV (Net Present Value). The present value of future cash flows minus initial investment. Example: NPV of USD 1.8M over five years.

36. Quality. The degree to which a set of inherent characteristics fulfils requirements. Example: an app meeting all specified performance benchmarks.

37. Grade. A category for products with the same functional use but different characteristics. Example: economy vs business class seats on a flight.

38. Cost of quality. All costs incurred to ensure quality, including prevention, appraisal, and failure. Example: USD 50K spent on testing plus USD 30K spent fixing defects.

39. Cost of conformance. Money spent to prevent and find defects. Example: training, audits, testing.

40. Cost of non-conformance. Money spent due to failures. Example: rework, warranty claims, liability.

41. Quality assurance. Process of auditing quality requirements to ensure standards are used. Example: a quarterly audit of the testing process.

42. Quality control. Monitoring specific project results to determine whether they meet standards. Example: inspecting a batch of products against specification.

43. Pareto chart. A bar chart showing causes of problems by frequency, used in root cause analysis. Example: identifying the 20 percent of defect types causing 80 percent of problems.

44. Control chart. A graph showing whether a process is stable and predictable. Example: an SPC chart monitoring fill weights in a manufacturing line.

45. RACI matrix. A chart showing Responsible, Accountable, Consulted, and Informed roles for activities. Example: a matrix listing 20 activities and their RACI assignments across 8 team members.

46. Resource calendar. A calendar showing availability of resources. Example: a calendar showing developer availability minus holidays and vacations.

47. Resource histogram. A bar chart showing time periods and resource use. Example: a graph showing peaks in QA demand during weeks 8 to 10.

48. Resource levelling. Adjusting the schedule to address resource constraints. Example: extending a phase by 2 weeks to avoid double-booking a critical engineer.

49. Resource smoothing. Adjusting activities within their float without changing the end date. Example: shifting a low-priority task to a lighter week.

50. Tuckman ladder. Stages of team development: forming, storming, norming, performing, adjourning. Example: a new team transitioning from storming to norming after 6 weeks.

51. Servant leadership. A leadership philosophy focused on serving the team. Example: a project manager removing blockers and amplifying the team's voice.

52. Co-location. Placing team members in close physical proximity to enhance collaboration. Example: a war room set up for an intensive 12-week phase.

53. Communication channels. The number of possible communication paths in a team; formula n(n-1)/2. Example: 6 people have 15 channels.

54. Push communication. Information sent to recipients (emails, reports). Example: a weekly status report emailed to stakeholders.

55. Pull communication. Information made available for recipients to access. Example: a project dashboard available on the portal.

56. Interactive communication. Real-time two-way communication. Example: a daily stand-up meeting.

57. Active listening. Fully concentrating on what is being said and confirming understanding. Example: paraphrasing a stakeholder's concern back to them.

58. Communications management plan. A document defining how project information will be communicated. Example: a matrix listing each stakeholder, their preferred channel, and the cadence.

59. Stakeholder engagement assessment matrix. A chart comparing current vs desired engagement levels of stakeholders. Example: a matrix showing a sceptical stakeholder targeted to move to supportive.

60. Risk. An uncertain event that, if it occurs, has a positive or negative effect. Example: the risk of a key vendor going out of business.

61. Issue. A problem that has occurred and requires action. Example: an outage in the test environment blocking progress.

62. Risk register. A document containing identified risks. Example: a spreadsheet listing 47 risks with probability, impact, and response.

63. Risk appetite. The amount of uncertainty an organisation is willing to take on. Example: a conservative bank with low appetite for innovation risk.

64. Risk tolerance. The amount of risk an organisation can withstand. Example: an organisation that can tolerate up to USD 500K of unmitigated risk.

65. Risk threshold. The level at which a risk becomes unacceptable. Example: any risk with EMV over USD 100K escalates to steering committee.

66. Qualitative risk analysis. Assessing risks using categories like high, medium, low. Example: a probability and impact matrix.

67. Quantitative risk analysis. Numerically analysing the effect of identified risks. Example: Monte Carlo simulation of project completion dates.

68. EMV (Expected Monetary Value). Probability multiplied by impact. Example: 30 percent probability x USD 100K impact = USD 30K EMV.

69. Risk response strategies (threats). Avoid, transfer, mitigate, accept, escalate. Example: transferring a risk via insurance.

70. Risk response strategies (opportunities). Exploit, enhance, share, accept, escalate. Example: enhancing the probability of an early go-live by adding resources.

71. Residual risk. Risk remaining after responses are implemented. Example: a 5 percent probability remaining after mitigation.

72. Secondary risk. Risk created by a response to another risk. Example: hiring a vendor to mitigate a delivery risk creates a vendor performance risk.

73. Make-or-buy analysis. Decision whether to perform work internally or contract it. Example: choosing to buy a hosting service rather than build a data centre.

74. Statement of work (SOW). A description of the deliverables and services to be provided. Example: a 12-page SOW for a custom software build.

75. RFP (Request for Proposal). A solicitation document used when the approach is unclear. Example: an RFP issued to five consulting firms.

76. RFQ (Request for Quotation). A solicitation document used when the requirement is clear and price is key. Example: an RFQ for standard server hardware.

77. Fixed-price contract. Total price set at contract signing. Example: USD 200K firm fixed price for a website build.

78. Cost-plus contract. Buyer pays seller's actual costs plus a fee. Example: cost-plus-fixed-fee contract for a research engagement.

79. Time and materials. Hybrid contract paying by hours and materials. Example: USD 150 per hour plus reimbursed materials for a renovation.

80. Bidder conference. A meeting with prospective sellers to clarify the procurement. Example: a one-hour Q&A call before proposal submissions.

81. Stakeholder. Any individual or group affected by or affecting the project. Example: customers, employees, regulators, vendors.

82. Stakeholder register. A document identifying stakeholders, their interest, and their influence. Example: a spreadsheet with 35 stakeholders categorised by power and interest.

83. Power/interest grid. A 2x2 matrix categorising stakeholders by power and interest. Example: high power, high interest stakeholders managed closely.

84. Salience model. Categorising stakeholders by power, urgency, and legitimacy. Example: a key regulator identified as having high salience.

85. Engagement levels. Unaware, resistant, neutral, supportive, leading. Example: moving a resistant stakeholder to neutral through targeted communication.

86. Agile. An iterative, incremental approach to delivery emphasising collaboration and adaptation. Example: a Scrum team delivering working software every two weeks.

87. Scrum. An agile framework with sprints, daily stand-ups, and defined roles. Example: a two-week sprint cadence with retrospectives.

88. Sprint. A short, time-boxed iteration. Example: a two-week sprint producing a shippable increment.

89. Product backlog. A prioritised list of features and work. Example: a list of 200 user stories owned by the product owner.

90. Velocity. The amount of work a team completes per sprint. Example: a team averaging 32 story points per sprint.

91. Kanban. A pull-based system with work-in-progress limits. Example: a Kanban board with a WIP limit of 3 in the testing column.

92. Retrospective. A team meeting to reflect and improve. Example: a 60-minute meeting at the end of each sprint.

93. Hybrid. A delivery approach combining predictive and agile elements. Example: predictive infrastructure with agile application development.

94. Definition of done. Shared criteria for considering work complete. Example: code reviewed, tested, documented, and deployed.

95. CV (Cost Variance). EV minus AC; positive means under budget. Example: EV of 2.3M minus AC of 2.4M = -0.1M CV.

96. SV (Schedule Variance). EV minus PV; positive means ahead of schedule. Example: EV of 2.3M minus PV of 2.5M = -0.2M SV.

97. CPI (Cost Performance Index). EV divided by AC; above 1.0 means under budget. Example: 2.3/2.4 = 0.96 CPI.

98. SPI (Schedule Performance Index). EV divided by PV; above 1.0 means ahead of schedule. Example: 2.3/2.5 = 0.92 SPI.

99. EAC (Estimate at Completion). Forecast of total project cost. Example: BAC of 5M divided by CPI of 0.96 = USD 5.2M EAC.

100. TCPI (To-Complete Performance Index). Cost efficiency needed to finish at BAC. Example: (5M-2.3M)/(5M-2.4M) = 1.04 TCPI.

A few additional terms beyond the official 100 that I find essential to round out fluency:

These terms appear constantly in exam questions and real-world discussions.

PMBOK 7 reorganised the project management body of knowledge around eight performance domains. Each is worth understanding briefly:

1. Stakeholders. Activities and functions associated with stakeholders.
2. Team. Activities and functions associated with the people delivering the work.
3. Development approach and lifecycle. Activities and functions related to choosing predictive, agile, or hybrid.
4. Planning. Activities and functions for organising, coordinating, and elaborating delivery.
5. Project work. Activities and functions associated with establishing processes and managing resources.
6. Delivery. Activities and functions associated with delivering scope and quality.
7. Measurement. Activities and functions for assessing project performance.
8. Uncertainty. Activities and functions associated with risk and uncertainty.

These domains are now the structural backbone of how PMI thinks about project work. The older process groups (initiating, planning, executing, monitoring and controlling, closing) still appear but are de-emphasised.

The shift from PMBOK 6 to PMBOK 7 is from a process-centric view to a principles- and outcomes-centric view. The vocabulary above sits inside that broader shift.