Stakeholder Performance Domain: Simplicity and Power You Need to Know

In the 2021 seventh Edition of its Guide to the Project Management Body of Knowledge (PMBOK Guide), PMI introduced eight Project Performance Domains. In this article, I am going to describe and evaluate the first of these, the Stakeholder Performance Domain.

This is the first 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 Stakeholder Performance Domain?
• Basic Principles of the Stakeholder Domain
• PMI’s Description of the Components of the Stakeholder Performance Domain
• Critical Evaluation of the Stakeholder Domain
• What Else We Should Include in the Stakeholder Performance Domain?
• How the Stakeholder Performance Domain Relates to the other Project Management Domains

Good Background

As background, you may like these articles about PMBOK 7 and the Project Performance Domains:

• PMBOK Guide 7th Edition: Your 20 Most Important Questions Answered
• PMBOK 7: 7th Edition of the PMI’s Guide to the Project Management Body of Knowledge – with Nader Rad
• Project Performance Domains: Do You Know What they Are and Why they Matter?

What is the Stakeholder Performance Domain?

In many ways, the Stakeholder Performance Domain is the most straightforward of the eight project management domains in PMBOK 7. 

• The definition is simple and uncontentious 
• It embraces a tight range of content
• There is little we need to add to it
• It maps most closely to one of the pre-existing PMBOK 6 Knowledge Areas

These make it an ideal starting place. But, of course, it is also a good place to start because of the truth in one of my favorite ‘rules’ of project management:

‘Your stakeholders will determine the success, or not, of your project.’

This makes stakeholder engagement a critical project activity. So, this domain of knowledge is fundamental. Indeed, while Tim Lister asserts that:

‘Risk Management is how adults manage projects.’

I would respond that:

‘Stakeholder Engagement is how sophisticated adults manage projects.’

The PMBOK Definition of the Stakeholder Performance Domain

As I said above, the PMBOK 7 definition of the Stakeholder Performance Domain is simple and uncontentious:

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

A Guide to the Project Management Body of Knowledge, 7^th Edition
Project Management Institute, 2021

Our Expanded Definition of the Stakeholder Performance Domain

Whilst I’d love to be able to add something to this, I can see no way to improve it. The statement is well-crafted in its:

• Breadth
• Simplicity
• Precision

In the case of the Stakeholder Performance Domain, the PMI‘s team has got it spot-on.

The Expected Outcomes for the Stakeholder Performance Domain

PMBOK 7 goes on to define the domain in terms of three desired outcomes. These demonstrate that the project team has executed it effectively:

1. A productive working relationship with stakeholders throughout the project
2. Stakeholder agreement with project objectives
3. Stakeholders who are project beneficiaries are supportive are satisfied while stakeholders who may oppose the project or its deliverables do not negatively impact project outcomes.

Let’s take a look at these in turn.

Productive Working Relationship with Stakeholders

I like this outcome statement a lot. It reflects my conviction that we need to engage positively with all of our stakeholders, to build good working relationships with all of them. And this should be regardless of whether they agree with us or not – and whether we find their approach comfortable or not.

The secret here is to respect all your stakeholders. You may not respect their opinions. And you certainly do not need to respect (or even accept) discourteous behaviors. But remember that every stakeholder is a person trying to do what they feel is best for them.

Stakeholder Agreement

I worry that this outcome is a little glib and overoptimistic. Stakeholder acceptance of project objectives may be achievable, but to expect all stakeholders to agree with your project objectives in all cases is plainly ridiculous.

And your failure to achieve this universal approval is likely to be more of a reflection on the nature of the project and the diversity of your stakeholders than of the capabilities and diligence of you and your team.

This is especially going to be the case for large public policy and infrastructure projects. Because, in these, it is rarely possible to design a project that has no degree of controversy or compromise.

Beneficiaries and Opposers

This outcome statement would be simpler and more useful if split into its two components, as two statements.

