Study guide · Domain 1

People

33% of the exam's questions · 8 tasks

People is about leading and working with the humans who make a project succeed: the team, the sponsor, customers and everyone the work affects. The exam almost never asks you to define a conflict mode or a stakeholder tool; it describes a tense meeting, a disengaged team member, a sponsor with shifting expectations or a team that has stopped sharing, and asks what the project manager should do first, next or best. Strong answers understand the situation before acting, deal directly with the people involved before escalating, and use the agreed artifacts (team charter, stakeholder register, engagement and communications plans). Expect the same task in predictive, agile and hybrid settings, where the leader plans and coordinates in one and serves and protects a self-organising team in the other.

A study feature written by ExamDragon, not part of the real exam. Each heading is one of PMI's 8 tasks for this domain, in our own words. Predictive, agile and hybrid approaches run through every domain (PMI: about 40% predictive, 60% agile or hybrid).

At a glance

Domain 1

33%

of the exam's questions (PMI)

Tasks: 8
Key terms: 12

What this guide covers, task by task

PEO.1Build a shared picture of what the project is for, and keep it alive
PEO.2Find the sources of conflict and settle them with an agreed approach
PEO.3Lead the team: set expectations, give it room to decide, and speak for it
PEO.4Identify, analyse and win the support of the people the project affects
PEO.5Sort stakeholders, surface what each expects, and bring the expectations together
PEO.6Know what customers inside and outside the organisation expect, and keep results matched to it
PEO.7Capture what the project knows and make sure it passes on
PEO.8Decide how the project communicates and reports, and keep feedback flowing

PEO.1Build a shared picture of what the project is for, and keep it alive

A project vision is a short, outcome-focused statement of why the project exists and what will be different for its users when it is done; it is broader than scope and should still make sense if the solution changes.
Build the vision with the sponsor, key stakeholders and the team rather than handing it down: a visioning workshop, a product vision board or an elevator-pitch template ('for [user] who [need], our [product] will [benefit], unlike [current state]') turns different hopes into one sentence everyone can repeat.
Promote the vision actively: open kickoffs, sprint reviews and steering meetings with it, put it on the team's board or wiki, and use it as the test for trade-off decisions ('does this move us toward the vision?').
Refresh the vision when the context moves: revisit it at phase gates, release planning and after major changes in the business case, market or regulation, and update the charter, roadmap and backlog when it shifts so artifacts do not drift apart.
When people work toward different goals, treat it as a misunderstanding of the vision and find the root cause before correcting anyone: the 5 Whys, a fishbone diagram or simply asking each party what they believe success looks like often shows an unclear benefit, a conflicting incentive or a stakeholder who missed the original conversation.
Link the vision to measurable outcomes and stakeholder value (for example, shorter wait times or lower energy use), so the team can see progress toward it rather than only toward deliverables.

Predictive: The vision is captured early in the project charter and business case, then reinforced at kickoff and checked at each phase gate against the approved objectives.
Agile: The product owner holds a product vision and roadmap that the whole team helped shape; each sprint goal and sprint review connects the increment back to that vision.

In practiceOn a hospital patient-portal project, two developers kept building administrative reports while the clinical lead pushed for appointment booking. The project manager asked each group to describe success in one sentence, found the reporting team had never seen the charter's goal of reducing missed appointments, and ran a one-hour session where both groups agreed a single vision statement and reordered the roadmap around it.
Where questions turnChoosing to escalate or to restate the vision more forcefully when people disagree on direction; the stronger answer first finds out why they understand it differently, then realigns them together.

Practise PEO.1

PEO.2Find the sources of conflict and settle them with an agreed approach

