Study guide · Domain 2

Process

41% of the exam's questions · 10 tasks

Process covers the technical work of running a project: choosing the delivery approach, planning scope, schedule, cost, resources, quality and procurement, delivering value, tracking performance and closing properly. It is the largest domain, and the exam tests it through situations rather than recall: a variance appears in an earned value table, a vendor misses a milestone, a burnup flattens, a team must choose between predictive and agile for a new piece of work, or a phase is ready to hand over. Expect calculations (earned value, float, communication channels, expected monetary value) with figures in the stem or an exhibit, and expect to pick the right tool for the approach, never a predictive control in an agile setting or the reverse. Strong answers follow the plan the project agreed, act on data, and keep delivered value in view beside scope, time and cost.

A study feature written by ExamDragon, not part of the real exam. Each heading is one of PMI's 10 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 2

41%

of the exam's questions (PMI)

Tasks: 10
Key terms: 12

What this guide covers, task by task

PRO.1Choose the delivery approach and build one integrated plan for the work
PRO.2Define the scope, agree it with stakeholders and break it down
PRO.3Deliver value early and often, and keep checking the value is real
PRO.4Work out the people and materials needed, and keep supply matched to need
PRO.5Plan purchasing, choose contract types, negotiate and manage suppliers
PRO.6Plan the budget and reserves, track spending and act on variances
PRO.7Plan quality into the deliverables, review it and keep improving it
PRO.8Estimate, build, baseline and control the schedule for the chosen approach
PRO.9Measure progress, keep project artifacts current and report status
PRO.10Get acceptance, hand over, and close the project or phase properly

PRO.1Choose the delivery approach and build one integrated plan for the work

Assess the project's needs, complexity and size before planning: how stable and well understood are the requirements, how new is the technology, how many teams and stakeholders, what regulation applies, and how costly is a late change; tools such as a suitability or tailoring assessment help.
Recommend the development approach that fits: predictive when requirements are stable and change is costly (a bridge, a regulated device), agile when requirements will emerge and early feedback is valuable (a new app), hybrid when parts differ (fixed hardware with agile software, or stage gates with iterations inside).
Identify critical information requirements early, including sustainability (energy use, waste, carbon reporting), security, privacy and accessibility, because they shape the plan, the vendors and the acceptance criteria.
Recommend an execution strategy: phases or releases, in-house or contracted work, pilot first or full rollout, and how teams will be organised and coordinated.
An integrated project management plan joins the subsidiary plans (scope, schedule, cost, quality, resources, communications, risk, procurement, stakeholders) and baselines so a change in one is checked against the others; in agile the equivalent is a lighter set of a roadmap, release plan, Definition of Done and working agreements.
Estimate effort and resources with suitable techniques: analogous (top-down from similar projects), parametric (unit rates), bottom-up from the WBS, three-point (PERT: (O + 4M + P) / 6), and relative sizing with story points or planning poker in agile.
Review the consolidated plans for dependencies, gaps and continued business value, keep the plan current through change control or backlog refinement, and base decisions on data (performance metrics, forecasts, risk analysis); AI tools can speed up analysis but their outputs are checked before decisions rely on them.

Predictive: The project manager leads detailed up-front planning, integrates the subsidiary plans into one baselined plan, and keeps it current through formal change control.
Agile: Planning is progressive: a vision and roadmap, release planning, then sprint planning each iteration, with the plan adapted continuously from feedback and measured velocity.

In practiceA manufacturer needed a new packaging line and the software to run it. The project manager assessed that the mechanical work had fixed specifications and long-lead equipment while the control software would change as operators tried it, so she proposed a hybrid plan: a predictive schedule with gates for the line and two-week sprints for the software, joined by integration milestones and a shared risk register.
Where questions turnChoosing an approach by preference or habit rather than by the project's characteristics, or treating the plan as finished once baselined; the plan is tailored to the work and maintained as conditions change.

Practise PRO.1

PRO.2Define the scope, agree it with stakeholders and break it down

