The PMI introduced 8 Project Performance Domains into the 7th Edition of its Project Management Body of Knowledge. These are different, yet similar, to ideas we’ve seen many times. So, what are these Project Performance Domains, why do they matter, and how well has the PMI drafted them?
Those are the three questions we will answer in this article. And, to do so, I’ve split it into six sections:
The Project Management Institute (PMI) issues a new edition of its Guide to the Project Management Body of Knowledge (PMBOK Guide) every four years or so. In summer 2021, it released the 7th Edition of the PMBOK Guide, PMBOK 7.
But, this was a revolutionary change from its six predecessors, and we cover all you need to know, in our feature article, PMBOK Guide 7th Edition: Your 20 Most Important Questions Answered.
The book itself contains two distinct parts:
Both parts saw a revolutionary overhaul, bearing no resemblance in style and structure to the 6th edition.
The biggest component of the Guide to the Project Management Body of Knowledge is the Project Performance Domains. On the face of it, these replaced the 10 Knowledge Areas (KAs) of the previous edition. Indeed, nine of those KAs appeared in the first edition, back in 1996.
When PMBOK 7 introduced the idea of performance domains, it was not a new idea – neither in industry in general, nor with the PMI in particular.
The idea of performance domains has been around for a long time. However, it was PMBOK 7 that created our current concept of Project Performance Domains. Two of the PMI’s other standards contain performance domains:
As a result, the obvious place to start is with the definition of Project Performance Domains in PMBOK 7. Curiously, the term does not appear n the glossary. (And neither does Performance Domain). But we have the opening sentence of Chapter 2:
A project performance domain is a group of related activities that are critical for the effective delivery of a project outcome
Chapter 2 of the Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
Project Performance Domains are sets of activities that run throughout a project.
Please don’t confuse PMBOK 7’s eight performance domains with:
These form the basis of both the:
Indeed, the PMP ECO uses the term domain, and defines it as a:
…high-level knowledge area that is essential to the practice of project management
This is not a bad definition. However, in the ECO context, it is referring to a higher level than the 8 Project Performance Domains of PMBOK 7.
I have been thinking about this carefully. As a result, I have a definition that is different from those of PMI in one substantive way. Here it is:
A project performance domain is the set of skills, activities, and behaviors that contribute to the effective practice of project management.
So, a performance domain is a logical grouping of some of the things we do, to deliver a project, its outcomes, and thus its value. They are what we spend our time doing.
Note: I do not believe that all parts of a performance domain will be necessary (critical/essential) in all contexts. And I would draw any performance domain wider than ‘just’ the elements critical to performance. What do you think?
PMI’s eight Project Performance Domains are:
Stakeholders will determine the success, or not, of your project. This is one of my Project Management ‘Rules’. So, this domain is about building effective working relationships with them, so you can properly integrate their needs, priorities, preferences, and points of view.
It is your team who will deliver the project. So, this domain is all about developing and leading your team, so that they can succeed.
All projects are hybrid in some way, but what elements will you draw on to create your project approach? And how will you structure your project to optimize the delivery of value and accountability?
Good planning is what sets your project up to succeed. The opposite is also true. This domain draws all of the knowledge and processes from the PMBOK 6 Planning Process Group, to set up that success through the planned scope, activities, schedule, resources, budget, and more.
This one may seem a little odd. Isn’t it all ‘project work’? Think of this domain as being about the infrastructure you need to create. It’s a kind of meta-activity that includes things like communication, procurement, deployment of physical resources, and collation of capability, knowledge, and expertise.
This domain is a close match for much of the knowledge and many of the processes of the old PMBOK 6 Executing Process Group. And I for one much prefer the word ‘delivery to ‘execution’. The latter sounds so… final. This runs through the whole implementation piece, right to handover.
I understand why PMI separated its Monitoring and Controlling Process Group from Executing. But too many people interpreted this as a different project stage. This was wrong. There is a whole extra skillset here and the domain structure makes this clearer. So, this domain is about assessing performance and taking the necessary steps to bring your project back on track.
Uncertainty is in the nature of a project – as are the other components of VUCA: Volatility, Complexity, and Ambiguity. And an uncertainty that can have an impact on our outcome is a risk – which volatility, complexity, and ambiguity exacerbate. Here is where you will find all the knowledge and skills of risk management.
One of my projects for 2022 was to produce a set of eight articles to cover each of these 8 Project Performance Domains.
And, to supplement each article, I have also produced a Kindle-exclusive eBook, that will give you all the knowledge you need, to understand the performance domain. These contain both my analysis of the domain, and anything from 6 to 8 additional chapters that look at aspects of the domain in detail.
PMBOK 7 treats each of the 8 sections describing the Project Performance Domains in a consistent way. They have four parts:
Many of them also have subsections describing relevant aspects of tailoring.
I will offer you three reasons why this is an important idea that you need to understand.
The first reason that Project Performance Domains matter is PMI’s assertion that:
Together the performance domains form a unified whole.
Chapter 2 of the Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
Therefore, by definition, the domains divide up the totality of Project Management knowledge, skills, and behaviors. By the way, this is why my own definition excludes the words necessary, critical, essential, or other synonyms. For each project, you may find that what elements you need to draw upon, and how they inter-relate, will be different. But you can expect all the domains (but not all the content of each domain) to be necessary for every project.
This relates to our second reason why Project Performance Domains matter. They run throughout every project, no matter what approach you choose, for project delivery. So, these domains are equally appropriate to:
Because the knowledge and skillsets of all domains are equally important – and necessary as a whole – they must also be interdependent. None can exist in isolation from its companions, and the set of eight is incomplete with any missing.
What this means is that we must not artificially divide up our practice of project management into independent workstreams. This approach is often referred to as the creation of ‘silos’ or ‘stovepipes’.
We might naturally behave as if they are separate disciplines when we study and learn the craft of project management. We may also choose to specialize in one or other of these domains – or parts of them, like:
However, these choices are about organizational pragmatics. In a real project, we must integrate our team’s activities across all eight domains.
PMI has determined what it considers the 8 domains to include. We’ll look at each, in detail, in the eight forthcoming articles. And we’ll provide detailed explanations of each component in their accompanying detailed eBooks.
Here, I think it is worth trying to reconcile the 8 domains of PMBOK 7 with the previous 10 Knowledge areas and 5 Processes of PMBOK 6.
Note that, because of the integrated nature of Project Management, these allocations are, at best, approximations. You may not rely upon any form of one-to-one correspondence. I suspect this is why the PMBOK 7 authors chose not to present any such reconciliation.
Project Performance Domain | PMBOK 6 Knowledge Areas | PMBOK 6 Processes |
Stakeholders | Stakeholder Management | |
Team | Resource Management (team parts) | |
Development Approach and Life Cycle | Integration Management | InitiatingClosing |
Planning | Scope Management (all parts except control) Schedule Management (all parts except control) Cost Management (plan, estimate, determine parts) Resource Management (plan, estimate, acquire parts) | Planning |
Project Work | Resource Management (develop and manage team, and control parts) Communications Management Procurement Management | |
Delivery | Scope Management (control part) Schedule Management (control part) Cost Management (control part) Quality Management | Executing |
Measurement | Monitoring and Controlling | |
Uncertainty | Risk Management |
As I have written before, I do not consider the list of 10 Knowledge Areas in PMBOK 6 to be complete. In this sense, the 8 Domains of PMBOK 7 are more so. It is far easier to see how all Project Management knowledge can fit into them.
We can draw on my wider selection of knowledge areas, along with:
To keep this table simpler, I am going to allocate each element of these four sources against one of the eight Project Performance Domains. I will select the one I think it best fits, for illustrative purposes only. Please recognize that this is a gross oversimplification.
Project Performance Domain | Knowledge Areas | APMBoK Sections | PRINCE2 Themes | PMI Practice Standards |
Stakeholders | Stakeholder Management | 3.1 Engaging Stakeholders | ||
Team | Leadership | 3.2 Leading Teams | ||
Development Approach and Life Cycle | Governance Tailoring | 1.2 Lifecycle Options and Choices1.3 Establishing Governance and Oversight2.1 Shaping the Early Lifecycle | Organization | |
Planning | Scope Management Schedule Management Cost Management Resource Management | 4.1 Defining Outputs4.2 Integrated Planning | PlansBusiness Case | Project EstimatingSchedulingWork Breakdown Structures |
Project Work | Resource Management Communications Management Procurement Management Knowledge Management | 2.2 Assurance, Learning, and Maturity4.3 Controlling Deployment | ||
Delivery | Quality Management Progress Management | 4.3 Controlling Deployment | QualityChange | Configuration Management |
Measurement | Benefits/Value Management | 2.3 Transition into Use | Progress | |
Uncertainty | Risk Management | Risk |
Throughout 2022, I have produced a series of eight articles that assess each of the Project Performance Domains in detail. So, I will summarize each domain and offering you the links you need, to investigate each performance domain further.
Note that, in each summary, I offer my definition of the domain. In each article, I discuss the PMBOK Guide definition and why I usually choose a slightly different articulation.
Here is your quick navigator:
In this case, I think the PMBOK 7 definition is spot on:
‘The Stakeholder Performance Domain addresses activities and functions associated with stakeholders.’
The Stakeholder Performance Domain was so nearly among the best. However, with no mention of the need to plan your stakeholder engagement campaign, I could not describe it as ‘good’.
Score: 3 Okay
Needs Significant work
The Stakeholder Performance Domain is simple, clear, and precise. What is there is good.
One of the definitions is naïve and unhelpful. There is no reference to planning your stakeholder engagement.
‘The Team Performance Domain addresses the support, organization, management, leadership, and culture of the people who are responsible for producing project deliverables that realize business outcomes.’
The Team Performance Domain is neither good, nor bad. It’s merely ‘okay’.
I’d like to see a fair amount of work on this section in the next edition of the PMBOK Guide – assuming that it retains the Project Performance Domains structure.
As with the Stakeholders Domain, what is there, is Good. It is what is missing that is largely responsible for the Okay rating.
Score: 3 Okay
Needs Significant work
There’s a lot to like:
The weaknesses in this performance domain largely flow from what is missing. This includes:
‘The Development Approach and Life Cycle Performance Domain addresses the strategic approach to delivering the project.’
I really struggled with this one. Part of me wanted to score this project performance domain as a 3, ‘Okay’. But, in truth, I think the evidence points to a score of 2, ‘Poor’. My reasons are in the paragraph below, on the weaknesses of this domain.
Score: 2 Poor
A lot of work needed
I think it is a real strength that the PMBOK 7 team looked at this as a Project Performance Domain at all. Some of the content is okay, verging on good. But far from all of it. And, I also quite like the running example.
There are a lot of flaws in what we must consider to be a provisional start to a mature articulation of this project performance domain. The principal weaknesses are:
The Planning Performance Domain contains the knowledge to create and maintain the methods and processes to deliver your project.’
This was the most difficult to assess. If all the content were of the quality of section 2.4.2, Planning Variables, I’d definitely award the Performance Domain a ‘Good’. But it most certainly is not.
Indeed, most of the rest of the main sections are ‘Poor’ at best and maybe even ‘Lacking’. What is the best form of average to use? With different approaches, I get to ‘Okay’, ‘Lacking’ and ‘Poor’!
So, I went with my gut. All of my ratings are subjective, but this one felt more so than the others. I scored the PMBOK 7 Planning Performance Domain a skinny 2: Poor – ‘a lot of work needed’.
Score: 2 Poor
A lot of work needed
Without a doubt, the subsections on estimating and scheduling, along with the introduction to the Planning variables section are good, closing in on excellent.
But I cannot find much else to like about this domain. The problem is that it is a huge topic, which encompasses six or maybe 7 of the 10 Knowledge Areas of earlier PMBOK Guides. Yet the authors allocate similar numbers of pages to the other seven performance domains. They didn’t have a chance.
There are two main things:
I prefer a statement in this section of the PMBOK Guide that is not the formal definition:
‘Project work keeps the project team focused and project activities running smoothly.’
This Domain has little coherence. It needs a lot more work. There are nuggets of good stuff, as there are in all of the Performance Domains. But there are also some serious deficiencies. This Domain takes me close to a rating of 1, Lacking. But its few strengths lead me to a score of 2, Poor.
Score: 2 Poor
A lot of work needed
I like a number of things the team thought to mention. I’d like it better if they did a better job of covering the ground:
The Project Work Performance Domain seems to me to be a mish-mash of odd topics. They feel like they have been dumped here because the authors could find nowhere else to place them.
There is no coherence to this domain, as defined in PMBOK 7. If a ‘Project Work Performance Domain’ were to make any sense, this is not how we would treat it. Rather, this feels like an afterthought, developed solely to be a home for waifs and strays.
I can only assume that the authors created an eighth domain out of this rag-tag of loose ends for one of two reasons. Either:
However, we should also assess the quality of what is there – irrespective of how it belongs together in this performance domain. And my answer here is that it is adequate (good) at best and very poor (lacking) at worst.
‘The Delivery Performance Domain addresses activities and functions associated with delivering the value that the project was undertaken to achieve.’
The challenge in assessing this Project Performance Domain was the limited definition the authors have chosen for it. Maybe this is a weakness. However, on its own terms, the definition means it is easy to assess the content against such a simple definition.
And doing that – which seems the fairest approach – led me to a choice of two options: okay or good. There is work needed. But think there is a lot to like in the Delivery Performance Domain. The three principal subsections are all good, and the one on Deliverables is Excellent. Yes, the authors of the next edition need to fix things. But I assessed these as minor tweaks. The Delivery Performance Domain is solidly Good and I score it a 4.
Score: 4 Good
Would be great, but minor tweaks are needed
The principal strengths of the Delivery Performance Domain are its discussions of:
I’ll list the weaknesses of this performance domain in three categories:
‘The Measurement Performance Domain involves assessing project performance and taking appropriate actions to maintain optimal performance and thereby deliver the promised business value.’
I rate this as the best of the eight domains. I came very close to awarding the Measurement Performance Domain my top score of 5 (Excellent). But there are a few tweaks I’d like to see in the next edition (if it retains the Project Performance Domains). So, I can’t really rate it 5.
But, awarding it a 4 (Good) seemed too mean-spirited. It is better than the Delivery Domain that I did score 4. And my quibbles with it are very minor indeed. So, I went for a rating of 4.5 (Very Good).
Score: 4.5 Very Good
Almost everything I could wish it to be
This is a well-thought-out and well-written domain, with a lot of clear illustrations to support the text. Many of the sections have exceptionally good content and some extend the thinking way beyond what the earlier editions of the PMBOK Guide offered. This section holds very true to the ‘Principles’ approach of PMBOK 7, whilst still offering a wealth of practical ideas and advice. The What to Measure section certainly stands out to me.
This whole domain will add huge value to a Project Manager’s learning and understanding. And the deep insights from seasoned practitioners show more here than in any other domain. There is a lot of thought-provoking content for even experienced Project Managers to savor.
There is not much to say about weaknesses. So, in the spirit of ‘when performance is good, you don’t need to look for weaknesses to moan about’, I shall say nothing more.
My suggestions for additional content are few and none of them are fundamental. I don’t think the authors missed anything important. There are just a few minor things I’d add.
‘The Uncertainty Performance Domain addresses activities and functions associated with the volatile, uncertain, complex, and ambiguous context in which project management happens.’
I struggled to assign a score to the Uncertainty Performance Domain. There are some frankly appalling definitions at the start of the section. However, the body of the performance domain is certainly good. Yes, it needs minor tweaks, but there are moments of excellence.
I scored the Uncertainty Performance Domain 3.5 – Okay tending to Good.
Score: 3.5 – Okay tending to Good
Could be great with significant work in parts, and a few tweaks in others
The linkage between the ‘classic’ approach to project uncertainty (risk management) and the ideas around a VUCA environment makes this an interesting development from discussions in previous PMBOK Guides. It makes this a thoughtful and engaging discussion of the wider concepts around the uncertain and ‘messy’ environment in which we work. In bringing in ideas of complexity, ambiguity, and volatility, the authors have created the space for a richer discussion of project interventions.
The biggest weaknesses are in the definitions of uncertainty, ambiguity, complexity, and volatility.
There are two other weaknesses I’d like to see future editions address.
And there is one big missing item that I would want to see in a revised and updated version: the basic risk process!
One of my projects for 2022 was to produce a set of eight articles to cover each of these 8 Project Performance Domains.
And, to supplement each article, I have also produced a Kindle-exclusive eBook, that will give you all the knowledge you need, to understand the performance domain. These contain both my analysis of the domain, and anything from 6 to 8 additional chapters that look at aspects of the domain in detail.
Please do share your thoughts in the comets below. I shall respond to every contribution.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
48 Top Tips, Tools, and Insights from the PMBOK’s 8 Project Performance Domains
How the Stage Gate Process Will Make You a Better Project Manager
Delegation: How to Get People to Do What They Say They Say They Will
What is a Pre-mortem? …and how do you run one?
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.