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?
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:
- 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
- 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 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:
- The Standard for Project Management
This is an Approved American National Standard (ANSI/PMI 99-01-2021). - 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 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.
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, 7th 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:
- People
- Processes (Technical PM Skills)
- 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.
Learn about Each of the Eight Project Performance Domains
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.
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:
- Introduction to what the performance domain is all about and what it is aiming to achieve. This part includes essential definitions of terms.
- A series of subsections that set out the components of the performance domain
- How the domain relates to the other domains
- 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.
- Completeness
- Approach
- 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, 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.
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:
- Stakeholder
- Team
- Development Approach and Life Cycle
- Planning
- Project Work
- Delivery
- Measurement
- 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:
- The definitions are somewhat tautological. They state the obvious and add little value to the titles
- The desired outcomes are weak and the checks are weaker still.
- Some of the principal content is ‘okay’ at best.
- 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:
- Governance and governance structures
- Procurement and sourcing
- 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
- 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:
- 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. - 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:
- They could not discipline themselves to find more logical alternative homes for these ideas
- 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:
- What’s missing
- Cost management
- Schedule Management
- Configuration Management
- Benefits management
- What’s weak
- Value
- Cost of Change
- Suboptimal outcomes
- 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.
- First, the discussion of volatility is lighter than the others (and missing the key aspect of horizon scanning and situational awareness).
- 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
Learn about Each of the Eight Project Performance Domains
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.
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.
