The PMBOK 8 Stakeholders Performance Domain: What It Really Covers
The Stakeholders Performance Domain is the part of the Eighth Edition most likely to be read as a description of things a project already does. Identify the stakeholders, write them down, tell them things, ask how they are getting on. A project can do all of that, keep a register accurate to the week, and still end up in the position the domain exists to prevent.
What the domain covers is the whole relationship between a project and the people around it, which takes in both the relationship and the information moving through it. Two propositions inside it are worth taking seriously, because they are the two most often ignored.
Two propositions worth taking seriously
The first is that stakeholder work is continuous and relational, which means it cannot be discharged by producing something. A register records an analysis, and the analysis ages: people move, priorities shift, a reorganisation in another directorate alters who cares about the project. A team that produced a good register in month one and has not revisited it is working from a photograph.
The second is that the domain is judged by what stakeholders do, and not by how satisfied they report themselves to be. Satisfaction is worth knowing and it is a lagging, polite measure. What tells you the domain is working is behaviour: decisions arriving when they were needed, problems mentioned early, somebody defending the project in a meeting you were not in. A project scoring well on a stakeholder survey and waiting three weeks for every decision has an engagement problem the survey will never find.
One identification, and three things done twice
Section 2.5 of the PMBOK® Guide Eighth Edition gathers seven processes into this domain, and their arrangement explains the domain better than a list of their names would.
One of them is identification, and it sits at the front because everything else needs a subject. It is also the only one people habitually treat as a one-off, which it is not: new stakeholders arrive with every phase, every scope change and every reorganisation.
The remaining six are three activities carried out twice. Planning, doing and monitoring are each performed once for engagement, which is the relationship, and once for communications, which is the information. Plan the engagement and plan the communications. Manage the engagement and manage the communications. Monitor each of them.
That pairing is the most useful structural fact in the domain, because organisations routinely split the two and hand them to different people. A customer success manager owns the relationship. A project manager owns the reporting. Two plans, two rhythms, two accounts of what is happening, and one stakeholder receiving both. The Eighth Edition puts them in a single domain because they are a single piece of work, and a project that separates them produces the failure the separation invites.
Two owners and one go-live date
A software company was implementing its platform for a large logistics client, a nine-month engagement affecting about forty of the client's staff. The account had two owners by design. A customer success manager held the relationship, with a monthly call to the client's operations director and responsibility for renewal. The implementation project manager held delivery, with a weekly written report to the same director and a fortnightly working session with the client's project team.
In month five the two accounts of the project diverged. The weekly report carried a go-live date of the twelfth of November, which was the plan of record and had a fortnight of contingency inside it. The monthly call had discussed that date and had also discussed, warmly and helpfully, the possibility of bringing a group of depots forward into October if things went well, which the customer success manager raised because the director asked and because it was true.
The director heard November as a commitment and October as a probability, and told her own board the second one. Nobody had lied and nothing had been mismanaged in either half. The two halves had simply never been reconciled, because no moment existed in either process where one person held both.
The repair was structural and small. The weekly report and the monthly call were prepared from the same page, the two owners spent twenty minutes together before each call, and anything said about dates in the relationship channel appeared in the next written report. The October option was withdrawn in writing, which cost a difficult conversation in month five instead of a considerably worse one in month nine.
For a PMP® candidate, the domain reads best as a single system rather than as seven processes. A stakeholder holding a different view of the project from the one the reporting describes is a domain-level failure, and the answer is rarely another report. Look for where the relationship and the information have come apart, and for who holds both. The question to put is what the stakeholder actually did, because behaviour is this domain's output. Practising on situations where the artefacts are immaculate is the stakeholder work a structured PMP exam preparation course sets.
The cheapest test of this domain takes ten minutes. Name the three people whose view of the project matters most, and for each write down who last spoke to them, what they were told, and what they did afterwards. If two different people have spoken to the same person in the past month and neither knows what the other said, the domain is being run as two workstreams, and that is worth fixing before it produces a date nobody agreed to.
Interested in going further?
An accurate register, a clean report and a stakeholder working from a different set of facts is a common combination and a domain-level failure. Omega's PMP® Exam Preparation works through stakeholder situations where the artefacts are in order and the relationship is not.
All seven of the stakeholder processes sit in one domain in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A137: When Stakeholders Disagree: What Should the PM Do First?
A136: Why Hostile Stakeholders Still Need Engagement
A134: Power/Interest Grid vs Salience Model
A139: Communication Plans That People Actually Use
A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
