PMBOK — the Project Management Body of Knowledge, published by PMI — is less a methodology and more a vocabulary. It doesn’t tell you to run Scrum, Kanban, Waterfall, or anything else. It tells you that every project, regardless of shape, has a recognisable set of problems to solve — scope, time, cost, quality, risk, people, communication, procurement, stakeholders, and the integration glue between them — and it gives each problem a name, a set of inputs it consumes, and a set of outputs (the artifacts) it produces.
That framing is the single most useful thing a working project manager can steal from PMBOK. You don’t need to run all 49 processes from the 6th edition or memorise the 12 principles of the 7th. You need to know: for this part of the work, what do I need before I start, and what do I leave behind when I’m done?
This article is that walkthrough — opinionated where it needs to be, complete where it matters.
TL;DR
- PMBOK = vocabulary + an input/output map, not a methodology. Tailor it; don’t perform it.
- Five process groups: Initiating, Planning, Executing, Monitoring & Controlling, Closing.
- Ten knowledge areas: Integration, Scope, Schedule, Cost, Quality, Resources, Communications, Risk, Procurement, Stakeholders.
- Every part has inputs (what you need to start) and artifacts (what proves it happened and informs the next part).
- The Project Charter, Project Management Plan, and Lessons Learned Register are the three artifacts that survive every project.
- PMBOK 7 reframes the same ground as twelve principles and eight performance domains — the inputs/outputs don’t disappear, they just stop being the point.
Why a Framework, Not a Recipe
Engineers often meet PMBOK as a wall of acronyms and process diagrams and bounce off. Fair. But the moment you’re running a project bigger than one team for longer than one quarter, you start re-inventing PMBOK’s artifacts whether you’ve read the guide or not. Someone asks “what’s in scope?” — you invent a scope statement. A stakeholder goes quiet for three weeks and then torpedoes a decision — you invent a stakeholder register. A risk lands on your head in week nine that you vaguely remember worrying about in week two — you invent a risk register, retroactively, from Slack.
PMBOK’s value is not that it forces you to produce every one of its artifacts. It is that when you need one, you are not designing it from scratch under pressure. You pull the shape off the shelf, tailor it to fit, and move on.
The other thing worth saying up front: the 7th edition (2021) shifted from a process-based framing to a principle-based one. It organises the same ground into 12 principles (stewardship, team, stakeholders, value, systems thinking, leadership, tailoring, quality, complexity, risk, adaptability, change) and 8 performance domains. The 6th edition’s process groups and knowledge areas still exist as a Standard for Project Management and in the Models, Methods, and Artifacts section — they just aren’t the spine anymore.
For the purposes of “what do I put in, what do I get out”, the 6th-edition structure is still the most direct map. That’s the one this article walks.
The Five Process Groups
Process groups are phases of activity, not phases of the project. They overlap. You will be executing one part of the work while planning another and closing a third.
| # | Group | Purpose | What survives |
|---|---|---|---|
| 1 | Initiating | Decide the project exists and what it is for. | Project Charter, Stakeholder Register (initial) |
| 2 | Planning | Decide how to do it. | Project Management Plan + all subsidiary baselines |
| 3 | Executing | Do it. | Deliverables, work performance data, team updates |
| 4 | Monitoring & Controlling | Notice when reality diverges from plan, and steer. | Change requests, forecasts, variance reports |
| 5 | Closing | Finish cleanly, including the bookkeeping most teams skip. | Final report, accepted deliverables, Lessons Learned Register |
Each knowledge area has processes that live in one or more of these groups. The input/output chains below follow the life cycle; you can read each area top-to-bottom as a timeline.
The Ten Knowledge Areas — Inputs In, Artifacts Out
Each section below gives: the purpose, the typical inputs (what must exist for this area to function), and the output artifacts (what you keep, version, and hand to the next person). Tools and techniques — the middle column of PMBOK’s famous “ITTO” tables — are mentioned only when they matter in practice.
Summary Table — All Ten Areas at a Glance
| # | Knowledge Area | Purpose (one line) | Headline Artifacts | Downloads |
|---|---|---|---|---|
| 1 | Integration | The glue that keeps the other nine in sync. | Project Charter · Project Management Plan · Change Log · Lessons Learned Register | 📄 · 📋 |
| 2 | Scope | Define what is in, what is out, and the acceptance criteria. | Scope Statement · WBS + Dictionary · Scope Baseline · Requirements Traceability Matrix | 📄 · 📋 |
| 3 | Schedule | Decompose, sequence, estimate, and track time. | Milestone List · Project Schedule · Schedule Baseline · Schedule Forecasts | 📄 · 📋 |
| 4 | Cost | Estimate, budget, and track money. | Cost Estimates · Basis of Estimates · Cost Baseline · EAC / ETC forecasts | 📄 · 📋 |
| 5 | Quality | Conformance to requirements; fit for use. | Quality Management Plan · Quality Metrics · Quality Reports · Verified Deliverables | 📄 · 📋 |
| 6 | Resource | People and physical resources. | Resource Management Plan · Team Charter · RBS · Resource Assignments | 📄 · 📋 |
| 7 | Communications | Right info, right audience, right time. | Communications Plan · Status Reports · Work Performance Reports | 📄 · 📋 |
| 8 | Risk | Inventory uncertainty and respond to it. | Risk Management Plan · Risk Register · Risk Report · Contingency Reserves | 📄 · 📋 |
| 9 | Procurement | Anything bought from outside. | Procurement Plan · Bid Docs · SOW · Contracts · Closed Procurements | 📄 · 📋 |
| 10 | Stakeholder | Everyone whose interests are affected. | Stakeholder Register · Engagement Assessment Matrix · Engagement Plan | 📄 · 📋 |
📄 = blank template you can fill in · 📋 = example filled with sample data. Each PDF is a printable A4 form with the exact inputs/outputs the section below describes.
1. Integration Management
The glue. Integration is where a change in one area ripples through the rest — a scope change triggers a schedule change triggers a cost change triggers a risk re-assessment. Without integration, you have ten well-managed silos and a project that still misses the date.
| Inputs | Output Artifacts |
|---|---|
| Business case / statement of work | Project Charter — foundational document that authorises the project, names the sponsor and project manager, and captures success criteria, budget envelope, and risk appetite. No charter = a wish, not a project. |
| Agreements (contracts, MoUs) with sponsor and external parties | Project Management Plan — master integrated plan that contains (or references) the scope, schedule, and cost baselines plus every subsidiary plan. |
| Enterprise Environmental Factors (EEFs) — org culture, tools, market, regulations | Change Log / Approved Change Requests — every change, its reason, and which baselines moved. |
| Organisational Process Assets (OPAs) — templates, prior lessons learned, policies | Issue Log — things that have already gone wrong and need active management. |
| Lessons Learned Register — grows throughout the project; feeds the next project’s OPAs. | |
| Final Product / Service Transition and Final Report (at closing). |
2. Scope Management
Scope is what the project will and will not deliver. The single most valuable sentence a scope document contains is a well-chosen one beginning with “Out of scope:”.
| Inputs | Output Artifacts |
|---|---|
| Project Charter | Scope Management Plan and Requirements Management Plan — how scope and requirements will be defined, validated, and controlled. |
| Project Management Plan (especially the Scope Management Plan) | Requirements Documentation — numbered, testable, traceable. |
| Stakeholder Register and requirements | Requirements Traceability Matrix — each requirement mapped to source, design, test case, and accepted deliverable. Wins scope arguments. |
| Relevant EEFs and OPAs | Project Scope Statement — authoritative “what’s in, what’s out, deliverables, acceptance criteria”. |
| Work Breakdown Structure (WBS) + WBS Dictionary — scope decomposed into work packages small enough to estimate and assign. | |
| Scope Baseline — approved Scope Statement + WBS + WBS Dictionary, version-controlled. | |
| Accepted Deliverables — from Validate Scope; formal customer sign-off per deliverable. |
3. Schedule Management
Time. Notice that estimating, sequencing, and resource-levelling are separate concerns that PMBOK forces you to un-tangle.
| Inputs | Output Artifacts |
|---|---|
| Scope Baseline (the WBS — you cannot schedule work you haven’t decomposed) | Schedule Management Plan — units, rounding, reporting cadence, scheduling tool of record. |
| Project Management Plan | Activity List + Activity Attributes — decomposition of work packages into schedulable activities. |
| Activity attributes, resource availability, and calendars | Milestone List — dates/events that matter to the business (go-live, regulatory deadline, contractual gate). |
| Schedule Network Diagram — dependencies between activities (FS, SS, FF, SF). | |
| Duration Estimates + basis (analogous, parametric, three-point / PERT). | |
| Project Schedule — typically a Gantt chart; the model underneath is what matters. | |
| Schedule Baseline — approved schedule; variance is measured against it. | |
| Schedule Forecasts — from Control Schedule; updated as reality diverges. |
4. Cost Management
Budget. Related to schedule but not the same — a slipped schedule costs money through extended burn; a bad estimate costs money through bad pricing.
| Inputs | Output Artifacts |
|---|---|
| Scope Baseline, Schedule Baseline, Resource plan | Cost Management Plan — units, rounding, control thresholds, measurement technique (usually EVM). |
| Risk Register (contingency reserves flow from here) | Cost Estimates — with a documented basis and a confidence range. |
| Historic actuals from similar projects (OPAs) | Basis of Estimates — assumptions, exclusions, sources. Protects you when an estimate is later called a promise. |
| Cost Baseline — time-phased budget, including contingency reserves for known risks. Management reserves sit above the baseline. | |
| Project Funding Requirements — when money is needed, not just how much. | |
| Cost Forecasts — EAC (Estimate at Completion), ETC (Estimate to Complete), from Control Costs. |
5. Quality Management
Quality is conformance to requirements and fitness for use. Not gold-plating. Not subjective taste.
| Inputs | Output Artifacts |
|---|---|
| Scope Baseline + Requirements Documentation | Quality Management Plan — how quality will be planned, assured, and controlled; what standards apply. |
| Stakeholder expectations | Quality Metrics — measurable definitions of “done well” per deliverable. |
| Risk Register (quality risks) | Quality Checklists — the concrete, runnable version of the metrics. |
| Applicable standards and regulations (EEFs) | Quality Reports — findings from Manage Quality (process audits) and Control Quality (product inspections). |
| Verified Deliverables — outputs of Control Quality; a prerequisite to Validate Scope. | |
| Test and Evaluation Documents — test plans, test results, defect logs. |
6. Resource Management
People and physical resources (equipment, materials, facilities). The 6th edition renamed “Human Resource Management” to “Resource Management” to acknowledge both.
| Inputs | Output Artifacts |
|---|---|
| Project Charter and Management Plan | Resource Management Plan — how team members are acquired, developed, managed, released; how physical resources are procured and controlled. |
| Scope and Schedule baselines (what work, and when) | Team Charter — team ground rules, values, communication norms, decision-making protocol. |
| Stakeholder Register | Resource Requirements + Resource Breakdown Structure (RBS) — hierarchical view of resources by category and type. |
| EEFs (labour market, org structure) | Resource Calendars — when each resource is available. |
| Resource Assignments — who is doing what, when. | |
| Team Performance Assessments — individual and team. | |
| Physical Resource Assignments + project reports on utilisation and variance. |
7. Communications Management
Communication is not “sending updates”. It is engineering the right information reaching the right stakeholder at the right time in a form they will actually read.
| Inputs | Output Artifacts |
|---|---|
| Stakeholder Register | Communications Management Plan — a table, per audience, of: what information, why, frequency, channel, owner, format, escalation path. |
| Project Management Plan (especially Stakeholder Engagement Plan) | Project Communications — actual artifacts produced against the plan: status reports, dashboards, meeting minutes, presentations, release notes. |
| EEFs (time zones, languages, cultural norms) | Work Performance Reports — consolidated, audience-tailored view used for Monitor & Control decisions. |
| OPAs (templates, channels) | Updates to Issue Log and Lessons Learned Register from communication outcomes. |
8. Risk Management
Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on an objective. The positive half — opportunities — is routinely ignored. Don’t.
| Inputs | Output Artifacts |
|---|---|
| Project Charter (risk appetite) | Risk Management Plan — methodology, roles, categories (Risk Breakdown Structure), probability/impact definitions, risk appetite, reporting cadence. |
| Project Management Plan | Risk Register — living inventory of individual risks (description, category, causes, probability, impact, owner, response strategy, triggers). |
| Scope, schedule, cost baselines (what’s at stake) | Risk Report — narrative view of overall project risk, top exposures, trends. For executive audiences. |
| Stakeholder Register | Contingency Reserves — carved out of cost and schedule baselines, tied to specific risks. |
| Relevant OPAs (prior risk registers, checklists) | Change Requests — from Implement Risk Responses and Monitor Risks. |
Response strategies cheat-sheet:
| Type | Strategies |
|---|---|
| Threats (negative) | avoid · transfer · mitigate · accept · escalate |
| Opportunities (positive) | exploit · share · enhance · accept · escalate |
9. Procurement Management
Anything the project buys from outside the performing organisation. Vendors, SaaS, consultants, hardware, legal counsel. The artifacts here become legally enforceable, which is why this area is the most document-heavy.
| Inputs | Output Artifacts |
|---|---|
| Scope Baseline + Requirements Documentation | Procurement Management Plan — make-or-buy criteria, contract types, procurement doc standards, independent estimates policy. |
| Project Schedule | Procurement Strategy — delivery method, contract payment type (fixed-price, cost-reimbursable, T&M), phasing. |
| Risk Register | Bid Documents — RFI / RFQ / RFP / IFB. |
| Stakeholder Register | Procurement Statement of Work (SOW) — what the vendor is actually being asked to deliver, at a level the vendor can bid against. |
| Organisational procurement policies (OPAs) | Source Selection Criteria — scoring rubric, agreed before bids arrive. |
| Make-or-Buy Decisions. | |
| Independent Cost Estimates — internal benchmark against which vendor bids are compared. | |
| Selected Sellers + Agreements / Contracts. | |
| Procurement Documentation — proposals, correspondence, change orders, performance reports, payments. | |
| Closed Procurements — formal closure, final payment, claims resolution, archival. |
Contract-type trade-offs:
| Contract type | When it fits | Risk sits with |
|---|---|---|
| Fixed-Price (FP / FFP) | Well-defined scope, stable requirements. | Seller |
| Cost-Reimbursable (CR / CPFF / CPIF) | Research, uncertain scope; incentive aligns quality. | Buyer |
| Time & Materials (T&M) | Short, hybrid; hourly rate known, quantity not. | Shared |
10. Stakeholder Management
Stakeholders are anyone whose interests are affected by the project — positively or negatively. Yes, the noisy ones. Also the quiet ones who will surface at the worst possible moment if ignored.
| Inputs | Output Artifacts |
|---|---|
| Project Charter | Stakeholder Register — identification, assessment (interest, power, influence, attitude), classification. |
| Business documents (business case, benefits plan) | Engagement Assessment Matrix — per stakeholder, current level and desired level; the delta drives tactics. |
| Project Management Plan | Stakeholder Engagement Plan — how each group is engaged, by whom, through which channels. |
| Agreements, EEFs, OPAs | Change Requests arising from engagement (often scope-adjacent). |
| Updates to communications, risk, and issue logs. |
Engagement levels (use on the matrix):
| Level | Meaning |
|---|---|
| Unaware | Does not know about the project or its impacts. |
| Resistant | Aware and actively opposed. |
| Neutral | Aware, neither supportive nor resistant. |
| Supportive | Aware and supportive of the project and its outcomes. |
| Leading | Aware and actively engaged in ensuring success. |
How the Artifacts Connect
The ten areas look independent on the page, but their artifacts are joined at the hip. A small but representative slice:
- The Scope Baseline is an input to Schedule, Cost, Quality, Resource, Risk, and Procurement planning.
- The Risk Register is an input to Cost (contingency), Schedule (risk-adjusted durations), Procurement (risk-based contract type), Quality (quality risks), and Communications (who needs to hear what).
- The Project Management Plan references — or contains — every subsidiary plan and baseline. Changes to any baseline pass through Integration’s Integrated Change Control process, which updates the plan and notifies affected areas. This is the loop that keeps ten silos from drifting out of alignment.
flowchart LR
Charter[Project Charter] --> PMPlan[Project Management Plan]
PMPlan --> ScopeB[Scope Baseline]
PMPlan --> SchedB[Schedule Baseline]
PMPlan --> CostB[Cost Baseline]
ScopeB --> SchedB
ScopeB --> CostB
ScopeB --> QualityP[Quality Plan]
ScopeB --> RiskR[Risk Register]
ScopeB --> ProcP[Procurement Plan]
RiskR --> CostB
RiskR --> SchedB
RiskR --> ProcP
StakeR[Stakeholder Register] --> CommsP[Communications Plan]
StakeR --> EngageP[Engagement Plan]
PMPlan --> ChangeLog[Change Log]
ChangeLog -.integrated change control.-> ScopeB
ChangeLog -.integrated change control.-> SchedB
ChangeLog -.integrated change control.-> CostBTailoring — The Part PMI Actually Wants You to Read
The 7th edition elevates tailoring to a principle, but it was always implicit. A three-week internal tool does not need a Procurement Management Plan, a Make-or-Buy Decision document, and independent cost estimates. It needs a sentence in the charter that says “no external procurement required” and a note in the lessons learned if that turns out to be wrong.
The useful question is not “which artifacts does PMBOK require?” — PMBOK requires none of them. The useful questions are:
| Question | Why it matters | Implication |
|---|---|---|
| Will a future reader need this? | Successors, auditors, future-you all pay the cost of missing context. | If yes, create it. |
| Will anyone notice it doesn’t exist until it’s too late? | Risk and stakeholder registers fall here — cheap while small, expensive to invent in a crisis. | Create early, grow over time. |
| Is there a regulatory or contractual driver? | Quality audits, government procurement, ISO/PMI certification remove tailoring flexibility. | Know which artifacts are legally load-bearing. |
| What is the blast radius of getting this wrong? | A scope statement for 5 people × 2 months can be a page. 50 people × 18 months needs to be adversarially readable. | Scale detail to stakes. |
The Three Artifacts That Always Earn Their Keep
If you strip everything else away and keep only three artifacts across every project you ever run, keep these:
- The Project Charter — because no one can later dispute what the project was for.
- The Risk Register — because the risks you tracked on day 30 are usually the reasons you’re calling a retro on day 180.
- The Lessons Learned Register — because unlearned lessons become organisational tax, paid again on every subsequent project.
Everything else is negotiable based on tailoring. These three compound in value the longer you keep a team together.
A Working Checklist
Before you declare a project “planned enough to start executing”:
- Charter signed by the sponsor, with success criteria a reasonable person could later measure.
- Scope statement with an explicit Out of scope list and acceptance criteria per deliverable.
- WBS decomposed to work packages that can be estimated in days, not months.
- Schedule baseline with a critical path identified and milestones tied to business dates.
- Cost baseline with reserves separated from working budget.
- Quality plan naming the standards that apply and the metrics that prove conformance.
- Resource plan with named people for the first phase, not just role codes.
- Communications plan — one row per stakeholder group, not an aspirational paragraph.
- Risk register with at least the top ten risks, owners, and responses.
- Procurement plan — even if it says “none required”.
- Stakeholder register with engagement levels (current and target) assessed.
- Change control process documented — who can approve what, by when.
If more than two of those are missing or hand-waved, you’re not ready to start executing; you’re ready to start discovering how unready you were.
Further Reading
- A Guide to the Project Management Body of Knowledge (PMBOK Guide) — 6th and 7th editions. Read the 6th for the process/artifact map; read the 7th for the principles and tailoring framing. They are complementary, not replacements.
- The Standard for Project Management (included with the 7th edition) — the principles, in under 40 pages.
- PMI’s Practice Guides — Agile, Benefits Realization, Requirements, Risk — for deeper dives on specific areas.
- The PRINCE2 manual — a different vocabulary covering the same territory, stronger on governance and stage gates; reading it alongside PMBOK triangulates which concepts are universal and which are PMI-specific.
- Edward Yourdon, Death March — cautionary tales that make the artifacts above feel less like paperwork and more like protective equipment.
Frameworks age. Projects don’t stop. The artifacts are how one outlives the other.
