The People and Process domains at a glance

Together, the People and Process domains account for roughly three-quarters of the 2026 PMP exam: about 33 % and 41 % of scored questions respectively. This lesson gives a map of the tasks in each domain as listed in PMI's outline at the time of writing, explains in plain language what each task involves, shows how tasks appear differently in predictive, agile and hybrid settings, and points to the later courses in this program that teach each area in depth. The aim is orientation: by the end you should be able to recognize which task a scenario is testing and know where to study it. The tasks below are paraphrased summaries written for this course, not PMI's full wording; read the outline itself for the official text.

The People domain

The People domain covers the human side of project leadership: building a shared vision, leading the team, resolving conflict, engaging and aligning stakeholders, transferring knowledge and communicating. At the time of writing, PMI's 2026 outline listed eight People tasks:

People questions in different approaches

People tasks look different depending on the approach. In a predictive project, stakeholder engagement may involve a formal stakeholder register, a communications management plan and scheduled steering committee meetings. In an agile team, it may involve a product owner who represents stakeholders, sprint reviews where stakeholders see working increments, and information radiators such as task boards. In a hybrid project, you might use a formal governance structure for funding and milestones while teams work in iterations. Leadership questions in agile settings often reward servant leadership: removing impediments, facilitating rather than directing, and empowering self-organizing teams. In predictive settings, the project manager typically has more direct authority over planning, but the exam still favors collaborative, respectful leadership over command and control.

The Process domain

The Process domain covers the technical side of planning and delivering projects: integrated planning, scope, value delivery, resources, procurement, finance, quality, schedule, status and closure. At the time of writing, PMI's outline listed ten Process tasks:

Process questions in different approaches

Process tasks are where approaches differ most visibly. Scope in a predictive project is defined early and controlled through a change control process; in agile, scope lives in a prioritized product backlog refined continuously with the product owner. Schedules in predictive projects are built with work breakdown structures, networks and critical paths; in agile, the team commits to iteration goals and uses velocity or flow metrics to forecast releases. Status in predictive projects may be measured with earned value; in agile, with burndown or burnup charts, cumulative flow diagrams and working product demonstrated at reviews. Hybrid projects mix these: for example, a fixed regulatory milestone and contract, with iterative development of software components. Exam questions often test whether you can choose the tool or practice that fits the situation, rather than applying one approach everywhere.

Calculations in the Process domain

Although the PMP is mainly a judgment exam, some questions involve calculations, most often in scheduling and finance: critical path and float, earned value metrics such as schedule and cost variance and the performance indices SPI and CPI, estimate at completion, and simple expected value. The number of calculation questions varies by exam form and is usually small, but they are relatively easy marks if you practice them. PMP-130 covers these in detail. A quick reminder of the most common earned value relationships:

Here \(EV\) is earned value, \(AC\) actual cost, \(PV\) planned value and \(BAC\) the budget at completion. A CPI below 1 means the project is over budget for the work done; an SPI below 1 means it is behind schedule.

Linking People and Process

In real projects, People and Process are inseparable: a schedule only works if the team commits to it, and stakeholder alignment depends on clear scope and status information. Exam scenarios often combine them. A question about a delayed deliverable may really be about a team member who needs coaching; a question about a conflict may really be about unclear requirements. When you read a scenario, ask what the root cause is and which task best addresses it, rather than reacting to the most visible symptom. This habit, practiced throughout the later courses, is one of the most important exam skills.

Reading a People scenario

People questions often describe a tension between individuals or groups and ask how the project leader should respond. The details matter. Is the conflict about task priorities, technical approach, resources, personalities or values? Is it within the team, between the team and a stakeholder, or between stakeholders? Has anything already been tried? Strong answers usually involve understanding the cause before acting, speaking directly with those involved, encouraging collaboration and problem solving, and escalating only when the issue exceeds the leader's authority or has resisted reasonable efforts. Answers that avoid the problem, impose a solution without listening, or publicly blame someone are rarely best.

Questions about team development often draw on models of how teams form and mature, on servant leadership, and on psychological safety. A newly formed team needs clear goals, roles and working agreements; a team in conflict needs facilitation; a high-performing team needs autonomy and protection from interruptions. In agile settings, the project leader's role shifts from directing to enabling: removing impediments, coaching, facilitating ceremonies and shielding the team so it can self-organize.

Reading a Process scenario

Process questions frequently present a deviation, such as a delay, a cost overrun, a quality problem or a scope dispute, and ask what to do next. In predictive projects, the usual sequence is to assess the variance against the baseline, identify the cause, evaluate options and their impacts, and, if a change to the baseline is needed, submit it through change control. In adaptive projects, the response is more likely to involve the product owner reprioritizing the backlog, the team adjusting its plan at the next iteration, or the issue being discussed at a review or retrospective.

Knowing a handful of measures helps interpret these scenarios. Schedule variance, cost variance and the performance indices tell you whether a predictive project is ahead or behind and over or under budget. Velocity, burndown and burnup charts tell you how an agile team is progressing toward its goals. Cumulative flow diagrams show bottlenecks in flow-based work. The exam is less concerned with calculating these precisely than with what they imply and what the leader should do about it.

Interpreting earned value results

When CPI and SPI are both below 1, the project is over budget and behind schedule; when both are above 1, it is under budget and ahead of schedule. Mixed results are common: a project that has added resources to catch up may show SPI improving while CPI falls. The estimate at completion based on CPI assumes that current cost performance continues; other formulas assume that future work proceeds at the budgeted rate or reflect both cost and schedule performance. On the exam, choose the formula that fits the assumption described in the scenario, and remember that a forecast is a basis for action: the leader should analyze causes and consider corrective options, not simply report the number.

Linking People and Process

Many real problems span both domains. A schedule slip may be caused by unclear roles, a struggling team member or a stakeholder who delays approvals. A quality problem may reflect inadequate training or a team that does not feel safe raising concerns. When a scenario presents a process symptom, look for a people cause, and vice versa; the best answer often addresses the underlying cause rather than the symptom.

Tasks in agile and hybrid contexts

Every task in People and Process can be tested in any approach. Take plan and manage scope: in a predictive project it involves a scope statement, a work breakdown structure and baseline control; in an agile project it involves a product vision, a backlog refined continuously, and acceptance criteria and a definition of done; in a hybrid project it may combine a contractually fixed set of deliverables with iterative development of the details. When you study a task, write a short paragraph for each approach. If you cannot, that is a gap to close before the exam, since roughly 60 % of questions involve adaptive or hybrid settings.