PMBOK

PMBOK on one screen — the Eighth Edition, every element

Most people who look up PMBOK want its structure, and the structure has changed twice in four years. Here is the current one, complete: the six principles first, then the seven performance domains with every one of their forty processes. Where a process was renamed from the 6th edition, the old name follows it, because that is the name most people still say out loud. Later sections cite the lines by number.

1. 1.Governance — 9 processes; the only domain in all five focus areas

   1. 1.1Initiate Project or Phase — was Develop Project Charter
   2. 1.2Integrate and Align Project Plans
   3. 1.3Plan Sourcing Strategy — was Plan Procurement Management
   4. 1.4Manage Project Execution — was Direct and Manage Project Work
   5. 1.5Manage Quality Assurance — was Manage Quality
   6. 1.6Manage Project Knowledge
   7. 1.7Monitor and Control Project Performance
   8. 1.8Assess and Implement Changes — was Perform Integrated Change Control
   9. 1.9Close Project or Phase

2. 2.Scope — 6 processes

   1. 2.1Plan Scope Management — its outputs now include the quality management plan
   2. 2.2Elicit and Analyze Requirements — was Collect Requirements
   3. 2.3Define Scope
   4. 2.4Develop Scope Structure — was Create WBSWBSWork Breakdown Structure — the project’s scope as a treeA tree of everything a project will deliver, broken down until each piece is small enough to estimate and give to one owner — and, by definition, nothing the project will not deliver. Its children must add up to exactly their parent, which is what makes it a scope boundary rather than a task list.Full article →All terms
   5. 2.5Monitor and Control Scope — was Control Scope; now includes measuring the quality of deliverables
   6. 2.6Validate Scope

3. 3.Schedule — 3 processes; the 6th edition had six

   1. 3.1Plan Schedule Management
   2. 3.2Develop Schedule
   3. 3.3Monitor and Control Schedule — was Control Schedule

4. 4.Finance — 4 processes; was Cost

   1. 4.1Plan Financial Management — was Plan Cost Management
   2. 4.2Estimate Costs
   3. 4.3Develop Budget — was Determine Budget
   4. 4.4Monitor and Control Finances — was Control Costs

5. 5.Stakeholders — 7 processes; communications now live here

   1. 5.1Identify StakeholdersStakeholderanyone the outcome affectsAnyone whose work or results are affected by what is being built, whether or not they can decide anything about it. The distinction that matters in practice is between those who are consulted and those who can say no.All terms
   2. 5.2Plan Stakeholder Engagement
   3. 5.3Plan Communications Management
   4. 5.4Manage Stakeholder Engagement
   5. 5.5Manage Communications
   6. 5.6Monitor Stakeholder Engagement
   7. 5.7Monitor Communications

6. 6.Resources — 5 processes

   1. 6.1Plan Resource Management
   2. 6.2Estimate Resources — was Estimate Activity Resources
   3. 6.3Acquire Resources
   4. 6.4Lead the Team — was Develop Team and Manage Team, two processes
   5. 6.5Monitor and Control Resourcing — was Control Resources

7. 7.Risk — 6 processes

   1. 7.1Plan Risk Management
   2. 7.2Identify Risks
   3. 7.3Perform Risk Analysis — was the qualitative and the quantitative analysis, two processes
   4. 7.4Plan Risk Responses
   5. 7.5Implement Risk Responses
   6. 7.6Monitor Risks

8. 8.Five focus areas — the old process groups, renamed

   1. 8.1Initiating — authorising the project, or the next phase of it
   2. 8.2Planning — how the scope, time, money, people and risks will be handled; about half of the forty processes
   3. 8.3Executing — doing the work, and leading the people doing it
   4. 8.4Monitoring and Controlling — comparing what happens with the plan and deciding on changes; it runs alongside the other four throughout
   5. 8.5Closing — acceptance, handover and lessons, for the project or for a phase

Which PMBOK someone means — three editions, three different documents

PMI has published the guide since 1996. For twenty years the editions kept one shape — process groups across knowledge areas — while the number of processes drifted from 37 to 49. Then it changed shape twice, so three editions are in use at once: organisations, contracts and job descriptions still run on the 6th, a generation of certificate holders learned the 7th, and the 8th is what PMI publishes now.

One volume, two documents. Since the 7th edition the book holds The Standard for Project Management, the normative part, together with the Guide, which explains. PMI calls the 8th edition “the most data-driven and community-informed update in the guide’s history”, built on “more than 48,000 data points” from practitioners. When someone says “PMBOK says”, it is worth asking which edition, and which of the two documents, because only one of them is the standard.

The exam is not the book

Many readers arrive here on the way to the PMP, PMI’s Project Management Professional certification. From July 2026 the exam follows a new content outline: People 33%, Process 41%, Business Environment 26%. About 40% of the questions represent predictive approaches, and the rest are divided between agile and hybrid ones. PMI’s outline says plainly that “there are noticeable differences between this updated PMP Certification Exam Content Outline and A Guide to the Project Management Body of Knowledge”. Study from the outline first; the guide is a reference for it, not its syllabus.

