Home›Blog›Project management knowledge areas: the map and the order
FundamentalsBeginnerSignature
Published September 6, 2026 · By Vincent KENNEL
Project management knowledge areas: the map and the order
Ten knowledge areas, eleven domains, three competence areas, or none at all: no two standards divide project management the same way. What they do agree on, without ever writing it down, is the order in which the areas get established.
In brief
There is no official list of project management knowledge areas: standards count between three and seventeen, and the ten stopped being the structure of the PMBOK Guide with its 7th Edition (2021), though the PMI still teaches them. Seven areas recur everywhere, and they are established in order: stakeholders, then scope, organisation, schedule, cost, control and reporting, with risk across all of them.
Ask ten project managers what project management is made of, and you get ten lists. That would be harmless if the lists were interchangeable, but each one decides where a question goes, and where a question goes decides who answers it and which document settles it. A schedule nobody can freeze, a cost nobody owns, a change nobody approved: each is a question that landed on the wrong desk.
What a knowledge area is, and whether there are still ten
The term belongs to one publisher. The PMBOK Guide, 6th Edition (2017) defines a knowledge area at section 1.2.4.6 as an identified area of project management, defined by its knowledge requirements and described through its own processes, practices, tools and techniques. That edition names ten: Integration, Scope, Schedule, Cost, Quality, Resource, Communications, Risk, Procurement, Stakeholder.
They are no longer the structure of the Guide. The 7th Edition (2021) moved to principles and eight performance domains, and the 8th Edition, released late 2025, carries seven. The PMI has not abolished the ten: its own PMP exam preparation glossary, updated in February 2023, still describes them in the present tense, two years after the change.
The more telling fact is negative. That definition lives in the Guide and nowhere else. The PMI Lexicon of Project Management Terms (2012) has no entry for it. The AFITEP Dictionnaire de management de projet, 3rd edition (1996), has no entry for domaine. ISO/FDIS 21506:2024, the vocabulary for project, programme and portfolio management, defines a hundred terms and uses neither domain, nor area, nor discipline, though what we read is the final draft and not the published text. The word everyone uses is defined by none of the three reference vocabularies.
Count the subdivisions and the picture holds:
PMBOK Guide: nine from 1996, ten from 2013, none in the structure since 2021
NF ISO 21500:2012, withdrawn on 16 March 2021: ten subject groups
NF ISO 21502:2021: none at all, nine integrated management practices and seventeen project management practices
PRINCE2 7 (2023): seven principles, seven practices, seven processes, seven performance aspects, and not one of the four is the areas
IPMA ICB 4.0 (2015): three competence areas, twenty-nine competence elements
APM Body of Knowledge, 8th edition (2025): none at all, six chapters, thirty-two sections, one hundred and seventeen topics
EIA-748-D (2018): five categories, thirty-two guidelines
NF X 50-115:2017, the French national standard in force: eleven domains of project management, a) to k)
Between three and seventeen subdivisions, depending on the standard and on what it is built to do.
What follows is therefore a grouping, and not a nomenclature: there is no official one to defer to. We call the seven areas, and keep knowledge area for the PMI object of 1996 to 2017, performance domain for the one that replaced it.
The seven areas, in the order you meet them
They come in the order a project meets them, not in the order of a table of contents. Each is a doorway this article names and does not open.
Stakeholders and coordination
Who has an interest in the project, who decides, who has to be informed and how often. Under contract, the first decision is who the project reports to and on which document: the customer-supplier chain is contractual before it is relational. See stakeholders and coordination.
Scope and requirements
What the project delivers, and what it does not. The decision that costs money is what falls inside the commitment, and therefore what triggers a change order. The work breakdown structure belongs to this ground. See scope and requirements.
Organisation and the team
Who does the work, under whose responsibility, and therefore who answers for the slip. Where the breakdown of work meets the breakdown of the organisation, the DoD Earned Value Management System Interpretation Guide (2019) and MIL-STD-881F at section 3.1.4 both name the intersection: the control account, the lowest level at which technical, schedule and cost responsibility exist together. See team and organisation.
Schedule and dependencies
In what order the work runs, and what blocks what. The decision is which date is tenable, and which contractual milestone a given delay puts at risk. See dependencies and planning.
Cost and finance
What the work consumes, in money and in resources. The decision is what is budgeted against which package, and at what point consumption becomes a variance. See workload and financials.
Control and reporting
Measuring real progress, seeing the variances, deciding on corrective action, accounting for it. The decision is what gets declared to the customer, and above what threshold a variance becomes an alert. NF X 50-115:2017 makes that triptych a task common to every domain at section 5.3.4. See steering and reporting.
Risk and opportunity
What may happen and is not simply absorbed. The decision is which contingency and which margin, and when a risk becomes a fact to replan around. See risks and opportunities.
Why that order, and what it lets you decide
Figure 1: the order in which the seven areas are established, and the two positions that escape the chain.
The standards agree on one point: their own table of contents is not a sequence. The GAO writes that the ten best practices of GAO-16-89G, its Schedule Assessment Guide, are in no particular order and are not a series of steps, and says the same of the figure in GAO-20-195G, its Cost Estimating and Assessment Guide. NASA prints on the cover of NASA/SP-2016-3424, its Project Planning and Control Handbook, that the order of the gears is not significant but their size is. GAPPS writes, in its Framework for Performance Based Competency Standards for Global Level 1 and 2 Project Managers (2007), p. 2, that its units, elements and criteria are neither linear nor sequential. And NF X 50-115:2017 notes at section 5.3.4 that the ranking of project management domains is a relative concept, which each organisation adapts to its own processes.
An order exists all the same, and it is written somewhere else: in the standards that describe what an organisation must produce under contract, rather than what an individual should know.
Scope comes before schedule. GAO-16-89G, p. 7: scope planning precedes sequencing, and the two should in no case be concurrent. The NASA Schedule Management Handbook, Revision 2 (2024), holds at section 5.3.1 that a clear understanding of the work content is necessary before a valid schedule can be developed.
The breakdown derives from the scope. The same handbook, at the same section, calls the breakdown structure the what of the scope, and has the documents that carry that scope, the statement of work among them, incorporated into it. ECSS-M-ST-10C Rev.1 derives it from the product tree at section 4.3.5, and MIL-STD-881F chains requirements specification to breakdown structure to statement of work to master plan and schedule, at section 2.2.3.
The schedule is built on the breakdown. GAO-16-89G, p. 21, puts it plainly: the breakdown structure defines what will be delivered, the schedule how the programme will produce it. GAO-20-195G, p. 62, makes it the starting point of the detailed schedule.
The organisation crosses the breakdown. EIA-748-D (2018), guideline e), in wording unchanged since the 2006 edition: integrate the programme breakdown structure and the organisational structure so that cost and schedule performance can be measured by elements of either or both.
The budget follows the schedule. GAO-20-195G, p. 298: the performance measurement baseline, the yardstick a programme is then measured against, assumes an integrated network schedule reflecting the breakdown structure and identifying resources. The NASA WBS Handbook, NASA/SP-20250006071 revision E (2025), at section 4.4: once the elements are planned, the basis for time-phased budgets is already there.
None of these texts publishes the chain. Each publishes one link, and the chain is what you get by laying them end to end. Two positions escape it: stakeholders settle before the chain starts, and risk runs across the whole of it without holding a rank in it. On control and reporting the claim has to be weaker still: the structure of EIA-748-D (2018) places analysis and management reports after budgeting, but no text makes that an obligation.
What the map buys you is a diagnostic. A question arrives, you name the ground, and the ground names the document that settles it and the person who owns it. The order does the rest: it says what has to be stable before anyone can decide. A schedule you cannot freeze sends you back to the scope, not to the scheduling tool.
An area is not a phase. The order is an order of establishment, not a division of the calendar: once set, the seven run in parallel until the project closes. An Integrated Baseline Review examines technical content, schedule, risk and resource adequacy in the same sitting, as the NDIA Guide to the Integrated Baseline Review, Revision 3 (2019) has it at section 1.3, and the DoD Earned Value Management System Interpretation Guide requires planning, scheduling, budgeting, work authorisation and accounting to stay integrated at all times.
Where the split came from
The PMI was founded in 1969 on the premise that some management practices are common to projects as different as a building and a drug. The split itself is documented from August 1983: Matthew H. Parry, in Project Management Quarterly 14(1), publishes a figure titled PMI/ESA Project Task Areas carrying six divisions, time, cost, communications, scope, quality and human resources. The paper also gives the reason for the split, and it is the best fact in this article: the body of knowledge was decomposed following the branching techniques of a work breakdown structure. The discipline was structured with its own tool.
What follows moves in three steps, not two. In August 1986, L. C. Woolshlager opens a series of seven articles in Project Management Journal 17(3), one per project management function: seven are established by then. In September 1986, R. Max Wideman, chairing the standards committee, argues in Project Management Journal 17(4) for expanding the seven areas to eight, so as to recognise risk as a function in its own right. In August 1987 the eight are published, and Wideman, by then chair of the PMBOK Standards Board, lists them in PM Network 1(3): scope, cost, time, quality, human resources, communications, contract-procurement, risk. The 1996 PMBOK Guide tells this as a two-step story, but that is a retrospective account and the 1986 papers are the evidence.
1996 brings two changes, both stated in the preface of that Guide: function is renamed knowledge area, because function was being read as a piece of the functional organisation, and integration is recognised as the ninth. 2013 makes a tenth by splitting stakeholders out of communications, recorded at annex X1.10 of the PMBOK Guide, 5th Edition (2013). 2017 renames Time Management to Schedule Management, whereas time is not managed, at annex X1.11 of the 6th Edition. 2021 changes logic altogether, to principles and performance domains, a direction the 7th Edition traces at annex X5.2 to research from 2012. The 8th Edition, released late 2025, carries seven performance domains and six principles.
Figure 2: two series, not one. From 2021 the count changes object.
One reading is worth heading off: the 8th Edition is not a return to knowledge areas. The number of principles falls at the same time as the number of domains, twelve and eight in 2021, six and seven in 2025.
In short
Naming the ground is the whole move. It tells you who decides and which document settles the matter, and the order tells you what has to be stable before anyone can decide at all. So the next time a question stalls, place it on the map before answering it: if it sits downstream of something unresolved, the answer is upstream, and the ground it belongs to is where to start reading.
And one liberty follows from all of this: since no list carries authority, an organisation that settles on its own owes no justification to any standard. What you have above is a way to find your ground, not a nomenclature to conform to.
Stop guessing. See the real impact.
Frequently asked questions
Q.Are knowledge areas the same as project management process groups?
No. They are two ways of classifying the same processes. The PMBOK Guide, 6th Edition (2017) defines a process group at section 1.2.4.5, then adds at section 1.2.4.6 that processes are also categorised by knowledge area. Its Table 1-4 maps one against the other.
Q.What is the difference between a knowledge area and a performance domain?
A knowledge area divides what a project manager needs to know. A performance domain describes a group of activities critical to delivering outcomes, as the PMBOK Guide, 7th Edition (2021) puts it at section 2. Two different objects, which is why their counts cannot be compared.
Q.Do you need to master every area to run a project?
No, and the French national standard draws the line itself. NF X 50-115:2017, at section 5.3.4, separates the activities a manager must master to steer a domain from those that belong to the methods and techniques practised inside it. Steering an area and practising it are not the same job.
References
AFNOR - NF X50-115 - Management de projet et de programme, présentation générale - Décembre 2017
AFNOR - NF ISO 21500:2012 - Lignes directrices sur le management de projet - Octobre 2012
AFNOR - NF ISO 21502:2021 - Recommandations sur le management de projet - Juin 2021
AFNOR, AFITEP - Dictionnaire de management de projet français-anglais-espagnol - 3e édition, 1996
