Project Performance Domains: Do You Know What they Are and Why they Matter?

PMI introduced 8 Project Performance Domains into the 7^th 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, and why do they matter?

What we cover

Those are the two questions we will answer in this article. And, to do so, I’ve split it into five sections:

• PMBOK 7 and Project Performance Domains
• What are Project Performance Domains?
• Why are Project Performance Domains Valuable to us?
• Relationship between Project Performance Domains and Knowledge Areas
• Reconciling Project Performance Domains with KAs, APMBoK Sections, and PRINCE2 Themes

PMBOK 7 and Project Performance Domains

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 7^th 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:

1. The Standard for Project Management, which is an Approved American National Standard (ANSI/PMI 99-01-2021).
2. A Guide to the Project Management Body of Knowledge, which sets out PMI’s assessment of the knowledge and skills we need, to be a professional Project Manager.

Both parts saw a revolutionary overhaul, bearing no resemblance in style and structure to the 6^th 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.

PMI and Performance Domains

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:

• The Standard for Program Management
• The Standard for Portfolio Management

What are Project 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, 7^th Edition
Project Management Institute, 2021

Project Performance Domains are sets of activities that run throughout a project.

Umm, aren’t there Three Performance Domains? 

Please don’t confuse PMBOK 7’s eight performance domains with:

1. People
2. Processes (Technical PM Skills)
3. Business Environment. 

These form the basis of both the:

• PMI’s Talent Triangle and
• Examination Content Outline (ECO) for PMI’s Project Management Professional (PMP) exam.

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.

My Definition of Project Performance Domains

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?

What are PMI’s 8 Project Performance Domains?

PMI’s eight Project Performance Domains are:

1. Stakeholders

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.

2. Team

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.

3. Development Approach and Life Cycle

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?

4. Planning

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 planned scope, activities, schedule, resources, budget, and more.

5. Project Work

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. 

6. Delivery

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.

7. Measurement

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.

8. Uncertainty

Uncertainty is in the nature of a project – as are the other components of VUCA: Volatility, Complexity, and Ambiguity. And uncertainty that can have an impact is risk – which volatility, complexity, and ambiguity exacerbate. Here is where you will find all the knowledge and skills of risk management.

How PMBOK 7 Describes each Project Performance Domain

PMBOK 7 treats each of the 8 sections describing the Project Performance Domains in a consistent way. They have four parts:

1. Introduction to what the performance domain is all about and what it is aiming to achieve. This part includes essential definitions of terms.
2. A series of subsections that set out the components of the performance domain
3. How the domain relates to the other domains
4. The outcomes you should expect, and how to evaluate your results

Many of them also have subsections describing relevant aspects of tailoring.

Why are Project Performance Domains Valuable to us?

I will offer you three reasons why this is an important idea that you need to understand.

1. Completeness
2. Approach
3. Integration

Completeness

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, 7^th 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.

Approach

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:

• Purely Predictive (traditional) project management approaches
• Purely Adaptive (agile) project management approaches
• Hybrid project management approaches that draw on the whole project management body of knowledge. Indeed, I think it reasonable to assert that ‘all project management is hybrid project management’.

Integration

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:

• Risk management
• Planning
• Stakeholder engagement
• Procurement

However, these choices are about organizational pragmatics. In a real project, we must integrate our team’s activities across all eight domains.

Relationship between Project Performance Domains and Knowledge Areas

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

Reconciling Project Performance Domains with KAs, APMBoK Sections, and PRINCE2 Themes

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:

• some of the key sections of the Association for Project Management’s Body of Knowledge (APMBoK) 7th edition 
• the 7 themes of PRINCE2
• some of the PMI’s Practice Standards

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 which one I think it best fits with, 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

What are Your Thoughts about the Idea of Project Performance Domains?

Please do share your thoughts in the comets below. I shall respond to every contribution.