Six principles — what each asks of you on an ordinary Monday

A principle is only useful if it changes a decision. Here is each of the six on one project — the retailer replacing its online shop from the WBS and PRINCE2 pages, nine months at a fixed pricefixed priceagreed scope, agreed sumA contract where an agreed scope is delivered for an agreed sum, so the supplier carries the cost of anything that takes longer than planned. That is why fixed-price work comes with the strictest change control: every change to the scope is a commercial event, not just a planning one.All terms — and the decision it changed.

• 1. Adopt a holistic view

  The new shop changes how the warehouse receives orders, how customer service works and how finance reconciles payments. A plan that saw only the website would have missed three teams; this one put the reconciliation report, WBS 5.3, in scope.

• 2. Focus on value

  The value is a cheaper shop to run and a conversion rate from 2.1% to 2.4%, not thirty-one work packages. Benefits reviews at three and six months after launch are where the principle is actually tested.

• 3. Embed quality

  Each work package carries its own tests, and the checkout’s speed limit — under 2 seconds at three times peak load — is checked every sprint, not once in a test phase at the end.

• 4. Be an accountable leader

  One named person, the commercial director, owns the business case. The project manager reports the forecast every fortnight, the bad fortnights included — the 7th edition’s stewardship and leadership principles, joined into one.

• 5. Integrate sustainability

  Product pages go from 4.2 MB to under 1.5 MB, and the old shop’s racks are switched off within 30 days of launch — written down and measured like time and cost. New as a principle in 2025.

• 6. Build an empowered culture

  The payments team lead decides how card payments are built and can stop a release on their own judgement; the agency’s teams choose their own practices inside each work package.

Three of the 7th edition’s principles have no namesake among the six, and each lives on one level down. Tailoring is a section of its own, the subject of the tailoring section below. Optimising risk responses lives in the Risk domain, group 7 of the hook. Engaging stakeholders lives in the Stakeholders domain, group 5.

Seven domains and forty processes — how the structure fits together

A performance domain is an area of practice a project has to keep healthy. The forty processes live inside the domains, and each process also belongs to one of five focus areas — the 6th edition’s process groups under a new name. The two cut across each other: a domain says what is being looked after, a focus area says at what point in the life of a project or phase the work concentrates.

Focus areas are not phases, and reading them as phases is the oldest misreading of PMBOK, carried over intact from the process groups. Monitoring and Controlling runs the whole time, beside the others. A project with three phases passes through all five focus areas in each of them, which is why the first and last processes are called Initiate Project or Phase and Close Project or Phase.

The arithmetic is worth doing once, because it shows where the forty came from. The 6th edition had 49. Schedule lost three processes, quality and procurement two each, and two pairs were merged into one — the two risk analyses at 7.3, and developing and managing the team at 6.4. That is nine, and 49 minus nine is forty. Quality did not vanish with its area. PMI’s own errata shows Plan Scope Management producing the quality management plan, and Monitor and Control Scope defined as including “measuring the quality of the deliverables”.

Every domain ends in a check

The most practical addition in the 8th edition is easy to miss: each domain closes with a table of target outcomes and a check that shows whether each was met. The Scope domain’s, Table 2-6, measures scope creep as unplanned deliverables divided by all deliverables, and requirements stability as unchanged requirements divided by all requirements, both as percentages. On the shop project, three deliverables were added after the baseline — a second delivery provider’s prices, a printable order page and a finance export — so scope creep was 3 of 34, or 8.8%. Of 124 requirements in the baseline, 109 never changed: a stability of 87.9%.

The renamed processes carry the agile reading with them. The errata’s definition of Develop Scope Structure, line 2.4, says that “in agile projects, this effort corresponds to the decomposition of the product backlog”, where work items can be broken down into epicsepica large backlog itemA large piece of work that is split into features or stories before anyone builds it, best written as a bet with a hypothesis and a condition that closes it. Its size depends on whose vocabulary is in use — anything above a story in Jira, a portfolio investment with a business case in SAFe — so check before comparing two epics.Full article →All terms, features, and user storiesuser storya need told from the user’s sideA short description of something a user needs and why, usually "As a …, I want …, so that …", written as a promise of a conversation rather than a specification. Its weakness is its strength: without acceptance criteria agreed in that conversation, two people will build two different things from one card.Full article →All terms — the hierarchy the Epics, Features, Tasks page takes apart. The WBS and the backlog are now one process with two dialects.

Tailoring — forty processes, one project

In the 7th edition tailoring was a principle. In the 8th it is a section, and PMI’s description of it is one line: “Learn how to adapt practices, tools, and techniques to fit your team, organization, and environment.” What that means in practice is a decision for every process: do it formally, do it lightly, fold it into another document, or leave it to someone else. Here is the shop project’s record, all forty decisions.