Define scope from requirements: collect them through interviews, workshops, observation, prototypes and document analysis, record them with acceptance criteria, and trace each back to a business objective using a requirements traceability matrix.
The project scope statement describes the deliverables, acceptance criteria, exclusions, constraints and assumptions; the exclusions matter because they prevent later arguments about what was promised.
Get stakeholder agreement explicitly: review the scope statement or initial backlog with the sponsor and key stakeholders and record their approval, so the scope baseline has authority.
Break predictive scope down with a work breakdown structure (WBS): decompose deliverables into work packages small enough to estimate and assign, with the 100% rule (the children add up to all of the parent and nothing more) and a WBS dictionary describing each package.
The scope baseline is the approved scope statement, WBS and WBS dictionary; changes to it go through change control.
In agile, break scope down from epics to features to user stories ('As a [user], I want [goal] so that [benefit]'), each small enough to finish in a sprint and meeting INVEST (independent, negotiable, valuable, estimable, small, testable); story mapping keeps the user journey visible.
Guard against scope creep (uncontrolled additions) and gold plating (the team adding unrequested extras); both add cost and risk without an approved decision.

Predictive: Scope is defined in detail early, baselined as the scope statement, WBS and WBS dictionary, validated through formal acceptance of deliverables and changed only through change control.
Agile: Scope is a prioritised product backlog that the product owner refines continuously; the team commits to a small slice each iteration, and new items are welcome but must be prioritised against existing work.

In practiceFor a community centre renovation, the project manager wrote a scope statement that excluded furniture and landscaping, built a WBS down to work packages such as 'accessible entrance ramp', and walked the board through it line by line; when a board member later asked about new chairs, the signed exclusion made it a clear change request rather than a dispute.
Where questions turnAccepting a stakeholder's small extra request directly into the work, or letting the team add features nobody asked for; additions go through change control (predictive) or the product owner's backlog (agile).

Practise PRO.2

PRO.3Deliver value early and often, and keep checking the value is real