Common sources of project conflict are schedules and priorities, scarce resources, technical opinions, unclear roles, cost, administrative procedures and personalities; most are about the work, not the people, and some conflict is healthy when it sharpens decisions.
Analyse the context before choosing a response: how urgent is the decision, how important is the relationship, who holds power, is it a one-off disagreement or a pattern, and has it moved from task conflict into personal conflict?
Know the five classic modes (from the Thomas-Kilmann model): collaborate or problem-solve (best for lasting results when time allows), compromise or reconcile (each side gives something), smooth or accommodate (emphasise agreement, useful to preserve a relationship on minor points), force or direct (one view wins, for emergencies or safety), and withdraw or avoid (only as a cooling-off step or when the issue is trivial).
Once a strategy is agreed, implement it and follow up: record the decision, the owners and the date, and check later that the conflict has not resurfaced elsewhere.
Ground rules and a team charter (how we decide, how we disagree, response times, meeting norms, use of shared tools including AI assistants) give everyone common footing; share the principles with external stakeholders too, so vendors and client staff know how disagreements will be handled.
When a ground rule is broken, address it early and privately with the person, refer to the rule the team agreed, and let the team revisit the rule if it no longer works; repeated or serious breaches go to the functional manager or HR through the proper path.
Emotional intelligence matters throughout: stay calm, listen to understand each side's interests, and separate positions (what people say they want) from interests (why they want it).

Predictive: The project manager often facilitates the resolution directly, using the responsibility assignment matrix, schedule and change control to settle disputes over roles, priorities and scope.
Agile: The team is expected to work through most conflicts itself using its working agreements; the agile lead coaches and facilitates, stepping in only when the team cannot resolve it or ground rules are broken.

In practiceA construction electrical subcontractor and the mechanical crew argued daily over who got the ceiling space first. The project manager met both foremen together, mapped the sequencing on the lookahead schedule, found that the real interest of both was avoiding rework, and agreed a zone-by-zone handover with a short daily coordination call, then checked a week later that rework had stopped.
Where questions turnPicking 'force' or 'escalate to the sponsor' as the first move in a non-urgent conflict; when time allows, meet the parties and solve the underlying problem together.

Practise PEO.2

PEO.3Lead the team: set expectations, give it room to decide, and speak for it

Set team-level expectations early in a team charter or working agreement: purpose, ways of working, decision rights, quality standards, communication norms and how success is measured; revisit it when the team changes.
Servant leadership puts the team first: remove obstacles, shield the team from distractions, coach rather than command, and give the team the authority to decide how to do its work; empowerment means real decision rights, not just consultation.
Adapt leadership style to the situation and the team's maturity: directive when a new team needs structure or in a crisis, coaching and supporting as skills grow, delegating to an experienced self-organising team (the idea behind situational leadership).
Tuckman's stages (forming, storming, norming, performing, adjourning) describe how teams develop; expect storming after changes in membership, help the team through it with clear roles and facilitation, and expect productivity to dip each time the team re-forms.
Speak up for the team: carry its concerns, capacity limits and impediments to management and stakeholders honestly, and push back on unrealistic commitments made without the team.
Value varied experience, skills and perspectives: diverse and distributed teams make better decisions when everyone can speak, so use round-robin input, written ideas before discussion and inclusive meeting times; psychological safety is a precondition for problem solving.
Make roles and responsibilities explicit with a RACI or role definitions (only one Accountable per deliverable); in agile, clarify the product owner, team and agile lead roles, while letting team members take tasks rather than be assigned them.

Predictive: The project manager builds the team, assigns work through the resource plan and RACI, tracks performance and adjusts leadership style as the team develops.
Agile: The agile lead acts as a servant leader and coach: the team self-organises, pulls its own work and decides how to meet the sprint goal, while the lead removes impediments and protects its focus.

In practiceWhen two senior engineers joined a telecom team mid-release, velocity fell and stand-ups turned tense. The agile lead recognised the team had slipped back into storming, facilitated a short session to update the working agreement and pairing rotation, and asked the newcomers to lead a design spike, which settled the team within two sprints.
Where questions turnAssigning tasks to individual members or making the technical decision for an agile team; the better answer empowers the team to decide and helps it through the obstacle.