The count is seventeen processes done formally, fourteen lightly, six folded into another document and three left to the supplier. None was skipped by accident. Each decision was taken once, at initiation, written into the plan with its reason, and could be reopened at a stage boundary. That last part is what separates tailoring from neglect: neglect has no record.

PMBOK next to PRINCE2 and Scrum

These three are presented as rivals and mostly are not. Each answers a different question, and an organisation using all three is not being indecisive: it is using a body of knowledge, a governance method and a delivery framework, which are three different things.

The shop project used all three without contradiction. A PRINCE2 board authorised stages and held the tolerances. PMBOK’s processes supplied the techniques the board assumed someone knew — the estimate behind the fixed price at 4.2, the stakeholder map at 5.1, the risk responses at 7.4. And the agency’s teams ran Scrum inside each work package. Arguing about which of the three is “better” usually means two people have different problems.

Phoenix — a project structure mistaken for governance

The Government of Canada’s Phoenix pay system is the clearest recent case of every principle missing at once, and its audit is unusually exact. Public Services and Procurement Canada was to centralise pay for 46 departments in a new pay centre in Miramichi and move all of government onto new pay software. The budget was $310 million, $155 million of it to build the software. The expected saving was about $70 million a year from 2016–17, mainly because pay advisors were to handle 400 employee files each instead of 184.

The warnings existed. A Gartner review commissioned by the Treasury Board Secretariat, delivered on 11 February 2016, named one critical risk: Phoenix might not pay employees accurately and on time, because it had not been fully tested. It recommended a gradual rollout and running the old system in parallel. Phoenix went live for 34 departments on 24 February 2016 and for the remaining 67 on 21 April. By 30 June 2017 more than $520 million in pay was outstanding because of errors, and 494,500 pay requests were waiting.

The Auditor General’s conclusion was blunt: “The building and implementation of Phoenix was an incomprehensible failure of project management and oversight.” The sentence that matters most for this page comes later. The department had committees, chairs and reporting lines, and believed that was enough: “Public Services and Procurement Canada considered the Phoenix project management committees and structure it put in place to be governance and oversight. In our view, this was in fact just a project management structure.” Governance is the part that can say no to the project, and it has to reach the decision-maker by a path the project does not control.

Why averages hide projects like Phoenix

Phoenix is not a freak. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects for the Harvard Business Review in 2011. The average cost overrun was 27%, which sounds survivable. But “fully one in six of the projects in the sample was a Black Swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%”. A 2022 study of 5,392 IT projects by Flyvbjerg and colleagues found that overruns follow a power law: many small ones and a fat tail of extreme ones, which a plan built on averages will grossly underestimate.

Where it degrades — and what a body of knowledge cannot do

In practice PMBOK shows up in two places: as the vocabulary of a PMOPMOProject Management Office — the office that sets project standardsA unit that sets project-management standards across an organisation, collects reporting from its projects and sometimes employs the project managers. Its value depends on which of those it does: a PMO that only gathers status reports adds a layer without adding a decision.All terms, and as the reference behind the PMP. Knowing it matters most at that boundary — an engineering team running Scrum inside a programme governed by a PMO needs someone who can translate “sprint goal” into the PMO’s language without either side feeling translated at. It degrades in predictable ways.

• Quoting one edition as if it were the current standard — the five process groups in 2021, the twelve principles in 2026.
• Reading focus areas, like process groups before them, as project phases.
• Running all forty processes formally on a three-month project, which is governance theatre.
• Treating the principles as a compliance checklist to be ticked rather than reasoned from.
• “We tailored it” as the answer to why something necessary was skipped, with no record of the decision.
• A dashboard built from the first printing’s inverted formulas.
• Committees and reporting lines presented as governance, with no path to the decision-maker the project does not control.
• PMBOK vocabulary used to relabel an agile process without changing how decisions are made.

When to use it

Related pages

• ManagementPRINCE2PRINCE2 is a structured method for governing projects, built around one question a project must keep answering: is it still worth funding? It says almost nothing about how the work gets done and a great deal about who may decide that it continues. The page opens with one project set up the PRINCE2 way, finished, then covers what the method is, its seven principles, seven practices and seven processes, tolerances and exceptions, two projects it exists to stop, and where it degrades.
• ManagementRisk ManagementRisk management is deciding in advance what could go wrong, which of those things is worth spending money on now, and who will notice if one starts happening. A risk is not a problem yet, and that is the entire reason it is cheap to deal with. The page opens with the whole map — seven groups and twenty-eight lines to check your own project against — then covers how to size a risk without faking precision, the four responses, the practices that actually move the number, and six public failures with the control that was missing from each.
• ManagementEstimation MethodsEstimation methods in IT are the units a team uses to predict how much work something will take: story points, man-days, hours or T-shirt sizes. They are not interchangeable. Each one moves the step that turns effort into a date to a different place and a different person, and each fails in its own recognisable way. The page opens with all four side by side and a table of which one fits which decision, then covers why an honest estimate is a range rather than a number, each unit in depth, six documented estimates that went wrong, and where estimating turns into theatre.