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

The 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, why do they matter, and how well has the PMI drafted them?

What we cover

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

1. PMBOK 7 and Project Performance Domains
2. What are Project Performance Domains?
3. Why are Project Performance Domains Valuable to us?
4. Relationship between Project Performance Domains and Knowledge Areas
5. Reconciling Project Performance Domains with KAs, APMBoK Sections, and PRINCE2 Themes
6. Critical Assessment: How good are the Eight Project Performance Domains?

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
   This is an Approved American National Standard (ANSI/PMI 99-01-2021).
2. A Guide to the Project Management Body of Knowledge
   This 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 the 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 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.

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 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

Critical Assessment: How good are the Eight Project Performance Domains?

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:

1. Stakeholder
2. Team
3. Development Approach and Life Cycle
4. Planning
5. Project Work
6. Delivery
7. Measurement
8. Uncertainty

Stakeholder

My Definition

In this case, I think the PMBOK 7 definition is spot on:

‘The Stakeholder Performance Domain addresses activities and functions associated with stakeholders.’

Assessment

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

Main Strengths

The Stakeholder Performance Domain is simple, clear, and precise. What is there is good.

Main Weaknesses

One of the definitions is naïve and unhelpful. There is no reference to planning your stakeholder engagement.

Learn More

• Read the full Article:
  Stakeholder Performance Domain: Simplicity and Power You Need to Know
• Get the eBook: 
  Project Management Domains: Stakeholders: Creating a productive working relationship with stakeholders
• Watch the Livestream: 
  Stakeholder Performance Domain: The people we work for and with

Team

My Definition

‘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.’

Assessment

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

Main Strengths

There’s a lot to like:

• Its definitions
• Presence of Servant Leadership – although I’d like to see a little more – possibly in the Models, Methods, and Artifacts chapter
• The elements of team culture
• A decent introduction to emotional intelligence
• The attempt to set up how to tailor your leadership style – although I think the content is seriously lacking

Main Weaknesses

The weaknesses in this performance domain largely flow from what is missing. This includes:

• No link to the description of team development models and how to create a high-performing team
• Absence of any useful discussion of leadership in general
• Diversity and Inclusion
• Virtual (or remote) Teams
• Handling team member stress and building emotional resilience
• Managing key team events like team members leaving
• Competency frameworks for project team members and, particularly Project Management team members
• Relationship to wider organizational culture
• General management skills like delegation and feedback, for example

Learn More

• Read the full Article:
  Team Performance Domain: How to Establish a Base for a Successful Project
• Get the eBook: 
  Project Management Domains: Team: Getting the Best from the People who are Responsible for Performing the Work
• Watch the Livestream: 
  Team Performance Domain: The Four Essentials of Teams

Development Approach and Life Cycle

My Definition

‘The Development Approach and Life Cycle Performance Domain addresses the strategic approach to delivering the project.’

Assessment

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

Main Strengths

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. 

Main Weaknesses

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:

1. The definitions are somewhat tautological. They state the obvious and add little value to the titles
2. The desired outcomes are weak and the checks are weaker still.
3. Some of the principal content is ‘okay’ at best.
4. There are only three key elements to a Performance Domain that I consider should have two more key elements. That means 40 percent of the core content is missing:
   1. Governance and governance structures
   2. Procurement and sourcing
5. The integration between this domain and the section of the PMBOK Guide that follows Project Performance Domains, Tailoring, is weak to non-existent. Yet they should be more closely aligned, with the links more clearly drawn
6. The section on interactions with other domains misses an important one

Learn More

• Read the full Article:
  PMBOK 7 Development Approach Performance Domain: Is it a Missed Opportunity?
• Get the eBook:
  Project Management Domains: Development Approach and Life Cycle: Tailoring the Big Choices
• Watch the Livestream:
  Development Approach and Life Cycle Performance Domain: Time for Tailoring

Planning

My Definition

The Planning Performance Domain contains the knowledge to create and maintain the methods and processes to deliver your project.’

Assessment

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

Main Strengths

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.

Main Weaknesses

There are two main things:

1. Coherence
   This chapter has something of the feeling of a camel – designed by a committee. It is nowhere near as coherent as the plans is encourages us to create. It feels like the authors have prioritized one part of the planning process at the cost of the others. And then, they have created a patchwork of disjointed comments about the other components, with no unity or, dare I say, holistic approach.