Practise PEO.3

PEO.4Identify, analyse and win the support of the people the project affects

Identify stakeholders early and keep looking: anyone who affects or is affected by the project, including end users, regulators, operations staff, communities and suppliers; use the charter, contracts, org charts, interviews and brainstorming, and record them in the stakeholder register.
Analyse stakeholders on power, interest, influence and attitude: the power/interest grid suggests managing closely (high power, high interest), keeping satisfied (high power, low interest), keeping informed (low power, high interest) and monitoring (low, low); the salience model adds legitimacy and urgency.
Assess engagement with a stakeholder engagement assessment matrix: mark each person's current level (unaware, resistant, neutral, supportive, leading) and the desired level, then plan actions to close the gap.
Tailor communication to each stakeholder: content, detail, channel, frequency and language that fit their needs (an executive dashboard, a technical walkthrough, a community briefing), recorded in the communications and engagement plans.
Execute the engagement plan and adjust it: hold the meetings, demos and one-to-ones planned, watch for changes in attitude, and update the register and plan as people join, leave or change position.
Align stakeholder needs with project objectives: surface competing interests early and resolve them openly against the vision and business case rather than letting the loudest voice win.
Build trust and influence through reliability, transparency and listening; influence comes more from relationships and shared interests than from position, so invest in key stakeholders before you need their support.

Predictive: Stakeholders are identified and analysed during initiation, with a register and engagement plan baselined early and reviewed at milestones and phase gates.
Agile: Stakeholders engage continuously through sprint reviews, backlog refinement and frequent demos; the product owner represents many of them, and engagement is checked each iteration rather than mostly up front.

In practiceA municipal transit app project had strong council support but a quiet union whose drivers would use the new dispatch screens. The project manager placed the union in high power, high interest, saw its engagement was 'resistant', and set up monthly hands-on previews with driver representatives, whose feedback changed two screens and moved the union to 'supportive' before rollout.
Where questions turnTreating stakeholder identification as a one-time activity at the start, or sending every stakeholder the same report; registers and plans are updated throughout, and communication is tailored.

Practise PEO.4

PEO.5Sort stakeholders, surface what each expects, and bring the expectations together

Categorise stakeholders so you can treat groups appropriately: by power and interest, by internal or external, by direction of influence (upward to executives, downward to the team, sideways to peers, outward to customers and regulators) or by how they will be affected.
Identify expectations explicitly; many are unspoken (a sponsor who assumes a feature, a user who assumes training): use interviews, surveys, workshops and assumption logs, and turn vague expectations into measurable acceptance criteria where you can.
Facilitate discussions that bring differing expectations together: a joint workshop with a neutral facilitator, prioritisation techniques (MoSCoW, dot voting, trade-off sliders for scope, time, cost and quality) and the business case as the shared reference.
Make agreements visible afterwards: update requirements, the backlog, the stakeholder register and the issue log, and confirm in writing what was agreed and what was not.
Look for mentoring opportunities in both directions: pair a less experienced team member with a stakeholder expert, coach a new product owner on backlog ownership, or mentor stakeholders on how the delivery approach works so their expectations become realistic.
Recheck expectations when anything significant changes (a new sponsor, a reorganisation, a revised budget), because alignment reached once does not hold by itself.

Predictive: Expectations are captured in requirements documentation, the scope statement and the stakeholder register, and realigned through formal reviews and change control.
Agile: Expectations are aligned continuously as stakeholders see working increments; the product owner reconciles competing requests in the backlog, and the team coaches stakeholders on the cadence of delivery.

In practiceA university's IT and finance departments each expected a new procurement system to be built around their own workflows. The project manager ran a joint workshop using MoSCoW against the business case, agreed a shared set of 'must have' requirements, and arranged for a finance analyst to mentor the new product owner on approval rules so future backlog decisions reflected both groups.
Where questions turnAssuming silence means agreement, or resolving different expectations by meeting each group separately and promising each what it wants; expectations are surfaced and aligned together, then documented.