1. Stakeholders who are project beneficiaries are supportive are satisfied

This makes immediate sense. Don’t alienate your supporters. Keep them engaged and enthusiastic. If anything, ‘satisfied’ is a low bar. Why not aim for ‘delighted’?

2. Stakeholders who may oppose the project or its deliverables do not negatively impact project outcomes

This is a great outcome. You may not be able to win over every stakeholder (see above). But a sensible objective is to at least neutralize any adverse impact their opposition may have on the outcomes of your program.

Verifying the Outcomes from the Stakeholder 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.

Productive Working Relationship with Stakeholders

Stating the obvious, PMBOK starts by suggesting we can observe productive working relationships. In fact, this tells us nothing about what we will observe. We should be looking for:

• Respectful, courteous interaction – wuth good quality listening
• Two-way sharing of points of view
• A suitable frequency of dialogue
• Clarity over the distinctions between information, opinion, and emotional response

It then goes on to mistake movement along a ‘continuum of engagement’ as a proxy for relative levels of satisfaction. In fact, in my experience, the more stakeholders dislike what you are doing, the more actively they will resist it. But, strong resistance represents a high level of engagement.

Stakeholder Agreement

PMBOK 7 defines this in the negative. It asserts that a lot of changes to scope or specification suggest poor engagement (wrong) and alignment with the project’s objectives. So, what, PMI, does indicate agreement?

I shan’t struggle to answer this question of mine because, as I stated above, I think this is an unreasonable outcome to set as a standard for good stakeholder engagement. But, in outline, I’d expect to see active stakeholder support (even at low levels) as an indicator of stakeholder agreement with the project objectives.

Beneficiaries and Opposers

Again, stating the bleedin’ obvious, PMBOK 7 tells us stakeholder behavior is what we can look for. What behavior, PMI?

However, I do agree that we can determine stakeholders’ support or opposition with surveys, interviews, and focus groups. And also that our issues and risk registers are a good place to look for signs of opposition.

But, crucially, how can we measure that stakeholders who oppose what we are doing have had no effect on our outcomes? PMI does not address this. Partly, I would say, by setting clear outcome goals at the start (a challenge for highly adaptive projects). But, if we end up with different outcome, we have to ask:

1. How do we know who (or what) to attribute this to?
2. Why should not stakeholders with divergent views influence our outcomes? Maybe this is a ‘Good Thing’!

Checks: In Conclusion

This part of the Stakeholder Performance Domain (section 2.1.3) is by far the weakest part of the domain. In fact, I’d go so far as to say it is woeful. It shows shallow thinking and therefore all the signs of being rushed.

Important Definitions within the Stakeholder Performance Domain

In the introduction to the Stakeholder Performance Domain, PMBOK 7 highlights (in a box), two key definitions of jargon terms:

Stakeholder: An individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.

A Guide to the Project Management Body of Knowledge, 7^th Edition
Project Management Institute, 2021

There is nothing wrong with this, aside from being rather wordy!

I confess to preferring my own definition:

Stakeholder: Anyone with an interest in your project – whether affected by its outcome or process, or with an ability to affect its outcome or process.  

Be on the Inside: Decode the Jargon of Project Management, 2^nd Edition
Mike Clayton, OnlinePMCourses

They also define:

Stakeholder Analysis: A method of systematically gathering and analyzing quantitative and qualitative information to determine whose interests should be taken into account throughout the project.

A Guide to the Project Management Body of Knowledge, 7^th Edition
Project Management Institute, 2021

No, no, no!
I hate this definition.

The second part of this does not represent the purpose of stakeholder analysis. We analyze stakeholders so we can determine:

• How best to communicate with our stakeholders
• Which ones are likely to take what views
• What we can learn from them
• How best we can influence them
• Which stakeholders to prioritize 
  (given that we should take into account the interests of all stakeholders, we will need to put some ahead of others)

Basic Principles of the Stakeholder Domain