2. Agile vs Predictive PM
   The whole section doesn’t say much about planning in an agile project environment. But, by not wanting to overplay the need for planning as a casual acknowledgment of this, it seems therefore to short-change the planning needs of a largely predictive project. Rather than being an equal assessment of planning on both ends of the spectrum, we have poor service to each.

Learn More

• Read the full Article:
  Planning Performance Domain: How to Plan a Solution to Meet Your Goals
• Get the eBook:
  Project Management Domains: PLANNING: How to Plan a Solution to Meet Your Goals
• Watch the Livestream:
  Project Planning Domain: Preparing Your Project for Success

Project Work

My Definition

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.’

Assessment

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

Main Strengths

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:

• Mention of lean production methods and retrospectives or lessons learned in the section on Project Processes
• The focus on waste (and reference to health and safety) in the section on physical resources
• The section on procurement is weak, but at least it exists – there is nothing else about the topic in PMBOK 7
• The section on monitoring new work and changes does articulate the key points very clearly and succinctly
• Mention of knowledge management and explicit versus tacit knowledge in the section on Learning throughout the Project

Main Weaknesses

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:

1. They could not discipline themselves to find more logical alternative homes for these ideas
2. Numerology came to bear… Perhaps they did not like the number 7 – it is, after all, an odd number and sometimes viewed as sinister. And it is also prime. Or maybe they wanted to avoid copying the heavy use of 7 themes, processes, and principles in PRINCE2

The Quality of the Content of the Project Work Performance Domain

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.

Learn More

• Read the full Article:
  Project Work Domain: The Processes to Enable Effective Project Management
• Get the eBook:
  Project Management Domains: PROJECT WORK: The Processes to Enable Effective Project Management
• Watch the Livestream:
  Project Work Domain: Get the Job Done

Delivery

My Definition

‘The Delivery Performance Domain addresses activities and functions associated with delivering the value that the project was undertaken to achieve.’

Assessment

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

Main Strengths

The principal strengths of the Delivery Performance Domain are its discussions of:

• Value
• Deliverables (Excellent)
• Cost of Quality (Excellent)

Main Weaknesses

I’ll list the weaknesses of this performance domain in three categories:

1. What’s missing
   1. Cost management
   2. Schedule Management
   3. Configuration Management
   4. Benefits management
2. What’s weak
   • Value
   • Cost of Change
   • Suboptimal outcomes
3. What needs fixing
   • Cost of Change

Learn More

• Read the full Article:
  Delivery Performance Domain: How to be Clear What You Commit to Deliver
• Get the eBook:
  Project Management Domains: DELIVERY: How to be Clear What You Commit to Deliver
• Watch the Livestream:
  Project Delivery Domain: Realizing Project Benefits

Measurement

My Definition

‘The Measurement Performance Domain involves assessing project performance and taking appropriate actions to maintain optimal performance and thereby deliver the promised business value.’

Assessment

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

Main Strengths

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.

Main Weaknesses

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.

Learn More

• Read the full Article:
  Monitoring and Controlling: What is The PMBOK 7 Measurement Performance Domain?
• Get the eBook:
  Project Management Domains: MEASUREMENT: Monitoring and Controlling: What is The Measurement Performance Domain?
• Watch the Livestream:
  Measurement Performance Domain: Monitor & Control Your Project

Uncertainty

My Definition

‘The Uncertainty Performance Domain addresses activities and functions associated with the volatile, uncertain, complex, and ambiguous context in which project management happens.’

Assessment

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

Main Strengths

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.

Main Weaknesses

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. 

1. First, the discussion of volatility is lighter than the others (and missing the key aspect of horizon scanning and situational awareness).
2. Second, the discussion of complexity is just crying out to draw more clearly upon the ideas of the Cynefin Framework

And there is one big missing item that I would want to see in a revised and updated version: the basic risk process!

Learn More

• Read the full Article:
  Uncertainty Performance Domain: How to Deal with Risk in a VUCA Context
• Get the eBook:
  Project Management Domains: UNCERTAINTY: Uncertainty Performance Domain: How to Deal with Risk in a VUCA Context
• Watch the Livestream:
  Uncertainty Performance Domain: Managing Projects in the Presence of VUCA and 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.