Practise PEO.5

PEO.6Know what customers inside and outside the organisation expect, and keep results matched to it

Customers can be internal (another department, operations who will run the product) or external (clients, end users, the public); identify who they are and what each expects in outcomes, quality, timing, service and communication.
Translate expectations into criteria the team can deliver against: acceptance criteria, service levels, quality metrics, a Definition of Done and, where relevant, sustainability or accessibility requirements.
Keep outcomes aligned by checking deliverables against those criteria throughout, not only at the end; early prototypes, demos and pilot releases catch mismatches while they are cheap to fix.
Monitor satisfaction with direct and indirect signals: feedback sessions, surveys and net promoter style scores, support tickets, adoption and usage data, complaints and informal conversations.
Respond when satisfaction drops: find the cause (an unmet expectation, a quality problem, poor communication), agree corrective action, and use change control if the expectation means new scope rather than a defect.
Manage expectations honestly: tell customers early about delays, constraints or trade-offs, and never promise what the team has not committed to; trust lost by surprises is hard to win back.

Predictive: Customer expectations are defined in requirements and acceptance criteria, validated through scope reviews and quality checks, and confirmed at formal acceptance.
Agile: Customers or their proxies see each increment at the review, and their feedback re-prioritises the backlog; satisfaction is checked continuously through releases and usage data.

In practiceAfter the pilot of a nonprofit's donor platform, usage data showed volunteers abandoning the sign-up form halfway. The project manager met three volunteer coordinators, learned the form asked for data they rarely had, and worked with the product owner to simplify it in the next release; completion rose and the coordinators were invited to every review after that.
Where questions turnWaiting for the final acceptance meeting to learn whether the customer is satisfied, or treating every customer request as in scope; monitor satisfaction throughout and route new scope through change control.

Practise PEO.6

PEO.7Capture what the project knows and make sure it passes on

