PMBOK Guide, Eighth Edition: PMBOK Guide, Eighth Edition – Tutorial (about 60 minutes)

The PMBOK Guide (A Guide to the Project Management Body of Knowledge) is the Project Management Institute's main reference on how projects are managed well. Project managers, sponsors, PMO staff, engineers who lead delivery work and people preparing for PMI certifications use it as a shared vocabulary and a checklist of good practice, whether their projects are predictive, agile or a mix of both. After this tutorial you will be able to explain how the Eighth Edition is organised, apply its principles and performance domains to a real project, and tailor its practices sensibly instead of following them mechanically.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is the PMBOK Guide, Eighth Edition, published by the Project Management Institute (PMI), a not-for-profit professional association based in the United States. PMI launched it in November 2025. Like the Seventh Edition, the book brings together The Standard for Project Management and the Guide itself; together they set out principles, performance domains, focus areas, processes and tailoring guidance. It replaces the Seventh Edition (2021). No newer edition has been announced. Status verified 2026-10-29 against the Wikipedia article on the PMBOK Guide, which cites PMI's ProjectManagement.com launch article of 13 November 2025 (PMI's own pages block automated readers, so they could not be read directly).

Who it is for: new and aspiring project managers, team leads, product owners who work with project governance, sponsors and steering-group members, PMO analysts, business analysts, and engineers or consultants who keep meeting PMBOK vocabulary in their organisation.

Prerequisites: none. Having worked on any kind of project helps, but every term is explained when it first appears.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the four diagrams, then spend the rest of the hour on the reflection questions before you attempt the 25-question knowledge check.

Learning objectives:

You will be able to explain what the PMBOK Guide is, who owns it, and why the Eighth Edition looks different from the editions many people learned.
You will be able to name the six principles and the seven performance domains and describe what each one asks of a project team.
You will be able to explain how the five focus areas, the processes and tailoring fit together.
You will be able to apply the guide to a realistic project, from the business case to closure, using a hybrid delivery approach.
You will be able to describe how people and organisations are assessed against PMBOK ideas, and why there is no organisational certificate.
You will be able to relate the PMBOK Guide to ISO 21502, PRINCE2, Scrum and PMI's program and portfolio standards.

Lesson 1 – Origins, purpose and scope

Why a body of knowledge?

Projects existed long before anyone wrote a guide about them, but for most of the twentieth century each company, government agency and engineering firm described project work in its own way. One organisation talked about "work packages", another about "tasks"; one tracked "contingency", another "management reserve". When people moved between employers, or when two companies worked on the same contract, a great deal of time went into translating. PMI, founded in 1969, set out to describe the knowledge that experienced practitioners shared, so that the profession had a common language. A 1983 white paper from a PMI committee on ethics, standards and accreditation was reworked over the following years and led by the first PMBOK Guide in 1996.

The word "guide" matters. The body of knowledge itself is everything the profession knows: books, research, case studies, lessons learned and individual experience. The PMBOK Guide is a structured summary of the subset that is generally recognised as good practice on most projects most of the time. It is not a method you install, and it does not tell you exactly which documents to produce on a given Tuesday. It describes what good project management pays attention to and leaves the "how much" to the people running the project.

From processes to principles, and back to a balance

For its first two decades the guide grew around processes. By the Sixth Edition (2017) it described 49 processes arranged in a grid of ten knowledge areas (such as scope, schedule, cost and risk) and five process groups (initiating, planning, executing, monitoring and controlling, and closing). Each process listed inputs, tools and techniques, and outputs, often shortened to ITTOs. That detail helped beginners but encouraged a box-ticking style that did not suit agile teams or fast-changing work.

The Seventh Edition (2021) made a sharp turn. It replaced the process grid with twelve principles and eight performance domains and focused on outcomes and value rather than prescribed steps. Many experienced practitioners welcomed the flexibility. Many others, especially people new to the field and trainers, found it abstract: it told you what to care about but gave little practical structure.

The Eighth Edition tries to keep the strengths of both. It condenses the principles to six, regroups the work into seven performance domains, brings back a process view arranged by five focus areas, and keeps a strong section on tailoring. You can think of it as "principles to guide judgement, plus processes to give structure, plus tailoring to make them fit".

A new emphasis: projects as investments

The most important idea running through the Eighth Edition is value. A project is described as a temporary initiative, set in a unique context, that is undertaken to create value. That is a shift from older wording, which stressed creating a unique product, service or result. The difference is practical. Under the older view a project that delivered the agreed product on time and on budget was a success. Under the new view, a project is an investment, and delivering an output nobody uses is not success, however tidy the schedule looked. This links the project manager's daily decisions to the business case that justified spending the money in the first place.

Scope of the guide

The PMBOK Guide covers the management of individual projects. Managing a group of related projects to achieve shared benefits is the subject of PMI's separate program management standard, and choosing and balancing a whole collection of initiatives belongs to its portfolio management standard. The guide applies to any industry and to any delivery approach: predictive (plan the work in detail up front), adaptive (plan in short cycles and adjust, as agile teams do) or hybrid (a combination). It is published in several languages and is one of the best-known project management references worldwide.

Lesson 2 – Key concepts and vocabulary

PMBOK vocabulary is used in job descriptions, contracts and steering meetings, so it pays to know it precisely. The terms below are explained in our own words.

Project – a temporary initiative with a definite start and end, carried out in a unique context to create value. "Temporary" refers to the effort, not to the result: a bridge lasts for decades even though the project that built it ends.
Value – the worth, importance or usefulness of something to the people who fund or use it. Value can be financial, social, environmental or operational, and it is often realised after the project closes.
Output, outcome and benefit – an output is what the project produces (a new app); an outcome is the change that results when people use it (customers book online); a benefit is the measurable gain that follows (fewer call-centre hours).
Stakeholder – any person, group or organisation that can affect, be affected by, or believe it is affected by the project. Perception counts: a community that thinks a project threatens it is a stakeholder even if engineers disagree.
Principle – a fundamental norm or value that guides behaviour and judgement. Principles do not tell you what to do step by step; they tell you what a good decision should respect.
Performance domain – a group of related activities that are critical for delivering a project effectively, such as scope or risk. Domains interact constantly; they are not sequential stages.
Focus area – one of five lenses on the project's journey (initiating, planning, executing, monitoring and controlling, closing) that group the processes by the kind of attention they need. They replace the label "process groups" used in earlier editions.
Process – a systematic series of activities aimed at producing a result, for example creating a schedule or identifying risks. In the Eighth Edition, each process sits in one domain and one focus area.
Tailoring – deliberately adapting the approach, governance, processes and artefacts to suit the project's context. Tailoring is expected, not a sign of weakness.
Development approach – the way the product is created and evolved: predictive, adaptive (iterative or incremental) or hybrid.
Life cycle – the series of phases a project passes through from start to finish, for example feasibility, design, build, test, deploy and close.
Baseline – an approved version of a plan (scope, schedule or cost) used for comparison. Changes to a baseline go through formal change control.
Work breakdown structure (WBS) – a hierarchical decomposition of the total scope into smaller, manageable deliverables. Its lowest level is the work package.
Value breakdown structure – a newer idea in the Eighth Edition's glossary: decomposing the value a project should create into contributing parts, so teams can see which work drives which value.
Critical path and critical path drag – the critical path is the longest chain of dependent activities, which sets the shortest possible project duration. Drag measures how much one critical activity is lengthening the whole project; drag cost puts a money value on that delay.
Governance – the framework of authority, decision rights, oversight and accountability within which the project operates.
Models, methods and artefacts – models are thinking tools (for example a leadership or change model); methods are means of achieving an outcome (for example a retrospective or Monte Carlo analysis); artefacts are templates, documents or outputs (for example a risk register or burndown chart).

Two vocabulary habits help beginners. First, separate "what we produce" from "why we produce it": outputs are not value until someone benefits. Second, separate a domain (an area of concern that is always active) from a focus area (where the project is in its journey). Most confusion about the Eighth Edition comes from mixing those two ideas.

Lesson 3 – Structure of the Eighth Edition

The book has a clear layered structure. Understanding the layers is the fastest way to use it, because each layer answers a different question.

Figure 1 – How the layers of the Eighth Edition fit together: principles guide the domains, domains and focus areas organise the processes, and tailoring turns them into a project-specific way of working that creates value.

The six principles

At the top of the structure are principles. The Eighth Edition has six, down from twelve in the Seventh Edition: ideas that earlier stood as separate principles were consolidated into fewer, broader statements. In our own words:

Adopt a holistic view. See the project as a system inside a larger organisation and environment. A change in one place (a scope addition) ripples into others (schedule, cost, risk, team load), and the project itself affects the business around it.
Focus on value. Keep asking whether the work still contributes to the outcomes and benefits that justified it. Re-check the business case when conditions change, and be willing to change course or stop.
Embed quality into processes and deliverables. Build quality in from the start through clear acceptance criteria, sound processes and early feedback, rather than relying on inspection at the end.
Be an accountable leader. Leadership is shown by anyone on the team, not only the manager. Accountable leaders take ownership of decisions, act ethically, communicate honestly and look after the people and resources entrusted to them.
Integrate sustainability within all project domains. Consider environmental, social and economic effects over the whole life of the result, not just during delivery. Sustainability is treated as part of every domain, not as a separate checklist.
Build an empowered culture. Create an environment where people have the information, authority and psychological safety to contribute, raise problems early and make decisions at the right level.

Figure 2 – The six principles of the Eighth Edition, each with the core idea it asks a project team to respect.

The seven performance domains

The Guide groups project work into seven performance domains. Compared with the old ten knowledge areas, some topics were merged and some renamed:

Governance – how the project is authorised, directed, integrated and overseen: the charter, the project management plan, decision rights, change control, phase gates and closure. Much of what earlier editions called integration management lives here.
Scope – defining and managing what the project will and will not deliver: requirements, scope statements, backlogs, the WBS, and validating deliverables with stakeholders.
Schedule – planning and controlling timing: activities, dependencies, estimates, the critical path, iterations and release plans, and tracking progress against them.
Finance – everything about money: cost estimates, budgets, funding limits, reserves, financial performance measurement such as earned value, and links back to the business case. The name signals a wider view than "cost" alone.
Stakeholders – identifying, understanding and engaging the people the project affects, including planning and delivering communication. Communication is treated as a means of engagement, not as a separate domain.
Resources – obtaining and managing the people, equipment, materials, facilities and services the project needs, including those acquired from outside suppliers, and developing the team.
Risk – handling uncertainty: identifying threats and opportunities, analysing them, planning responses, and watching for new risks as the project evolves.

Notice what is not a separate domain. Quality is a principle that runs through every domain. Communication sits inside stakeholder engagement. Team topics are part of resources and of the culture principle. This reflects the book's holistic stance: the domains are lenses, and real work touches several of them at once.

Focus areas and processes

The five focus areas (initiating, planning, executing, monitoring and controlling, closing) will look familiar to anyone who studied the older process groups. They describe the kind of attention a piece of work needs, not rigid phases. A large project may pass through all five focus areas in each phase, and an agile team cycles through planning, executing and monitoring every iteration. The processes are arranged in a matrix: each process belongs to one performance domain and one focus area. The edition describes around forty processes, fewer than the 49 of the Sixth Edition, and presents them as a toolkit rather than a mandatory sequence.

Tailoring, models, methods and artefacts

A substantial part of the book explains tailoring: how to choose a development approach, how much governance a project needs, which processes to combine or skip, and how to adjust artefacts. Another part catalogues widely used models, methods and artefacts, from stakeholder maps and risk registers to burn charts and earned value.

Lesson 4 – How it works in practice

Start from context, not from the book

The most common beginner mistake is to open the guide and start producing every artefact it mentions. The intended use runs the other way. You begin with the context: what value is expected, how uncertain the requirements are, how much regulation applies, how experienced the team is, how large and risky the work is, and what the organisation's own policies demand. Then you choose an approach and tailor the domains and processes to that context.

A simple test helps. For each process or artefact you consider, ask three questions: what decision or risk does this support, who will use it, and what is the lightest form that still does the job? If nobody can answer the first two, leave it out or merge it with something else.

The focus areas across a project

Figure 3 – The five focus areas as a loop: monitoring and controlling feeds back into planning and executing until the work is accepted and the project or phase closes.

Initiating work establishes why the project exists and who has authority. Typical results are a business case (often prepared by the sponsor), a project charter that names the project manager and sets high-level objectives, and an initial list of stakeholders. Under the value principle, the charter should state the expected outcomes and benefits, not only the deliverables.

Planning work chooses the development approach and life cycle and builds just enough plan to proceed. On a predictive project that means a detailed scope baseline with a WBS, a schedule with dependencies and a critical path, a budget, a risk register and a communication approach. On an adaptive project it means a product vision, a prioritised backlog, a release roadmap and an iteration rhythm. Hybrid projects mix both: for example, a fixed-date hardware delivery planned predictively alongside software features delivered in iterations.

Executing work carries out the plan: building deliverables, managing the team, buying goods and services, engaging stakeholders and implementing risk responses. Quality is built in through agreed standards, peer reviews, automated tests or inspections at the point of work.

Monitoring and controlling work compares what is happening with what was intended and acts on the difference. Typical tools include variance analysis, earned value measures, burn charts, risk reviews and change control. The result is either corrective action (fix the execution) or a re-plan (change the plan through the proper decision route).

Closing work confirms acceptance, hands the result over to operations, releases resources, closes contracts, records lessons learned and archives information. For value-focused projects, closing also confirms who will measure the benefits after the project ends.

Roles

The guide is deliberately light on job titles because organisations differ. The roles you will typically meet are the sponsor, who champions the project, provides funding and owns the business case; the project manager, who leads the team and is accountable for achieving the objectives; the project team, which does the work and, under an empowered culture, shares many leadership tasks; a steering group or governance board, which takes decisions above the project manager's authority; and, in adaptive work, a product owner who prioritises the backlog for value. A project management office (PMO) may provide standards, support, reporting and assurance across projects.

Measuring performance

The Finance and Schedule domains rely on a few measures every practitioner should understand. Earned value management (EVM) compares three numbers at a point in time: planned value (PV, the budgeted cost of work scheduled so far), earned value (EV, the budgeted cost of work actually completed) and actual cost (AC, what that work really cost). The cost performance index CPI = EV / AC and the schedule performance index SPI = EV / PV. A CPI below 1.0 means you are getting less work per unit of money than planned; an SPI below 1.0 means less work has been completed than scheduled. Adaptive teams often use velocity, burn-up charts and cycle time instead, and the guide treats all of these as valid if they support decisions.

Critical path drag is a useful refinement. If a critical activity takes ten days and a parallel path has only four days of float, then shortening that activity can save at most four days before the other path becomes critical: its drag is four days. Drag tells you where speeding up will really shorten the project, and drag cost tells you what each day of that delay is worth, which helps when deciding whether to pay for extra resources.

Governance and change

Because projects are investments, the guide expects clear decision rights. Small changes inside agreed tolerances can be handled by the team; changes to baselines, value or risk appetite go to whoever holds that authority. On adaptive projects much change is absorbed through backlog reprioritisation, but decisions that alter cost, date or expected benefit still go through governance. The goal is not bureaucracy; it is making sure the right people decide with the right information.

Lesson 5 – Assessment, certification and compliance

No certificate for organisations

The PMBOK Guide is a guide and standard of good practice, not a management-system standard with auditable requirements. There is no accredited scheme that certifies an organisation as "PMBOK compliant", and claims of that kind should be treated with caution. An organisation can say that its project method is aligned with or based on the PMBOK Guide, and support the claim with a mapping between its own processes and the guide's domains and principles.

Certification of individuals

PMI certifies people, not organisations. Its best-known credentials are the Project Management Professional (PMP) for experienced project managers and the Certified Associate in Project Management (CAPM) for people early in their careers; PMI also offers credentials in agile, risk, scheduling, program and portfolio management, among others. These examinations are built from published exam content outlines that describe tasks practitioners perform. The PMBOK Guide is one important reference for them but not the only one, so candidates should always study the current outline for their exam rather than assume the book alone defines it. Eligibility rules, fees and exam content change over time and are published by PMI; check them there before planning a certification.

Assessing how well an organisation applies the guide

Organisations that want to measure their project capability usually combine several techniques:

Method mapping – compare the internal project method with the six principles and seven domains and record gaps, for example "no structured stakeholder analysis" or "benefits never tracked after closure".
Project health checks and audits – an internal PMO or independent reviewer samples projects and checks the evidence: is there a charter with stated value, a risk register that is actually updated, a change log, a lessons-learned record?
Maturity models – frameworks such as PeopleCert's P3M3 rate capability on a scale, which helps plan improvement over several years. PMI's own Organizational Project Management Maturity Model (OPM3) was used the same way, but PMI has retired it, so you will mostly meet it in older assessments.
Outcome measures – the share of projects that deliver their expected benefits, forecast accuracy, stakeholder satisfaction and how quickly problems are escalated. Because the Eighth Edition centres on value, outcome measures matter more than artefact counts.

Where compliance obligations come from

Contracts and public procurement rules sometimes require suppliers to use "a recognised project management methodology" and name the PMBOK Guide, PRINCE2 or ISO 21502 as examples. In those cases the evidence buyers look for is usually certified staff plus a documented method that maps to the named reference. Regulated sectors such as medical devices, aviation or pharmaceuticals add their own process requirements on top; the PMBOK Guide does not replace them, but its risk, quality and governance practices help meet them.

Lesson 6 – Worked example: a warehouse system replacement

To tie the lessons together, follow a fictional company through one project. Northbridge Logistics runs six regional warehouses. Its warehouse management software is out of vendor support, picking errors are rising and seasonal peaks cause overtime costs. The board approves a project to replace the system.

Figure 4 – The Northbridge project as an investment: a business case leads to hybrid delivery, a pilot and a rollout, and measured benefits feed the next investment decision.

Step 1 – Frame the value (initiating; governance and finance domains)

The sponsor, the operations director, writes a business case: reduce picking errors by a target percentage, cut peak-season overtime, and remove the risk of running unsupported software. The charter names Priya as project manager, sets a budget ceiling and a target date before the next peak season, and lists the expected benefits with their owners in operations. A steering group (operations director, finance lead, IT director) is given authority over baseline changes. Applying the holistic view principle, Priya also notes knock-on effects: the transport planning system reads warehouse data, so it is in scope as an interface even though it is not being replaced.

Step 2 – Choose and tailor the approach (planning; all domains)

Some work is predictable: the vendor contract, server environments, data migration rehearsals and site training have fixed dependencies and a hard deadline. Other work is uncertain: how pickers should use handheld scanners in each warehouse layout is best discovered by trying it. Priya therefore tailors a hybrid approach. Contract, infrastructure and rollout are planned predictively with a WBS, a schedule and a critical path. Workflow configuration runs in two-week iterations with a product owner from operations and a prioritised backlog. She drops a separate communications plan document and instead adds a stakeholder engagement section to the project plan, because the organisation is small and the audiences are few.

Step 3 – Engage stakeholders (stakeholders domain)

The stakeholder analysis shows that warehouse supervisors have high influence and low enthusiasm, since the last system change disrupted their bonuses. Priya invites two supervisors into the iteration reviews and agrees with HR that error-rate targets will not affect bonuses during the pilot month. Union representatives receive early briefings on scanner ergonomics. This is the empowered culture principle in action: people who will live with the result shape it.

Step 4 – Manage risk and resources (risk and resources domains)

The risk register includes threats (data migration quality, vendor staff availability, peak-season clash) and an opportunity (the vendor offers a discounted route-optimisation module that could cut walking distance). Responses include two full migration rehearsals, a contractual clause guaranteeing named vendor consultants, and a decision point at the pilot review on whether to exploit the opportunity. Resources include internal super-users released from shifts for training, rented handheld devices for the pilot, and the vendor team acquired through a competitive tender.

Step 5 – Build quality in (quality principle; scope domain)

Each backlog item has acceptance criteria written with supervisors, for example "a picker can complete a multi-line order with no more than one screen change per line". Automated tests check interface messages to the transport system on every build. Instead of a single acceptance test at the end, the pilot warehouse runs the new system on one shift for two weeks before going live fully.

Step 6 – Monitor and control (schedule and finance domains)

At month four the earned value report shows EV of 400,000, PV of 450,000 and AC of 420,000 (in the company's currency). SPI is about 0.89 and CPI about 0.95: the project is behind schedule and slightly over cost. The critical path runs through data migration. Analysis shows the migration rehearsal has five days of drag, and each day of delay to go-live costs roughly the price of extra overtime in peak season. The steering group approves paying for an additional data specialist, because the drag cost is clearly higher than the extra fee. The decision is recorded in the change log and the schedule baseline is updated.

Step 7 – Close and realise value (closing; governance and finance domains)

After the pilot and rollout, the project closes the vendor contract milestones, hands support to the IT service desk, releases the rented devices and holds a lessons-learned session. Benefits measurement continues for twelve months under the operations director, who reports error rates and overtime to the board. A sustainability review also notes that the old servers are being recycled through a certified provider and that paper pick lists, previously about a box of paper per site per day, are gone.

The worked example shows the guide working as intended: principles shaped the decisions, the seven domains made sure nothing important was forgotten, the focus areas gave a rhythm, and tailoring kept the paperwork proportional.

Lesson 7 – Relationship to other standards and frameworks

The PMBOK Guide rarely stands alone. Organisations combine it with other references, and the combinations work best when you understand what each one is for.

Reference	Owner and type	Main focus	How it relates to the PMBOK Guide
ISO 21502	ISO; international guidance standard	Method-neutral guidance on managing projects, with integrated and management practices	Very similar territory at a higher level of abstraction; PMBOK practices map well onto it, and organisations often cite both
PRINCE2 7	PeopleCert; proprietary method	A defined method with principles, practices, processes and roles, strong on governance by a project board	PRINCE2 says who decides and when; the PMBOK Guide supplies a broader set of techniques. Many organisations use PRINCE2 governance with PMBOK techniques
Scrum Guide	Ken Schwaber and Jeff Sutherland; lightweight framework	Delivering complex products in short sprints with three accountabilities and fixed events	Scrum can be the adaptive development approach inside a PMBOK-tailored project; the guide treats it as one option among several
Standard for Program Management and Standard for Portfolio Management	PMI; companion standards	Coordinating related projects for shared benefits; selecting and balancing investments	Sit above the PMBOK Guide: they decide which projects exist and how their benefits combine
Process Groups: A Practice Guide	PMI; practice guide	A process-by-process view similar to the Sixth Edition	Published to support people who missed the process detail removed in the Seventh Edition; the Eighth Edition now reintegrates much of that view
P3M3 (and the retired OPM3)	PeopleCert (P3M3); PMI (OPM3, no longer maintained); maturity models	Rating an organisation's capability to manage projects, programmes and portfolios	Used to assess and improve how well an organisation applies references such as the PMBOK Guide

A useful way to remember the relationships: ISO 21502 and the PMBOK Guide describe what good project management covers; PRINCE2 prescribes a specific way of organising it; Scrum and other agile frameworks describe how teams build products under uncertainty; and program, portfolio and maturity standards look at the level above the single project. They complement rather than compete with each other, and the Eighth Edition's tailoring section explicitly expects practitioners to combine practices from several sources.

Some organisations also link project practice to service management (for example ITIL) for the handover into operations, and to quality management systems such as ISO 9001 when projects must follow certified quality processes. In those cases the PMBOK Guide supplies the project vocabulary while the other standards set requirements for the operational side.

Common pitfalls and best practices

Pitfalls seen when organisations adopt the PMBOK Guide:

Treating the guide as a mandatory checklist. Producing every artefact on every project wastes effort and makes people cynical about project management.
Measuring success only by time, cost and scope. A project can hit all three and still deliver no value if the outcome never materialises.
Mixing up domains and focus areas. Treating "risk" as something done once during planning, instead of a domain that stays active until closure, leaves the project blind to new threats.
Studying an old edition for a current exam or method. Teams sometimes train staff on Sixth Edition process tables while the organisation's method and the certification outlines have moved on.
Claiming organisational "PMBOK certification". No such accredited scheme exists; buyers who check will lose trust.
Ignoring sustainability and culture as "soft" topics. In the Eighth Edition they are principles, and weak culture usually shows up later as hidden problems and late escalations.

Best practices that make the guide work:

Tailor deliberately and record why. A one-page tailoring note explaining what was combined, dropped or added helps reviewers and successors.
Write value into the charter. State expected outcomes and benefits, who owns them and how they will be measured after closure.
Use the seven domains as a review checklist. At each phase gate, ask briefly what has changed in governance, scope, schedule, finance, stakeholders, resources and risk.
Choose the development approach per component. Hybrid delivery is normal; plan stable work predictively and uncertain work adaptively.
Prefer leading indicators. Combine earned value or burn charts with risk trends and stakeholder sentiment so that problems surface early.
Keep learning continuous. Hold short retrospectives during the project, not only a lessons-learned meeting at the end, and feed results into the organisation's method.

Summary and key takeaways

The PMBOK Guide, Eighth Edition (PMI, launched November 2025) is the current edition and combines The Standard for Project Management with the Guide.
It defines a project as a temporary initiative created to deliver value and treats every project as an investment.
Six principles guide behaviour: holistic view, focus on value, embedded quality, accountable leadership, sustainability and an empowered culture.
Seven performance domains organise the work: governance, scope, schedule, finance, stakeholders, resources and risk.
Five focus areas (initiating, planning, executing, monitoring and controlling, closing) and a process matrix restore practical structure without making it mandatory.
Tailoring is central: choose predictive, adaptive or hybrid approaches and the lightest artefacts that still support decisions.
PMI certifies individuals (for example PMP and CAPM); organisations can only demonstrate alignment, often with maturity models and health checks.
The guide complements ISO 21502, PRINCE2, Scrum and PMI's program and portfolio standards rather than replacing them.

Reflection questions

Pick a project you have worked on. Which of the six principles was best applied, which was weakest, and what visible effect did that have on the result?
How would you split a current or recent project into parts that suit predictive planning and parts that suit adaptive delivery, and why?
Write two sentences for a project charter that state the expected value of a project you know, including who owns the benefit and how it would be measured.
Your organisation's template requires twenty documents for every project. Using the tailoring ideas from this tutorial, which would you keep for a three-month internal project, and how would you justify the decision to an auditor?
Where would the PMBOK Guide, a PRINCE2-style board and Scrum each add something on a project in your field, and where might they conflict?