The introductory section to the Stakeholder Performance Domain is necessarily brief. The PMBOK Guide has never been designed to provide a thorough education in any of the methods or tools of Project Management. So, here we have an outline introduction. And it is sound.

Who are Your Stakeholders?

PMBOK 7 reminds us that:

• Stakeholders may come from inside or outside the sponsoring organization.
• And may take a positive, negative, or neutral approach to your project.
• They come and go and so we may have different stakeholders to deal with at different stages of our project.
• So too, their interests, influence, and power may shift.

This all demands that Project Managers cultivate our interpersonal, communication, and leadership skills.

Proximity Map

Figure 2-2 is a simple proximity map. It illustrates different stakeholders at different levels of closeness/distance from the core of your project. At the center are the Project Manager and your team. Here is an illustration of a more sophisticated Proximity Map, from my 2014 book, The Influence Agenda: A Systematic Approach to Aligning Stakeholders in Times of Change.

The Stakeholder Engagement Process

PMBOK 7 offers us a 6-stage Stakeholder Engagement cycle in Figure 2-3. The six stages are:

1. Identify
2. Understand
3. Analyze
4. Prioritize
5. Engage
6. Monitor

I think this is weak. Let me start by sharing my 5-stage cycle (again from my book, The Influence Agenda). Then I will highlight the differences.

The first two the three differences are minor, and the third is crucial.

Difference 1: Review – Monitor and Act – Engage 

I use the word Review for the final stage, PMI uses the word Monitor. There is a significant difference in the meaning of the words, but the text of the PMBOK Guide makes it clear to me the authors intend Monitor to mean Monitor and Review, just as I intend Review to imply the monitoring process that provides the evidence for review.

Likewise, the difference between Act and Engage is nothing more than a choice of words. Again, maybe Act is a simpler word, but let’s not quibble.

Difference 2: Analyze

I have one stage, labeled Analyze. It includes three stages in the PMBOK 7 process: Understand, Analyze, and Prioritize. I could argue that it is simpler and loses nothing to combine them. But this is a small point too.

Difference 3: Plan

As a project manager, you will always plan your approach before acting. Clearly that is so. 

Yet PMI has no planning stage. I think that loses too much. Indeed, you need to plan at different levels:

• Your whole stakeholder engagement campaign
• Individual approaches to each stakeholder or stakeholder group
• Specific communications campaigns at project stages that need them

I cannot help but think this is a HUGE oversight by the authors and reviewers of PMBOK 7.

PMI’s Description of the Components of the Stakeholder Performance Domain?

PMBOK 7 has a short section for each of the stages in its Stakeholder Engagement cycle – although it merges Understand and Analyze into one section (partly endorsing my point above!).

Three of these offer little more than a basic explanation of the label. The exceptions are ‘Understand and Analyze’ and ‘Engage’.

Understand and Analyze

I like the listing of factors to take into account when analyzing stakeholders. It goes beyond the familiar ‘Power-Impact-Attitude’ that we so often see presented as a definitive list. For copyright reasons, I shan’t duplicate the list of 8 items (plus ‘other’). 

So, here instead is the far more detailed ‘Four Dimensions’ framework from my book, The Influence Agenda.

D1: Understand the Nature of their Stake

• Needs
• Special Needs
• Interests – eg: financial, emotional, 
• Rights
• Ownerships
• How they are affected – the nature and severity of the impact

What is their agenda?

D2: Understand the Intensity of their Stake

• Attitude
• Interest
• Impact
• Power
• Power of their contacts
• Influence
• Commitment
• Level of partisanship/impartiality
• Urgency (how urgently do you need to respond to them?)
• Legitimacy (how appropriate is their involvement?)

What is their priority/saliency?

D3: Understand their Background and Attitudes

• What is their past behaviour?
• Prior experience
• Prior knowledge and information
• Current opinions
• Expectations
• Preferences
• Prejudices
• Motivations
• Values