Find the knowledge the project cannot do without: specialist skills held by one person, decisions and their reasons, vendor and system know-how, regulatory interpretations and what operations will need after handover; a single point of knowledge is a risk to log.
Knowledge is explicit (documented: procedures, designs, lessons learned registers) or tacit (in people's heads: judgement, relationships, know-how); tacit knowledge transfers mainly through people, so plan for both.
Gather knowledge as you go, not only at closure: decision logs, a lessons learned register updated at milestones and retrospectives, architecture decision records and short recorded walkthroughs.
Use techniques that move tacit knowledge: pairing and mob work, job shadowing, communities of practice, brown-bag sessions, mentoring and rotating responsibilities; for handover, plan overlap time between the outgoing expert and the receiver.
Foster an environment where sharing is normal and safe: recognise people who teach others, make blameless reviews the norm, and keep knowledge in accessible, searchable shared repositories rather than private folders.
AI tools can summarise meeting notes or draft documentation, but a person must check the output for accuracy before it becomes project knowledge, and confidential or personal data must not be pasted into public tools.

Predictive: Knowledge is captured in project documents, the lessons learned register and formal handover packages, with transfer to operations planned as part of closure.
Agile: Knowledge spreads through cross-functional work, pairing, retrospectives and a shared Definition of Done that includes documentation; the team avoids relying on one 'hero'.

In practiceA bank's payments team depended on one contractor for the settlement engine, and her contract ended in six weeks. The project manager logged the risk, set up daily pairing sessions with two permanent developers, asked her to record short walkthroughs of the trickiest modules, and had the developers lead the final two releases while she was still available to answer questions.
Where questions turnLeaving knowledge capture until the closing lessons learned session, or assuming a documentation dump transfers expertise; capture knowledge throughout and use people-to-people methods for tacit knowledge.

Practise PEO.7

PEO.8Decide how the project communicates and reports, and keep feedback flowing

Set out how the project will communicate in a communications management plan: who needs what information, why, in what format, how often, through which channel, from whom, and how sensitive information is handled; tailor it to the stakeholder analysis.
Communication channels grow quickly with team size: the number of channels is n(n - 1) / 2, so a team going from 6 to 10 people moves from 15 to 45 channels, which is a reason to plan communication deliberately.
Choose the method to fit the message: interactive (meetings, calls) for complex or sensitive topics, push (emails, reports) for information people must receive, pull (wikis, dashboards, shared boards) for large audiences who look when they need to.
Work in the open: make plans, progress and problems visible (information radiators, shared boards, open dashboards), share bad news early, and keep a single source of truth.
Establish feedback loops so communication goes both ways: check understanding, ask stakeholders whether reports meet their needs, and adjust the plan; retrospectives and pulse surveys work for the team.
Understand reporting requirements from governance and the sponsor (format, frequency, thresholds, compliance reporting), and build reports that answer their questions: status against baselines or goals, risks, decisions needed and forecasts, not just activity.
Support governance by delivering reports on time, escalating through the agreed path when thresholds are breached, and keeping records of decisions; AI-generated summaries are checked by the project manager before they go out.

Predictive: Communication follows a communications management plan with scheduled status reports, steering committee meetings and formal reporting against baselines.
Agile: Communication is frequent and largely face to face or real time: daily stand-ups, visible boards, burnups and sprint reviews, with lightweight reports derived from the team's own artifacts.

In practiceAn energy company's executives complained that weekly status reports were too long to read. The project manager asked three steering members what decisions they needed to make, replaced the report with a one-page dashboard showing milestone forecast, top risks and decisions required, linked the detail on a shared site, and checked a month later that the steering meetings had become shorter and more decisive.
Where questions turnSending more information to fix a communication problem, or using the same format for every audience; first find out what each stakeholder needs, then tailor the content, channel and frequency.

Practise PEO.8

Key terms

Team charter: An agreement the team writes about its purpose, values, ground rules, decision making and ways of working.
Servant leadership: A style in which the leader serves the team by removing obstacles, coaching and enabling it to decide, rather than directing every task.
Tuckman's stages: A model of team development: forming, storming, norming, performing and adjourning.
Collaborate (problem-solve): The conflict mode that works through the underlying issue with all parties to reach a lasting solution that meets their interests.
Stakeholder register: The record of stakeholders with their roles, interests, influence, expectations and classification, kept current throughout the project.
Power/interest grid: A two-axis chart that groups stakeholders by their authority and their concern about the project to suggest how closely to engage each.
Engagement assessment matrix: A table comparing each stakeholder's current and desired engagement level (unaware, resistant, neutral, supportive, leading) to plan actions.
RACI chart: A responsibility assignment matrix showing who is Responsible, Accountable, Consulted and Informed for each deliverable or decision.
Tacit knowledge: Know-how, judgement and experience held in people's heads that is hard to write down and moves mainly through working together.
Communication channels: The number of possible two-way links in a group, n(n - 1) / 2 for n people.
Information radiator: A highly visible display (a board, a chart, a dashboard) that shows project status to anyone who passes or looks.
Psychological safety: A shared belief that team members can speak up, admit mistakes and disagree without fear of blame.

After this guide: Given a scenario of tension, disengagement or misaligned expectations, can you say what is really happening, which people you would talk to first, and which agreed artifact or technique you would use before considering escalation?

Practise People

ExamDragon is independent exam preparation, not affiliated with, endorsed by or reviewed by the Project Management Institute (PMI). PMP and PMI are registered marks of the Project Management Institute, Inc. The names are used only to describe the exam. Every question and guide here is our own, written from PMI's published PMP Examination Content Outline (July 2026); the path is not a source of the 35 training hours or of PDUs.