The Uncertainty Performance Domain is the last of eight in the PMI’s 7th Edition of its PMBOK Guide. It tackles the twin topics of the VUCA context in which Project Managers work, and how to deal with the risks that this environment creates.
This is the last of our series of eight articles, covering the eight Project Performance Domains of PMBOK 7. For a general introduction to these domains, check out our article, Project Performance Domains: Do You Know What they Are and Why they Matter?

Structure of this article
In this article, we will examine:
- What is the Uncertainty Performance Domain?
- Basic Principles of the Uncertainty Domain
- PMI’s Description of the Components of the Uncertainty Performance Domain
- Critical Evaluation of the Uncertainty Domain
- What Else We Should Include in the Uncertainty Performance Domain?
- How the Uncertainty Performance Domain Relates to the other Project Management Domains
What is the Uncertainty Domain?
This is one of the most clearly defined and logical of the eight Performance Domains. The definition makes sense, the content is coherent, and it all ties together well with the outcomes. So, let’s start at the beginning…
The PMBOK Definition of the Uncertainty Performance Domain
The Uncertainty Performance Domain has one of the shortest and strongest definitions among the eight domains. The Stakeholder Domain’s definition is two words shorter and equally precise.
‘The Uncertainty Performance Domain addresses activities and functions associated with risk and uncertainty.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
In many ways, this looks rather like a ‘theory section’ to a Risk Management Knowledge Area. And it is none the worse for that!
Our Expanded Definition of the Uncertainty Performance Domain
I like the definition PMBOK 7 offers. But I also observe that the authors use the VUCA framework to discuss this domain. VUCA stands for four complementary characteristics of many project contexts:
- Volatile
- Uncertain
- Complex
- Ambiguous
We’ll look at the definitions shortly. But for now, let’s note that the authors use uncertainty in two ways:
- As a component of this four-part descriptor, VUCA
- As a broad concept embracing the whole VUCA framework
I shan’t go as far as to say that the authors confuse the term ‘uncertainty’, But I shall say that they are in great danger of confusing their readers.
And, it is in this second sense that they use the term in their definition (I think).
I’d also note that risk is an inevitable consequence of uncertainty: we have risk where there is uncertainty. So, do define the domain in terms of i is tautological. That is, it says the same thing twice.
So, should the definition include both risk and uncertainty? And should it include the concepts of volatility, complexity, and ambiguity?
I propose this alternative definition, which is more consistent with:
- The treatment of the subject in the Performance Domain
- The principles-based approach of PMBOK 7 and the fact that risk is a necessary consequence of the VUCA context
‘The Uncertainty Performance Domain addresses activities and functions associated with the volatile, uncertain, complex, and ambiguous context in which project management happens.’
The Expected Outcomes for the Uncertainty Performance Domain
PMBOK 7 goes on to define the domain in terms of seven desired outcomes, which demonstrate that the project team has managed it effectively:
- An awareness of the environment in which projects occur, including, but not limited to, the technical, social, political, market, and economic environments.
- Proactively exploring and responding to uncertainty.
- An awareness of the interdependence of multiple variables on the project.
- The capacity to anticipate threats and opportunities and understand the consequences of issues.
- Project delivery with little or no negative impact from unforeseen events or conditions.
- Opportunities are realized to improve project performance and outcomes.
- Cost and schedule reserves are utilized effectively to maintain alignment with project objectives.
Let’s take a look at these in turn.
An awareness of the environment in which projects occur, including, but not limited to, the technical, social, political, market, and economic environments.
Situational awareness is critical, and PMI rightly places an increasing emphasis on its Project Managers having Business Acumen. The list of examples borrows heavily from the PEST, or PESTLE framework:
- Political
- Economic
- Social
- Technological
- Legislative
- Environmental
Proactively exploring and responding to uncertainty.
I’d hope this one is obvious!
An awareness of the interdependence of multiple variables on the project.
This is a nod to complexity. Projects have a lot of interacting parts and each one adds to its complexity and hence to the levels of risk. Take a look at our video:
The capacity to anticipate threats and opportunities and understand the consequences of issues.
A core part of risk management is anticipating potential risks. And the authors nicely drop into this outcome the fact that risks can have either:
- Negative outcomes (Threats), or
- Positive outcomes (Opportunities)
They also include issues and issue management (which I once described as PMBOK’s Missing Process).
Project delivery with little or no negative impact from unforeseen events or conditions.
This is the ideal we aim for. We either foresee all potential surprises, or we can deal with them so elegantly that their impact on our project is negligible.
Opportunities are realized to improve project performance and outcomes.
This is a nice inclusion. It fully recognizes the ‘light side’ of risk. Opportunities are the unexpected changes that can have a positive impact on our project, as long as we are ready to recognize them and capitalize on them.
Cost and schedule reserves are utilized effectively to maintain alignment with project objectives.
Shift happens. You will encounter unexpected events. And that is why we build contingency reserves into our budgets and schedules. What we don’t want is to have to use them up on mistakes, foolishness, or – most likely – handling things we simply missed out of our plans.
Verifying the Outcomes from the Uncertainty Performance Domain
For each domain, PMBOK 7 also sets out ‘checks’ by which we can assess project performance against each of the outcomes for the performance domain.
I will interpret these checks in my own words.
An awareness of the environment in which projects occur, including, but not limited to, the technical, social, political, market, and economic environments.
The check here is to incorporate environmental factors in risk evaluation and responses. This is fine. But I’d like to have seen a further comment about regular horizon scanning. Take a look at these two videos:
- How to Survey Changes to Your External Business Environment
- How to Anticipate Future Budget Challenges to Your Project
Proactively exploring and responding to uncertainty.
The PMBOK wisely requires we align risk responses to our priorities – in terms of constraints like budget, schedule, and performance. But this check says nothing about the requirement in the outcome to explore uncertainty.
An awareness of the interdependence of multiple variables on the project.
Here is one of PMBOK 7’s lazy checks, that state the blindingly obvious. We should take actions to address volatility, complexity, and ambiguity. This would have been a perfect place to direct readers the item in the chapter on Model, Methods, and Artifacts on the Cynefin Framework.
The capacity to anticipate threats and opportunities and understand the consequences of issues.
I think it is reasonable to specify systems and require they be robust. Yet this feels thin to me.
Project delivery with little or no negative impact from unforeseen events or conditions.
This one is good. It requires we meet scheduled dates and hit our budgets within a variance threshold.
Opportunities are realized to improve project performance and outcomes.
This check, however, simply restates the outcome, adding only that there are ‘established mechanisms’.
Cost and schedule reserves are utilized effectively to maintain alignment with project objectives.
The emphasis here is on threat prevention, which I like. But I’d like to see a mention of option evaluation and decision making, to pick up on the ‘effective utilization’ of reserves, when the need arises.
Important Definitions within the Uncertainty Performance Domain
In the introduction to the Uncertainty Performance Domain, PMBOK 7 highlights (in a box), five key definitions of jargon terms:
- Uncertainty
- Ambiguity
- Complexity
- Volatility
- Risk
I am sad to say that these are among the weakest in the whole of PMBOK 7. Yet these are important, so let’s look at them one at a time.
Uncertainty
‘A lack of understanding and awareness of issues, events, paths to follow, or solutions to pursue.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
This is fine as far as it goes. But it refers mainly to unknown unknowns (ontological uncertainty) where we have a complete lack of knowledge. Arguably it also includes known unknowns (epistemological uncertainty) where we are aware of our lack of knowledge.
But it clearly misses out on known knowns (aleatory, or statistical uncertainty), where we understand the issues fully, but still have no certainty. A good example is weather, and its impact on construction schedules and costs. We understand the weather well. But, over the course of a three-year project, the weather events remain uncertain.
Score 1 out of 2
Ambiguity
‘A state of being unclear, having difficulty in identifying the cause of events, or having multiple options from which to choose.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
No. This is simply wrong. Ambiguity is all about our inability to ascribe a unique interpretation to events, with confidence. As a result, meanings are unclear.
Note: I did wonder if the big difference in my understanding of ambiguity and that of the authors was due to the difference between UK and US English. So, I checked an American-English dictionary, Merriam-Webster online: ‘can be understood in two or more possible ways’.
Score 0 out of 2
Complexity
‘A characteristic of a program or project or its environment that is difficult to manage due to human behavior, system behavior, and ambiguity.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
Let’s leave aside the implied dependence on ambiguity (which is wrong). After all, they don’t have a good definition of that word to work from!
Complexity arises from two things:
- Multiple interactions of multiple parts (which, in itself, only creates complication
- The inscrutable (hard to understand) nature of some or all of thiose interactions
Yes, human and system behaviors give rise to complexity. But they don’t define it. And a complex system can give a wholly unambiguous response.
For goodness sake, authors. You are clearly aware of the Cynefin Framework (you put it in your Models, Methods, and Artifacts chapter). So why did you not bother to understand it?
Score 0 out of 2
Volatility
‘The possibility for rapid and unpredictable change.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
At last! A halfway decent definition. Volatility is about the capacity for rapid change. And it can be unpredictable. But it is not necessarily so, We may know what state a situation may flip to. Volatility is about the flip being sudden and dependent on a subtle shift in conditions.
Score 1 out of 2
Risk
‘An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project outcomes.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
Phew. A definition that is spot on. It is less concise than my own: ‘Uncertainty that can affect outcome’, but makes explicit that the effect can be positive or adverse.
Score 2 out of 2
To sum up
As a whole, I don’t think I exaggerate if I describe this set of five definitions as a horror-show. I score it 4 out of 10. It really lets the community down, in my opinion.
Basic Principles of the Uncertainty Domain
The rest of the Introductory section starts with a better definition of uncertainty than the formal one above it: ‘Uncertainty in the broadest sense is a state of not knowing or unpredictability’. YES!
Sadly, the authors follow this up with three examples of nuance to this which, respectively:
- Make a circular argument that risk is associated with not knowing the future
- Refer to a wholly wrong interpretation of ambiguity
- Use the term complexity appropriately
They then go on to correctly state that we need to understand the environment and give examples using much of the PESTLE framework.
PMI’s Description of the Components of the Uncertainty Performance Domain
The bulk of the Uncertainty Performance Domain is taken up with sections on:
- General Uncertainty
- Ambiguity
- Complexity
- Volatility
- Risk
So, we’ll examine each of these in turn.
General Uncertainty
This is a strong section that identifies four powerful ways to respond to uncertainty:
- Gather Information
It may seem obvious, but it is an essential point. One way to reduce (epistemological and, to a degree, ontological) uncertainty is to learn more. - Prepare for Multiple Outcome
Not just analyzing scenarios; but put in place contingency plans for different outcomes. - Set-based Design
This starts with multiple design solutions and refines the range of options as we learn more. It is the alternative to point-based design that settles on a single solution early. It trades off flexibility and risk reduction, against increased cost - Build in Resilience
This is about procedures and processes, and individual human resilience (psychological, emotional, and physiological). Resilience is the ability to respond to adversity without a substantial degradation of performance.
Ambiguity
It’s clear from this short section that the team does understand the term ambiguity. It distinguishes conceptual ambiguity from situational ambiguity. This is a nice discussion.
- Conceptual Ambiguity
A statement, question, or argument can have different meanings, and none is evidently the correct one.
The solution lies in a combination of riles and definitions, alertness to possible alternative meanings, and a willingness to ask questions and challenge assumptions. - Situational Ambiguity
When it is not clear how a situation will necessarily play out. Therefore multiple outcomes are possible.
The solution lies in investigation (PMBOK 7 refers to ‘progressive Elaboration’), experiment, and prototypes.
Complexity
Once again, the authors show a clearer understanding of the term in the main body of the domain than in the definitions section. There is strong content o ways to work with complexity, which are grouped into:
- Systems-based approaches
- Decoupling interdependent parts by breaking the links between them and so simplifying the system and reducing the complexity
- Simulating the complex system to better understand it.
- Reframing the system
- Assessing it form different points of view (‘Diversity’)
- Balancing different analysis methods, like forecasting against lagging indicators
- Process-based approaches
- Iteration and incrementalism, to build complexity over time, allowing us to understand what we have before adding to it
- Constant stakeholder engagement to learn from people with other perspectives
- Building in redundancy and fail-safe mechanisms to mitigate the risk of critical component failure
Volatility
The authors remind us that volatility can have adverse impacts on cost and schedule and propose two approaches to mitigate its impact:
- Analyzing alternative options
- Holding budget and schedule reserves
However, what they miss is the value of horizon scanning that can identify the first signs of changes. The faster we go around the Monitor and Control Loop (or the OODA Loop), the more likely we are to be able to reduce the impact of volatility.
Risk
This is the biggest section within the Uncertainty Performance Domain. And that’s what we’d expect. This is, after all, the spiritual child of the Risk Management Knowledge Area!
It introduces important concepts like:
- Threat and Opportunity
- Risk Threshold and Risk Appetite (related to Risk Tolerance)
Threats
The section has a five-part set of strategies for dealing with threats (adverse risks). These are the five that appeared in the former edition of the PMBOK Guide, PMBOK 6:
- Avoid
- Escalate
- Transfer
- Mitigate
- Accept
I compared them to other frameworks in my article, Risk Response Strategies: Full & Revised Roundup. This diagram summarizes the comparison.

In short, my critique is that:
- Mitigate is really two strategies: to reduce the impact of the threat or to reduce its likelihood.
- Acceptance can be either with or without a contingency plan. Indeed, the text in PMBOK 7 highlights this. See the point below this list.
- I don’t believe Escalation is a strategy for dealing with a threat. It’s a strategy for putting it off and getting somebody else to deal with it!
The text under Accept in PMBOK 7 first says it ‘acknowledges the existence of a threat, but no proactive action is planned.’ But then adds that it ‘can include developing a contingency plan’ – which is a proactive step.
We have a Vast Array of Resources about Project Risk Management
The place to start is our Ultimate Guide to Project Risk Management.
For the full set of resources, which will allow you to surgically find what you need, go to our Project Risk Management category page.
Opportunities
The second (of four) subsections under risk looks at five ways to respond to opportunities, which mirror the threat responses. We can:
- Exploit
- Escalate
- Share
- Enhance
- Accept
And, I have the same critique of the ‘Escalate’ response as above.
Management and Contingency Reserve
This is a short paragraph reminding us that:
- Contingency reserve is the time or budget we set aside to handle known risks
- Management reserve is the time or budget we set aside to handle unanticipated events
Usually, in my experience, Project Managers have a large measure of control over and access to the contingency reserve. However, the management reserve tends to be under the authority of the project’s sponsor, client, or steering group.
Risk Review
I like the reminder to build in a regular periodic review of risks and our planned responses. This can be at:
- Weekly status meetings
- Daily stand-ups
- Retrospectives and Lessons Learned meetings
- Demonstrations and tests
Critical Evaluation of the Uncertainty Performance Domain
I’m going to evaluate each of the eight Project Performance Domains in the 7th edition of the PMBOK Guide on a 5-point scale, of:
- Lacking
Little more than a passing mention of what’s important - Poor
A lot of work needed - Okay
Needs Significant work - Good
Would be great but minor tweaks needed - Excellent
Everything I could wish it to be
I am struggling with assigning a score to the Uncertainty Performance Domain. Most of my visceral response to it comes from the frankly appalling definitions at the start of the section. These are poor. Indeed, I scored them 4/10, which is precisely a 2 on a 5-point scale.
However, the body of the performance domain is certainly good. Yes, it needs minor tweaks, but not significant work. Indeed there are moments of excellence.
I could split the difference between the 2 of the definition section and the 4 of the body to give a 3. But that seems to unfairly weight a few sentences – albeit important definitional ones.
I created a bad precedent with the previous, Measurement Domain. I gave it a 4.5. But a precedent it is, and I am returning to it.
I score the Uncertainty Performance Domain 3.5 – Okay tending to Good. It needs significant work in parts and minor tweaks in others.
Strengths of The PMBOK 7 Uncertainty Domain
I do think that 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.
This is 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.
Weaknesses of The PMBOK 7 Uncertainty Domain
The obvious weakness (which I have hammered to death) is 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
What Else We Should Include in the Uncertainty Performance Domain?
I think there is one big missing item that I would want to see in a revised and updated version.
Basic risk process
I know this is primarily a ‘how’ thing and that PMBOK 7 strives to be about principles. But the fundamental Identify-Analyze-Plan-Act-Monitor process is so fundamental, I consider it a principle. It is no less a principle than the list of risk responses.
How the Uncertainty Performance Domain Relates to the other Project Management Domains
It is in this section that the authors address what, as I read the chapter, I increasingly thought they may have missed. Credit where it is due. They make an explicit link to tailoring here. Our use of Adaptive, Predictive, and hybrid approaches is, to a large degree, driven by our response to the different levels, types, and priorities of uncertainty.
What are your Thoughts about the Uncertainty Performance Domain?
Please share what you think of the way PMI has handles the Uncertainty Performance Domain and any comments you have about it. I’ll be sure to respond to any comments you post below.
Project Management Domains eBook Series
This is a Chapter from the Uncertainty volume of our Kindle Exclusive Project management Domains ebook series.
