The PMP is not a memorisation exam. It tests how you think as a project manager through situational questions, so the goal of studying is to internalise the “PMP mindset” and become equally comfortable with predictive, agile and hybrid delivery. This guide is a full, self-study course: it walks through each of the three domains in depth, explains the concepts behind the scenarios, shows where earned value, the critical path and risk strategies actually apply, and then turns all of it into a week-by-week plan. It is original teaching material and study guidance only. It contains no real or simulated exam questions, and you should always confirm current rules and weights against PMI’s own Exam Content Outline before you book.
Chapter 1: Exam overview and how to use this guide
What the PMP actually measures
The PMP measures whether you can lead a project competently in the situations real project managers face, not whether you can recite a process. PMI’s current Exam Content Outline (in force since 2021) organises the exam into three domains: People at 42%, Process at 50%, and Business Environment at 8%. Those weights are the single most important planning fact in this guide, because they tell you where your study hours should go. Roughly half of all questions reflect agile or hybrid ways of working rather than traditional predictive delivery, so agile is not a bonus topic, it is woven through every domain.
The exam is 180 questions in 230 minutes, with two scheduled breaks, and it mixes multiple-choice, multiple-response, matching, and hotspot formats. Most questions are situational: a short scenario followed by “what do you do next?” or “what should the project manager have done?”. That phrasing is deliberate. PMI is testing judgement under realistic pressure, so two answers will often both be defensible and your job is to pick the one that best reflects how a capable, modern project manager behaves.
The reference standards behind the questions
The questions are anchored to PMI’s standards rather than to any one textbook. The current edition is the PMBOK Guide, Seventh Edition, which moved away from the old “49 processes” model and is now built around twelve principles of project management and eight performance domains. The older, process-based PMBOK Sixth Edition language (process groups, inputs, tools and outputs) still circulates widely and is still useful for understanding mechanics like earned value, so this course teaches the concepts from both worlds where they help you reason. The exam itself is principle and outcome focused: it cares that you know why you would, say, hold a retrospective or run a risk review, far more than it cares whether you can name an input to a process.
How to use this course
Read the chapters in order at least once, because the People and Process chapters build the mindset that the Business Environment, agile, and situational-judgement chapters then apply. Treat the bold concept names as a checklist. By the end you should be able to explain each one in a sentence and say when it applies. The last three chapters turn the content into a schedule, a final-preparation routine, and a description of exam day. A short worked example appears wherever a concept is easy to misread, but none of these are exam questions: they are teaching illustrations to make the idea concrete.
Chapter 2: The People domain (42%)
The People domain is about leading and building the team, and it is the second-largest slice of the exam. The unifying idea is servant leadership: the project manager exists to remove obstacles, grow the team, and create the conditions for good work, rather than to command and control. Almost every People scenario can be solved by asking, “what would a supportive leader who trusts the team do here, before escalating?”.
Conflict management
Conflict is normal and, handled well, productive. The exam wants you to address conflict directly and early, at the lowest level possible, and to deal with the underlying issue rather than the personalities. The classic model of conflict-handling modes is worth knowing as a vocabulary: collaborating (or problem-solving) seeks a win-win and is usually the preferred answer because it resolves the root cause; compromising trades concessions and is a reasonable fallback; smoothing (accommodating) emphasises agreement and downplays differences; forcing imposes one view and is generally a last resort; withdrawing (avoiding) postpones the issue and is rarely right on the exam.
When a scenario describes two team members in conflict, the strong answer is almost always to bring them together to understand and solve the real problem, not to pick a side, not to escalate to the sponsor, and not to ignore it in the hope it passes. As a teaching example: if two developers disagree on an approach and it is slowing the team, a servant leader facilitates a conversation where both explain their reasoning and the team agrees on a path, rather than the manager simply deciding. The point the exam rewards is that you went to the source and solved it collaboratively.
Leading and building the team
Leading a team is about more than assigning tasks. The exam expects you to recognise where a team sits on its development journey and to lead accordingly. A useful frame is the team-development sequence of forming, storming, norming, performing, and adjourning: a brand-new team needs direction and clear goals, a storming team needs conflict facilitation, a norming team needs lighter-touch support, and a performing team can be largely trusted to self-organise. Reading the stage tells you how much to intervene.
Two further ideas show up repeatedly. First, a team charter and ground rules set agreed ways of working early and prevent many later problems, so establishing them is a strong “what should you do at the start” answer. Second, empowerment and self-organisation are the default in modern delivery: where a scenario offers “decide for the team” versus “let the team decide”, the team-led option usually wins, because PMI’s model trusts those doing the work to plan the work. Recognising and rewarding contribution, investing in training, and protecting the team from outside disruption are all part of building a high-performing team.
Stakeholder engagement
Stakeholders are anyone affected by, or able to affect, the project, and engaging them well is a recurring theme across both the People and Business Environment domains. The core sequence is identify, analyse, plan, engage, and monitor: you find your stakeholders, assess their interest and influence, decide how much and how to communicate with each, then keep that engagement alive and adjust it as attitudes shift. A common analysis tool is a power/interest grid, which sorts stakeholders by how much power they hold and how much interest they have, so you can decide who to manage closely, keep satisfied, keep informed, or simply monitor.
The exam’s instinct is proactive and communication-first. When a stakeholder is unhappy, surprised, or disengaged, the strong answer is usually to talk to them directly to understand their concerns and adjust engagement, not to escalate or to carry on regardless. As a teaching example: if a key sponsor has stopped attending reviews, you would reach out to understand why and re-establish the right level of involvement, rather than simply reporting the absence upward. Engaging before escalating is one of the most reliable patterns in the People domain.
Virtual and cross-cultural teams
Distributed and cross-cultural teams are explicitly in scope, reflecting how projects actually run. The skills the exam looks for are deliberate communication and inclusion. With virtual teams, you compensate for the loss of informal contact by being intentional: agreed communication tools and norms, overlap hours that respect time zones, regular video contact to build trust, and extra care that remote members are not excluded from decisions. With cross-cultural teams, you stay aware that norms around directness, hierarchy, and feedback differ, and you adapt your communication rather than assuming one style fits all. The underlying principle is the same as everywhere in this domain: remove the barriers that stop people contributing.
Servant leadership as the through-line
Pull the People domain together and it is one idea applied repeatedly. The project manager serves the team: clearing impediments, facilitating rather than dictating, communicating early and directly, and trusting the people doing the work. When two People answers both look reasonable, prefer the one that empowers the team and tackles the real issue at its source. That single habit resolves a large share of People-domain scenarios.
Chapter 3: The Process domain (50%)
The Process domain is the largest slice of the exam and covers the technical craft of delivering a project: defining and controlling the work, managing time, cost, quality, risk and procurement, and integrating it all through disciplined change control. The exam tests the intent behind these practices and when to tailor them, across predictive, agile, and hybrid settings, rather than rote inputs and outputs.
Scope management
Scope is the sum of the work required to deliver the product, and managing it means defining it clearly and then controlling change. In predictive projects you build a scope baseline, often decomposed into a work breakdown structure (WBS) that breaks deliverables down into manageable work packages, and you guard against scope creep, the uncontrolled addition of work without corresponding adjustments to time, cost, or agreement. In agile projects scope is deliberately flexible: a prioritised product backlog holds the work, and the team delivers the highest-value items first, accepting that lower-priority scope may change. The exam reads the context. If the setting is predictive and scope is changing, the answer involves change control; if it is agile, evolving scope is expected and handled through reprioritising the backlog.
Schedule management
Schedule management is about sequencing work and managing time realistically. In predictive planning, the critical path is the longest sequence of dependent activities through the schedule, and it determines the shortest possible project duration. Activities on the critical path have zero float (or slack), meaning any delay to them delays the whole project, so they are where your attention belongs. Knowing this lets you reason about scenarios: if a non-critical task slips within its float, the end date is safe; if a critical task slips, the project is late unless you act. To recover time you can crash the schedule (add resources to critical activities, usually at extra cost) or fast-track it (run activities in parallel that were planned in sequence, usually at extra risk). In agile delivery, time is handled through timeboxing: fixed-length iterations deliver whatever is ready, and velocity, the amount of work a team completes per iteration, is used to forecast.
Cost management and earned value
Cost management means estimating, budgeting, and then controlling spend against the plan. The exam’s main analytical tool here is earned value management (EVM), which integrates scope, schedule, and cost into a single set of measures. It rests on three values at any point in time: Planned Value (PV), the budgeted cost of the work that was scheduled to be done by now; Earned Value (EV), the budgeted cost of the work actually completed; and Actual Cost (AC), what that completed work actually cost.
From those three you derive the rest. Cost Variance (CV) = EV minus AC, so a positive CV means under budget and a negative CV means over budget. Schedule Variance (SV) = EV minus PV, so a positive SV means ahead of schedule and a negative SV means behind. The two indices express the same ideas as ratios: the Cost Performance Index (CPI) = EV divided by AC, where above 1.0 is good (you are getting more value than you spend) and below 1.0 is poor; and the Schedule Performance Index (SPI) = EV divided by PV, where above 1.0 means ahead of schedule and below 1.0 means behind. The clean way to remember the signs: EV always comes first; for the cost family you compare against AC, and for the schedule family you compare against PV; subtract for a variance, divide for an index.
Forecasting uses the Estimate at Completion (EAC), the expected total cost of the project given current performance. The most common form when current cost performance is assumed to continue is EAC = BAC divided by CPI, where BAC (Budget at Completion) is the original total budget; this is equivalent to EAC = AC + (BAC minus EV) divided by CPI. The Estimate to Complete (ETC) = EAC minus AC is what the rest of the project is expected to cost from now. As a teaching example to read the indices: if a project has spent its money efficiently but lagged on delivery, you would expect a CPI at or above 1.0 and an SPI below 1.0, which tells you the issue is schedule, not cost, and points you toward schedule recovery rather than budget cuts.
Quality management
Quality means the project delivers what it was meant to deliver, fit for purpose, and the exam draws a clear line between two ideas. Quality assurance is process-focused and preventive: building quality in through good practices, standards, and audits so defects are less likely. Quality control is product-focused and inspective: checking the actual deliverables against requirements to catch defects. The mindset the exam rewards is prevention over inspection, because preventing a defect is cheaper than finding and fixing one later, an idea captured in the cost of quality (the total of prevention and appraisal costs versus the failure costs you incur when quality is poor). Continuous improvement, the steady refinement of how the team works, sits underneath both and is especially prominent in agile, where retrospectives feed improvement every iteration.
Risk management
Risk is uncertainty that could affect objectives, and it cuts both ways: a threat is a negative risk and an opportunity is a positive one. The process is to identify risks, analyse them (qualitatively by probability and impact, and sometimes quantitatively), plan responses, and then monitor as the project evolves. A risk register records each risk, its analysis, its owner, and the planned response.
The response strategies are worth knowing precisely, because the exam often hands you a situation and asks which strategy is being used. For threats: avoid (eliminate the cause so the risk cannot occur), transfer (shift the impact to a third party, for example through insurance or a fixed-price contract), mitigate (reduce the probability or impact), and accept (take no proactive action, usually with a contingency reserve set aside). For opportunities the strategies mirror these: exploit (make sure the opportunity happens), share (partner with someone better placed to capture it), enhance (increase its probability or impact), and accept (take advantage of it if it arises but do nothing to pursue it). Escalate applies to both when the risk is outside the project’s authority and belongs to management or the wider organisation. As a teaching example: buying insurance against a specific loss is transfer, while adding a design safeguard so the loss cannot occur is avoidance, and recognising the difference is exactly what these questions test.
Procurement management
Procurement is how the project buys goods or services it does not produce itself, and the exam’s interest is mainly in contract types and the buyer-seller relationship. The key distinction is who carries the cost risk. A fixed-price contract places the cost risk on the seller, because the price is agreed regardless of the seller’s actual costs, which suits well-defined work. A cost-reimbursable contract places more risk on the buyer, who reimburses the seller’s costs plus a fee, which suits work whose scope is not yet clear. Time-and-materials contracts sit between the two and are common for staff augmentation or smaller, open-ended efforts. You should also recognise that procurement still requires planning, clear requirements, fair selection, and active management of the contract through to closure.
Integration and change control
Integration is the project manager’s job of holding everything together so the parts form a coherent whole, and its sharpest expression is integrated change control. The principle is that changes are not made informally: a proposed change is documented, its impact on scope, schedule, cost, quality, and risk is assessed, and it is approved or rejected through the agreed process, often by a change control board in predictive settings, before any baseline is updated. This is why “evaluate the impact of the change” and “follow the change control process” are such reliable predictive answers. In agile settings the equivalent discipline is lighter and continuous: changes flow into the backlog and are reprioritised, so the team absorbs change by re-sequencing rather than by formal board approval. Either way, the exam rewards controlled, transparent handling of change over either rigid refusal or uncontrolled acceptance.
Chapter 4: The Business Environment domain (8%)
The Business Environment domain is the smallest slice of the exam, but it is where individual questions are often quickest to answer if you hold the right idea: a project exists to deliver business value, not merely to produce outputs on time and budget.
Compliance and governance
Compliance covers the external and internal rules a project must satisfy: laws, regulations, industry standards, and organisational policies. The exam treats compliance as non-negotiable and proactive. When a scenario involves a regulatory or legal requirement, you plan for it, build it into the work, and address gaps rather than working around them, because compliance failures carry consequences a project cannot trade away. Governance is the broader framework of oversight and decision rights that keeps the project aligned with the organisation’s standards and accountable to it.
Benefits realisation and value
A project is justified by the benefits it is meant to create, captured in a business case at the outset and tracked through a benefits realisation view that asks whether those benefits are actually being achieved. The mindset the exam rewards is to keep the end value in sight throughout: if circumstances change so that a project will no longer deliver its intended value, the right response may be to raise that with the sponsor rather than to keep delivering for its own sake. Linking project work back to organisational strategy, and being able to say which strategic objective a piece of work serves, is the heart of this domain.
Organisational change
Most projects change how people work, and that change has to be led, not just delivered. The exam expects awareness that adoption depends on preparing stakeholders, communicating the reasons for change, and supporting people through the transition, so that the project’s outputs are actually used and the intended benefits land. A technically finished deliverable that no one adopts has not delivered value, which is why organisational change and benefits realisation sit so close together.
Chapter 5: Agile, hybrid, and predictive delivery
Because roughly half the exam reflects agile or hybrid ways of working, you need to be fluent in all three delivery approaches and, more importantly, in choosing between them. This is not a separate topic bolted on at the end. It runs through every domain.
Predictive, agile, and the spectrum between
Predictive (often called waterfall) delivery plans the scope, schedule, and cost up front and then executes against that plan, which suits projects where requirements are well understood and stable, such as construction or regulated manufacturing. Agile delivery embraces change: it works in short iterations, delivers value incrementally, and re-plans frequently as it learns, which suits projects where requirements are uncertain or expected to evolve, such as new product development. Most real projects sit somewhere on the spectrum between the two.
When to choose which
The exam frequently asks you to match an approach to a situation, so reason from the level of uncertainty and the need for early value. Choose predictive when requirements are clear and unlikely to change, when the work must follow a fixed sequence, or when regulation demands detailed up-front documentation. Choose agile when requirements are unclear or volatile, when early and frequent delivery of value matters, and when close, continuous collaboration with the customer is possible. As a teaching example: building to a fixed engineering specification leans predictive, while developing a new app whose features will be shaped by user feedback leans agile, and the scenario’s clues about stability and feedback are what point you to the answer.
Hybrid in practice
Hybrid delivery combines elements of both, and it is increasingly the realistic answer. A common pattern runs the well-understood parts of a project predictively while running the uncertain or innovative parts in agile iterations, for instance fixing an overall timeline and budget for governance while letting a development workstream iterate inside it. The exam rewards the judgement that you can tailor the approach to the project rather than forcing one method onto everything, which is the principle of tailoring applied to delivery as a whole.
Agile roles, events, and metrics
You should recognise the common agile vocabulary even though the exam is framework-agnostic. The product owner owns and prioritises the backlog to maximise value; the facilitator (a Scrum Master in Scrum) serves the team by removing impediments and protecting the process; and the development team self-organises to deliver. Familiar events include short iterations (sprints), a brief daily coordination meeting, a review or demo of completed work, and a retrospective where the team improves how it works. For measurement, agile favours empirical, value-oriented metrics over up-front baselines: velocity forecasts how much a team can deliver per iteration, a burndown or burnup chart shows work remaining or completed against time, and cycle time and lead time measure how quickly work flows through. The thread connecting all of these is fast feedback and continuous improvement, the same instinct that runs through the People and Process domains.
Chapter 6: The PMI mindset and situational judgement
The single skill that determines most PMP results is choosing the answer that reflects how PMI expects a project manager to think. The exam calls these situational questions, and they are deliberately written so that more than one option is plausible. This chapter is about how to choose.
What the PMI mindset is
The PMI mindset is proactive servant leadership. A capable project manager prevents problems rather than reacting to them, empowers and trusts the team rather than controlling it, communicates early and directly with stakeholders rather than going silent or going over their heads, keeps the project aligned to business value, and tailors the approach to the situation. Most wrong answers fail on one of these counts: they are reactive, controlling, avoidant, or they jump to escalation.
How to choose the best answer
Approach each scenario the same way. First, read the question carefully and notice what it is really asking, especially the word “next”, which means you should choose the immediate, appropriate step rather than the eventual outcome. Second, identify the real problem, because the best answer addresses the root cause, not a symptom. Third, eliminate the answers that contradict the mindset: anything that ignores the issue, blames or commands the team, or escalates prematurely is usually wrong. Among what remains, prefer the option that is proactive, empowers the team, communicates directly, and gathers information before acting drastically.
A reliable ordering helps when two answers survive: understand the situation, then act within the team’s authority, and only then escalate. Gathering information and talking to the people involved almost always beats jumping straight to a sponsor or to a contractual remedy. As a teaching example of the pattern: when something has gone wrong, the strong answer is typically to investigate the cause and address it with those involved, rather than to immediately report it upward or to impose a fix without understanding why it happened. Escalation is a real and correct option, but only once the issue genuinely sits beyond the project’s authority.
Common traps
A handful of instincts reliably lead to wrong answers, so name them and resist them. Avoid the command-and-control answer that has the project manager dictating to the team. Avoid the escalate-first answer that skips understanding and engagement. Avoid the do-nothing answer that hopes a problem resolves itself. And avoid the rigid-process answer that ignores the chance to tailor or to respond to change, especially in agile contexts where adapting is the point. Choosing against these four traps, in favour of proactive servant leadership, is what carries you through the situational core of the exam.
Chapter 7: Study plan and timeline
With the content understood, the remaining work is pacing it so that nothing, least of all the agile content and the situational practice, gets squeezed out at the end. Three things drive the plan: the prerequisite course, the domain weights, and the need to practise judgement over weeks rather than cramming it.
Clear the gate first
Before self-study proper, complete the required 35 contact hours of project-management education from an accredited provider, which is a hard prerequisite for sitting the exam, and begin documenting your project-leadership experience, since PMI requires it and may audit your application. Many candidates use the 35-hour course as their first structured pass through the material. Then download PMI’s free Exam Content Outline and let it, rather than any single book, define your scope.
Allocate time by domain weight
Spend your hours roughly in proportion to the weights, with the most going to Process (50%) and People (42%), studied together because real scenarios blend the technical work with leading the team, and a short focused pass on Business Environment (8%). Carry predictive, agile, and hybrid through every domain rather than treating agile as a separate module, because about half the questions lean that way.
Choose a timeline
A balanced self-study plan runs about eight weeks at eight to ten hours a week: weeks one to two on the Exam Content Outline and the predictive/agile/hybrid landscape; weeks three to six on the Process and People domains together; week seven on Business Environment and consolidating the mindset, with situational practice added daily; and week eight on full-length, timed mocks and review. A gentler plan runs twelve weeks at five to six hours, stretching the same sequence and starting light situational practice from around week five. Experienced project managers who already work in People and Process daily can compress to a four-to-six-week intensive at twelve to fifteen hours a week, spending the first two to three weeks closing agile and hybrid gaps and the last one to two almost entirely on situational questions and mocks. To turn whichever timeline you pick into dated weeks for your own start date, use the free study-plan generator.
Build judgement throughout, not at the end
Move from reading to answering scenario questions as soon as you have covered a domain, not on the last weekend, because the habit of choosing the servant-leadership or agile answer has to be built over weeks. Keep a steady diet of situational practice through the middle of the plan and ramp it up toward the end, and each time articulate why the best option reflects the PMI mindset, since that reasoning is exactly what the exam rewards. If you are still weighing the PMP against an agile-specialist route before committing, the PMP vs PMI-ACP comparison covers scope, agile focus, and eligibility.
Chapter 8: Final preparation, exam day, and format
Final preparation
In the last week or two, shift from topic study to full-length, timed practice, treating each session as both an endurance run and a diagnosis. Note which domain and which mindset slips leak marks, and review why the best answer beats the plausible wrong ones rather than only checking your score. Aim to be scoring comfortably above your target on fresh material before you book. Keep your application records accurate alongside your studying, because PMI may audit the documented experience you claimed, and a clean record removes a source of late stress.
Eligibility and the application
The application has to clear before the studying matters. You need 35 contact hours of formal project-management education plus documented experience, broadly 36 months leading projects with a four-year degree, or 60 months without one. PMI may audit what you claim, so record your projects, roles, and hours accurately as you prepare, and confirm the current rules on PMI’s site, since eligibility gates your exam date.
Exam day and format
On the day, the exam is 180 questions in 230 minutes with two scheduled breaks, taken either at a Pearson VUE test centre or via online proctoring, and you will need government-issued identification. The formats mix multiple-choice, multiple-response (where you select more than one option), matching, and hotspot questions, and most are situational. Pace yourself against the clock so the long sitting does not run away from you, use the scheduled breaks to reset, and apply the same disciplined reading and mindset-first reasoning you practised: understand the situation, address the root cause, empower the team, and escalate only when the issue truly sits beyond the project’s authority. Having practised at full length, the format will feel familiar rather than overwhelming, which is exactly the advantage you built over the weeks of study.