What do we know about the way they tick?

D4: Additional Factors for Groups

• Demographic make-up
• Internal dependencies, connections, and political dynamics
• Factions
• Key players and positions
• Internal dynamics
  • formal / constitutional
  • structural / operational
  • informal / political
• History and background
• Mission, vision and goals
• Values, culture and style
• Strengths and weaknesses

How does the group work?

In the Book, you will also find the 10 questions to ask (and answer) that will help you with your stakeholder engagement planning.

Engage

This section makes some important distinctions between:

• Verbal and written communication media
• Formal and informal communication
• Push and pull communication

Critical Evaluation of the Stakeholder Domain

I’m going to evaluate each of the eight Project Performance Domains in the 7^th edition of the PMBOK Guide on a 5-point scale, of:

1. Lacking
   Little more than a passing mention of what’s important
2. Poor
   A lot of work needed
3. Okay
   Needs Significant work
4. Good
   Would be great but minor tweaks needed
5. Excellent
   Everything I could wish it to be

I want to score this a 4, Good. But, the absence of planning from the process is for me, too big to represent the need for a minor tweak. So, with regret, I am going to need to score this a (possibly harsh) 3 out of 5 and call this section ‘okay’.

Strengths of The PMBOK 7 Stakeholder Domain

It’s easy to state what I like about this section:

1. It’s simplicity. It is simple, clear, precise.
2. What is there is good. It is solid content

Weaknesses of The PMBOK 7 Stakeholder Domain

And it’s equally easy to state what I don’t like. Setting aside minor complaints, I don’t like:

1. The second of the three definitions of effective execution (stakeholder agreement with project objectives) is naïve and unhelpful
2. The absence of any reference to planning your stakeholder engagement 

What Else We Should Include in the Stakeholder Performance Domain?

The obvious extra thing to include here is the planning stage of the stakeholder engagement process. But what else could we include?

The Association for Project Management’s Body of Knowledge 7^th Edition (APMBoK) points us to several relevant disciplines, within this domain. In section 3.1, we see content on:

• Social content and socio-political complexity
• Engagement and Influence
• Facilitation
• Conflict Resolution

If we avoid being as generic as ‘communications skills’ or ‘interpersonal skills’, I would suggest that, within the Project Management Domain of Stakeholders, we should include:

• Human Psychology (also important for the Team domain)
• Influence and Persuasion
• Political Acumen
• Facilitation Skills
• Presentation Skills
• Conflict Management, Mediation, and Arbitration

How the Stakeholder Performance Domain Relates to the other Project Management Domains

I could make an argument for placing any of a number of domains at the center of your Project Management. Indeed, there are a number of knowledge areas (like value/benefits management) that sit inside one or more domains, which could equally be central.

But, let’s face it, stakeholders:

• Determine the value of what we are doing
• And help us set our scope
• Create many of our risks
• Yet hold the resolution to many of our risks, issues, and problems
• Are a key factor in creating our plans
• And our development approach
• Can get involved in our delivery – in a supporting or frustrating role!
• Are an essential part of our project work
• Include our teams
• Set the measures of quality and success against which we monitor and control

It is not for nothing that many Project Managers repeat the statement that Project Management is 80 percent communication. And who are we communicating with: partly our teams and partly our wider stakeholder group. 

It may not be statistically precise, but in essence, this means Project Management is 40 percent stakeholder engagement and 40% team management. In this sense, stakeholder engagement is at least as important as anything else, probably more important (in terms of time commitment) than mush else, and clearly central to a lot of what we do.

What are your Thoughts about the Stakeholder Performance Domain?

Please share what you think of the way PMI has handles the Stakeholder 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 Stakeholders volume of our Kindle Exclusive Project Management Domains ebook series:

Project Management Domains: Stakeholders
Stakeholder Performance Domain: Creating a productive working relationship with stakeholders

Check out the whole series here.