The Standard for Project Management vs the PMBOK Guide
Anyone who buys the PMBOK® Guide receives two books in one binding, and nothing on the cover says so. The confusion surfaces the first time somebody cites Section 4.2 in a meeting and the person opposite cannot find anything resembling it, because one of them is counting from the front of the volume and the other from the front of the Guide.
The arrangement is simple once it has been said out loud. The Standard for Project Management comes first and is the shorter half: foundational terms, a system for value delivery, the project environment, the functions and roles a project needs, six principles, life cycles and development approaches, and the five Project Management Focus Areas. The PMBOK® Guide follows and is the longer half: seven performance domains, forty processes distributed across them, tailoring, inputs and outputs, tools and techniques, and a set of appendices.
What each half is for
The Standard is the normative document, published as a standard in its own right. It states what project management is, what a project exists to do, and what sound judgement looks like in general terms, and it is deliberately free of technique. Nothing in it will tell you how to build a schedule.
The Guide is descriptive. It sets out what the work consists of, domain by domain, with the processes, artefacts and techniques a project manager handles. It is explicitly nonprescriptive, so it describes rather than instructs, and the material in it is the material of the job: estimating, sequencing, forecasting, engaging, responding to risk.
Section 1.2 of the PMBOK® Guide Eighth Edition explains how the two sit together, and the short version is that they describe the same work at two different altitudes. The Standard is where a project manager goes to work out whether something is worth doing and what the project is for. The Guide is where they go to find out what the doing consists of.
Which half answers the question in front of you
The routing becomes easy once the habit is formed, and three kinds of question cover almost all of it.
Questions about whether and why belong to the Standard. Should this work be a project at all. Is the value proposition still intact. Is the team empowered enough to be accountable for what we are asking them to carry. Does this decision need a wider look before anybody takes it. These are judgement questions, and the six principles are written to be applied to exactly this sort of thing.
Questions about what and how belong to the Guide. What does a scope baseline contain. What separates resource levelling from resource smoothing. What is involved in monitoring stakeholder engagement. How does a risk response become real work. These questions have answers with content in them, and the content sits in the domains.
Questions about how much belong to both, and this is the pair that catches people. How much governance does this project need. How formal should the change process be. How much analysis does this risk deserve. The Guide supplies the full shape of the practice and the tailoring material inside each domain; the Standard supplies the judgement about what this particular context warrants. Answering a how-much question out of the Guide alone produces a project that does everything described in it, which nobody has ever recommended.
One car, two build standards
An automotive supplier was running a pre-production programme for a new interior module, six months of builds before the line went to volume. The engineering team wanted to know whether design changes during pre-production had to go through the full change control process used in volume production, which took nine days and three signatures.
Read as a Guide question, the answer is that change control governs proposed changes to approved baselines, that changes are assessed for their effect and implemented once decided, and that the documentation is updated afterwards. All correct, and none of it answers what was asked, because what was asked was a how-much question.
The Standard supplies the missing half. The purpose of that control is to protect commitments other people have already made decisions on the strength of. In pre-production the commitments that matter are the tooling order and the supplier release, and the rest is deliberately fluid, because learning is what the phase exists for. So the programme built two routes. Changes touching tooling geometry or a released supplier part went through the full nine-day process. Everything else went to a daily engineering review with a one-day turnaround and a written record. Two hundred and eleven changes took the fast route over six months. Nine took the slow one.
Neither half of the book produces that answer on its own. The Guide said what change control is made of. The Standard said how much of it this phase had earned.
For a PMP® candidate, knowing which half a concept lives in is worth more than it sounds. Development approaches and the Focus Areas sit in the Standard; performance domains, processes and techniques sit in the Guide. A study plan treating the whole volume as one undifferentiated text tends to over-weight the technique material, simply because there is more of it, and to leave the judgement material thin. In any situation you read, settle first whether it is asking what to do or how much of that to do. Practising that distinction on realistic situations is something a structured PMP exam preparation course makes room for.
The practical use of the split is in settling arguments. When a discussion about process gets stuck, it is nearly always because two people are answering different questions: one is arguing about what the practice contains and the other about how much of it this project warrants. Naming which of the two is actually on the table tends to end the argument inside a minute, and the book has a half for each.
Interested in going further?
Most disputes about project process are how-much disputes in disguise, and quoting practice back and forth does not resolve them. Omega's PMP® Exam Preparation works through decisions where the judgement and the technique have to be used together.
Both documents are published together in the PMBOK® Guide Eighth Edition, the Standard first and the Guide after it.
Ad · Amazon affiliate link.
References
A056: Predictive vs Agile vs Hybrid Project Management: How to Choose
A030: The Project Team Is Not the Project Manager’s Staff
A028: Project Manager vs Scrum Master vs Product Owner
A043: When Should a Project Manager Escalate?
A057: How to Recognise Predictive, Agile and Hybrid PMP Scenarios
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