Value is the benefit stakeholders receive, which can be financial (revenue, savings), operational (speed, quality), social or environmental; identify with key stakeholders which components of value matter most and how they will be recognised.
Prioritise work by value and feedback: MoSCoW (must, should, could, won't this time), Kano (basic, performance, delighter features), cost of delay, and weighted shortest job first (WSJF = cost of delay divided by job size, so high-value small items go first).
Look for ways to deliver value incrementally: a minimum viable product (MVP) to test an assumption, a minimum business increment or minimum marketable feature that is worth releasing, phased rollouts and pilots.
Examine business value throughout, not just at the end: revisit the business case at gates and releases, and recommend changing direction or stopping if the expected value no longer justifies the cost.
Check that a benefits measurement system exists: a benefits management plan names each benefit, its measure (KPI or OKR), its owner, its baseline and when it will be realised, often after the project closes.
Evaluate delivery options that demonstrate value early: prototypes, A/B tests, demos to real users and feature toggles; financial measures such as net present value (NPV), internal rate of return, payback period and benefit-cost ratio support selection between options (higher NPV and BCR are better, shorter payback is better).

Predictive: Value is defined in the business case and benefits plan, checked at phase gates, and mostly realised when the full product is delivered and adopted.
Agile: Value is delivered in small increments each release; the product owner orders the backlog by value, and feedback and usage data steer what comes next.

In practiceA city's permit-application project had 40 requested features. The product owner and the project manager scored them with WSJF, released an MVP with online submission and status tracking in eight weeks, and measured that phone enquiries fell by a third, which confirmed the business case and justified funding the next release.
Where questions turnEquating value with finishing all the scope, or ordering work by stakeholder seniority; value is assessed with stakeholders, delivered early where possible and measured against defined benefits.

Practise PRO.3

PRO.4Work out the people and materials needed, and keep supply matched to need

Define resources from the requirements and WBS or backlog: people (roles, skills, numbers), equipment, materials, facilities and services; a resource breakdown structure organises them by type.
Plan team resources with a resource management plan: how people are acquired (pre-assignment, negotiation with functional managers, hiring, contracting), released, trained and recognised, and a RACI for responsibilities.
Physical resources need lead times, storage, quality checks and just-in-time or buffer stock decisions; long-lead items belong on the critical path analysis and in procurement planning.
Resource leveling adjusts start and finish dates to resolve over-allocation and can lengthen the critical path; resource smoothing adjusts only within float so the end date does not move.
Manage availability actively: watch histograms and calendars for over-allocation, negotiate with functional managers in a matrix organisation, and plan for absences, competing projects and skill gaps (cross-training, contractors).
In agile, keep teams stable, dedicated and cross-functional, and plan by team capacity rather than individual assignments; adding people to a late team often slows it down at first.
Optimise for sustainability too: choose lower-impact materials and equipment where they meet requirements, and reduce waste and travel where remote work is effective.

Predictive: Resources are estimated per activity, assigned through the resource plan and schedule, leveled for over-allocation, and released when work is complete.
Agile: Stable, cross-functional teams own their capacity; the team pulls work it can finish, and resource needs are managed at the team level rather than by assigning individuals to tasks.

In practiceA data centre upgrade needed the only two certified network engineers, who were also booked on an outage project. The project manager found that one of her activities had five days of float, smoothed it to avoid the clash, agreed the remaining overlap with the functional manager, and arranged certification for a third engineer to reduce the risk next quarter.
Where questions turnAssuming resource leveling never changes the end date, or solving an agile team's capacity problem by adding people mid-sprint; leveling can extend the schedule, and agile capacity is managed by scope and team stability.

Practise PRO.4

PRO.5Plan purchasing, choose contract types, negotiate and manage suppliers

Plan procurement with a make-or-buy analysis (cost, capability, control, risk, capacity) and a procurement management plan covering what to buy, contract types, selection criteria, timelines and who has authority; a statement of work describes what the seller must deliver.
Choose the contract type by how well scope is known and who should carry cost risk: fixed price (firm fixed price, fixed price incentive fee, fixed price with economic price adjustment) puts most risk on the seller and suits well-defined scope; cost reimbursable (cost plus fixed fee, cost plus incentive fee, cost plus award fee) puts most risk on the buyer and suits uncertain scope; time and materials sits in between and suits staff augmentation or small, short work, ideally with a not-to-exceed cap.
Agile-friendly contracting shares the risk differently: fixed price per iteration or increment, capped time and materials, a target cost with shared savings and overruns, or a 'money for nothing, change for free' clause that lets the buyer re-prioritise or end early.
Run the selection fairly: request for information, proposal or quotation as fits, a bidder conference so all sellers get the same answers, weighted scoring against published criteria, independent estimates and documented evaluation.
Negotiate with a strategy: know your objectives and walk-away point (BATNA), understand the seller's interests, aim for terms that both sides can keep (a win-win agreement is easier to manage), and involve procurement or legal staff who hold signing authority.
Run the supplier relationship and the contract actively: monitor performance against the contract (milestones, quality, service levels, a vendor scorecard), hold regular reviews, handle claims and disputes through the contract's terms (negotiation first, then alternative dispute resolution), and route changes through contract change control.
Verify that the agreement's objectives were met before closing: inspect deliverables, settle claims, make final payment and record vendor performance for future selection; sustainability and ethics clauses (labour practices, materials) are part of what is verified.

Predictive: Procurement is planned up front with a detailed statement of work, usually under a fixed price contract, and managed against milestones, inspections and formal change control.
Agile: Contracts allow scope to evolve: work is bought in increments or capacity with regular demos as acceptance points, and the vendor collaborates closely with the buyer's product owner.

In practiceA health authority wanted a vendor to build a patient-scheduling app but could not yet define every feature. Rather than force a firm fixed price, the project manager proposed a fixed price per two-week increment with a cap on the number of increments and the right to end after any one, so the buyer kept control of cost while scope could change as clinicians gave feedback.
Where questions turnThinking the seller carries the risk under any contract, or telling a vendor directly to do extra work outside the contract; under cost reimbursable the buyer carries most risk, and every change to contracted work goes through contract change control and the person with procurement authority.

Practise PRO.5

PRO.6Plan the budget and reserves, track spending and act on variances

Analyse financial needs by aggregating activity or work package estimates into a time-phased cost baseline (the S-curve of planned value), then add reserves to get the project budget; agile teams often budget by team cost per sprint (a burn rate) times the expected number of sprints.
Quantify reserves from risk analysis: contingency reserve covers identified risks (known unknowns), sized with expected monetary value (EMV = probability x impact) or simulation, and sits within the cost baseline under the project manager's control; management reserve covers unidentified risks (unknown unknowns), sits outside the baseline and needs management approval to use.
Plan spend tracking and reporting: how costs will be recorded, at what level (control accounts), how often, against which baseline, and what thresholds trigger action or escalation.
Earned value management measures cost and schedule together: PV (planned value, budgeted cost of work scheduled), EV (earned value, budgeted cost of work done), AC (actual cost). CV = EV - AC and SV = EV - PV (negative is bad); CPI = EV / AC and SPI = EV / PV (below 1 is bad).
Forecast with EVM: EAC = BAC / CPI when current cost performance is expected to continue; EAC = AC + (BAC - EV) when the variance was a one-off; ETC = EAC - AC; VAC = BAC - EAC; TCPI = (BAC - EV) / (BAC - AC) is the efficiency needed on remaining work to finish within budget (above 1 means harder).
Anticipate financial challenges: inflation and exchange rates, funding limits by fiscal year, price rises from suppliers, and cash flow; compare expected spending against funding limits and reconcile any gap.
Act on variances through governance: analyse the cause, take corrective action within your authority, raise a change request if the baseline must change, and request management reserve only through the agreed process.

Predictive: A time-phased cost baseline is set early and tracked with earned value; variances beyond thresholds are reported and corrected through governance and change control.
Agile: Budget is often fixed per team and time box, and spending is tracked as burn rate against value delivered; scope flexes to stay within funding, and forecasts come from velocity and the remaining backlog.

In practiceAt month six of a $500,000 IT project, EV was $200,000, AC $250,000 and PV $240,000, so CPI was 0.8 and SPI about 0.83. The project manager found the overrun came from a contractor rate that would continue, forecast EAC at $625,000 (500,000 / 0.8), presented the gap and options to the steering committee, and they approved a scope reduction rather than more funding.
Where questions turnMixing up the reserves (using management reserve without approval or treating it as part of the cost baseline), or reading a CPI of 1.2 as an overrun; an index above 1 is favourable and a negative variance is unfavourable.

Practise PRO.6

PRO.7Plan quality into the deliverables, review it and keep improving it

Gather quality requirements from stakeholders, standards and regulations: what 'fit for use' means, measurable metrics and tolerances, acceptance criteria and, where relevant, accessibility, safety and sustainability requirements.
Quality management plans how quality will be built in; quality assurance checks that the processes are being followed and improved (audits, process analysis); quality control inspects the deliverables to verify they meet requirements (inspections, testing, measurement).
Use the right tools: checklists, checksheets, cause-and-effect (fishbone) diagrams, Pareto charts (the vital few causes, the 80/20 idea), histograms, scatter diagrams, flowcharts, and control charts (a process is out of control when a point falls outside the control limits or seven consecutive points sit on one side of the mean).
Cost of quality (CoQ) is the cost of conformance (prevention such as training and design reviews, and appraisal such as testing and inspections) plus the cost of nonconformance (internal failures like rework and scrap, external failures like warranty claims and lost reputation); prevention is usually cheapest.
Build in what regulators require: identify the standards that apply (safety, privacy, industry rules), build them into requirements and the Definition of Done, and keep evidence that they were met.
Review quality continuously: inspections at milestones in predictive work, and in agile a Definition of Done, automated tests, continuous integration, peer review and the sprint review.
Improve continuously with plan-do-check-act cycles, root cause analysis and retrospectives; treat sustainability as part of quality where it is required (materials, energy efficiency, waste), and check AI-assisted outputs such as generated code or test cases with the same standards.

Predictive: A quality management plan sets standards and metrics up front, quality assurance audits the processes, and quality control inspects deliverables before acceptance.
Agile: Quality is built in every iteration through the Definition of Done, test automation and frequent feedback; retrospectives drive process improvement, and defects are fixed before new work where possible.

In practiceA furniture manufacturer's project found that 9% of cabinets failed final inspection. The project manager's team built a Pareto chart of defect types, found that two causes (misaligned hinges and finish blemishes) produced 78% of rejects, traced the hinges to a worn jig, and added a jig check to the daily start-up checklist, cutting rework costs far more than adding inspectors would have.
Where questions turnConfusing quality assurance with quality control, or responding to defects by adding inspection rather than fixing the process; prevention and root cause correction usually cost less than more appraisal.

Practise PRO.7

PRO.8Estimate, build, baseline and control the schedule for the chosen approach

Prepare the schedule to suit the approach: a network-based schedule with activities, dependencies and durations for predictive work; iterations, release plans and a roadmap for agile; on-demand flow with WIP limits for Kanban; often a mix of milestones and iterations for hybrid.
Align with neighbouring projects and day-to-day operations: shared resources, maintenance windows, release freezes and dependencies on other teams belong in the schedule and the risk register.
Estimate with the right inputs: durations by analogous, parametric or three-point estimates (PERT: (O + 4M + P) / 6, standard deviation (P - O) / 6); milestones for key events; dependencies as finish-to-start (most common), start-to-start, finish-to-finish or start-to-finish, with leads and lags; story points and planning poker for relative sizing in agile.
Use benchmarks and historical data: past durations, productivity rates and a team's own velocity make estimates more reliable; velocity belongs to one team and is not compared between teams.
The critical path is the longest path through the network and sets the shortest project duration; activities on it have zero total float. Total float is how long an activity can slip without delaying the project end (late start minus early start); free float is how long it can slip without delaying the next activity.
Baseline the approved schedule and execute it through the schedule management plan; compress when needed by crashing (adding resources to critical activities, which adds cost) or fast tracking (overlapping activities, which adds risk), always working on the critical path.
Analyse variation with SV and SPI, milestone trend charts, comparison against the baseline, or in agile with burndown and burnup charts and velocity trends; decide whether a variance needs corrective action, a re-plan or a change request.

Predictive: The schedule is built from the WBS as a network of activities, the critical path is calculated, the approved schedule is baselined and variances are controlled against it.
Agile: Work is planned in fixed time boxes from a prioritised backlog; release dates are forecast from velocity, and progress is tracked with burndown and burnup charts rather than a baselined network.

In practiceA software release had paths of 22, 19 and 25 days, so the 25-day path was critical and the 19-day path had 6 days of float. When the sponsor asked to finish three days earlier, the project manager fast-tracked two critical-path test activities by running them in parallel, logged the added integration risk, and did not spend effort on the non-critical path, where shortening would not move the end date.
Where questions turnCompressing activities that are not on the critical path, or comparing velocity between teams; only critical-path changes move the end date, and velocity is a planning measure for one team.

Practise PRO.8

PRO.9Measure progress, keep project artifacts current and report status

Develop metrics that answer stakeholders' questions: schedule and cost (SV, SPI, CV, CPI), scope delivered (features or story points done), quality (defect rates), risk exposure and value delivered; reconcile the data (for example timesheets against invoices) so numbers agree.
Tailor the artifacts to the project: a small agile team may need a backlog, board and burnup; a regulated predictive project needs baselines, logs, registers and formal reports; avoid producing artifacts no one uses.
Make sure artifacts are created, reviewed, updated and controlled: owners, versions, a review cadence and configuration management for key documents.
Keep artifacts accessible: one shared, searchable repository with sensible permissions, readable formats and accessible design (for example colour choices readable by people with colour vision deficiency).
Assess progress with the right charts: earned value for predictive cost and schedule; a burndown (work remaining falling to zero) or burnup (work completed rising toward a total scope line, which also shows scope changes) for agile; a cumulative flow diagram where a widening band shows a bottleneck and growing WIP.
Interpret and forecast: CPI and SPI below 1 signal trouble; EAC = BAC / CPI forecasts the final cost if trends continue; a flat burnup means nothing is finishing; a team that finishes much less than planned each sprint should plan by its measured velocity.
Communicate status honestly and in the form the audience needs (dashboards, information radiators, status reports), and periodically check whether the artifact set is still useful, retiring or adding artifacts as the project changes.

Predictive: Status is measured against the scope, schedule and cost baselines with earned value and variance analysis, and reported in scheduled status reports to governance.
Agile: Status is visible in real time through the task board, burndown and burnup charts, cumulative flow and the sprint review, where stakeholders see working increments.

In practiceA hybrid ERP project's steering committee saw 'green' reports while users complained. The project manager added a burnup chart for the agile configuration stream, which showed scope growing faster than completion, and an EV table for the predictive infrastructure stream (CPI 0.95, SPI 0.88), reconciled both into one dashboard, and the committee agreed to freeze new scope for two sprints.
Where questions turnReporting activity or percent spent as progress, or using a burndown to show scope changes it cannot display; use measures of work actually completed (EV, done increments) and a burnup when total scope moves.

Practise PRO.9

PRO.10Get acceptance, hand over, and close the project or phase properly

Close the project or phase when its work is complete and accepted, or when it is terminated early (the business case no longer holds, funding is withdrawn); closing a cancelled project properly matters just as much.
Set closure criteria early: the acceptance criteria, exit criteria for each phase or release, the Definition of Done, and what counts as 'transition ready'.
Obtain formal acceptance: the customer or sponsor validates the deliverables against the agreed criteria and signs off; in agile, the product owner accepts each increment and the final release is accepted against the release goals.
Validate readiness for transition: operations or the next phase has the documentation, training, support arrangements, warranties and access it needs; a hand-over checklist and a period of supported operation (hypercare) reduce risk.
Conclude procurement: verify every contract's deliverables, settle claims, make final payments, close contracts formally and record supplier performance.
Close financially and administratively: final costs reconciled, accounts closed, unused reserves returned, records archived, and team members released with recognition and feedback to their managers.
Capture final lessons learned and retrospectives, update organisational process assets (templates, estimates, risk lists), and hand over benefits tracking to whoever owns it after the project ends.

Predictive: Closure happens at the end of each phase and the project: formal acceptance, contract closure, financial reconciliation, archiving and a final lessons learned review.
Agile: Closure is lighter and more frequent: each increment is accepted, each release is handed over to operations or users, and a final retrospective and transition plan close the product work.

In practiceWhen a regional bank's mobile app project was ended early after a merger, the project manager still held a closure review: she documented which features were complete, archived the code and designs, closed the vendor contract with a final acceptance of delivered work, returned unspent contingency, ran a retrospective, and wrote a handover note for the merged bank's digital team.
Where questions turnSkipping closure activities when a project is cancelled, or releasing the team before contracts are closed and lessons are captured; formal acceptance and administrative closure come before the team disperses.

Practise PRO.10

Key terms

Earned value (EV): The budgeted value of the work actually completed to date, used with planned value and actual cost to measure performance.
Cost performance index (CPI): EV divided by AC; below 1 means each unit spent is producing less than planned.
Estimate at completion (EAC): The forecast total cost, often BAC / CPI when current cost performance is expected to continue.
To-complete performance index (TCPI): (BAC - EV) / (BAC - AC): the cost efficiency the remaining work must reach to finish within budget.
Critical path: The longest sequence of dependent activities, which sets the shortest possible project duration; its activities have zero total float.
Total float: How long an activity can be delayed without delaying the project's end date.
Work breakdown structure (WBS): A hierarchical decomposition of the total scope into deliverables and work packages.
Contingency reserve: Budget or time within the baseline set aside for identified risks, controlled by the project manager.
Management reserve: Budget outside the baseline for unforeseen work, released only with management approval.
Cost of quality: The total of prevention and appraisal costs (conformance) and internal and external failure costs (nonconformance).
Burnup chart: A chart of completed work rising toward a total-scope line, which also shows when scope is added or removed.
Weighted shortest job first (WSJF): A prioritisation method that divides cost of delay by job size so the highest-value, smallest items go first.

After this guide: Given an exhibit of earned value figures, a schedule network or an agile chart, can you calculate the measure, say what it means for the project, and choose the action that fits the approach and the plan the project agreed?

Practise Process

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.