PMP Deep Course — Part I: Foundations

How this book works. This is a full-depth course, built part by part. Each topic
follows the same rhythm: a plain-language explanation of what it is, why it matters,
the mechanics/detail, real-world examples, the exam traps people fall into, and
practice questions with answers. Read actively: pause at each example and try to
predict the answer before reading on. Part I builds the mental scaffolding everything
else hangs on — don't skip it, even the "obvious" parts, because the exam tests
precise distinctions here (project vs operations, OPA vs EEF, process group vs
phase) that feel obvious until a question twists them.

Chapter 1 — Projects, Programs, Portfolios, and Operations

1.1 What exactly is a project?

A project is a temporary effort undertaken to create a unique product, service, or result.

Two words carry all the weight:

-​ Temporary — it has a definite beginning and a definite end. The end comes when the
objectives are met, when it becomes clear they can't be met, when the need no longer
exists, or when funding is withdrawn. "Temporary" does not mean short — building a
dam can take a decade and still be a project. It also doesn't mean the result is
temporary; a bridge lasts a century, but the project to build it ended.
-​ Unique — the deliverable differs in some meaningful way from everything before it.
Even your tenth "identical" warehouse sits on different soil, with a different crew, different
weather, different permits. The uniqueness is why you can't just run it on autopilot.

A project is also progressively elaborated: you learn as you go, so the plan gets more detailed
and accurate over time. Early on you have a fuzzy outline; by execution you have precise
specs. This is not scope creep — it's the planned refinement of detail.

Why projects exist: to create value for the organization. This is the single most important
framing on the modern exam. A project is never an end in itself; it's a vehicle to deliver a benefit
— more revenue, lower cost, compliance, a strategic capability. Hold onto this: if an exam
answer ignores value/benefit, it's suspect.

Real-world example. Your plant decides to install a new aseptic filling line. That's a
project: temporary (it ends when the line is commissioned and handed over),
 unique (this exact line, this layout, this integration with existing utilities has never
been done here before), and it exists to deliver value (capacity, new product format,
lower scrap). Once it's running and you're producing cartons every shift, that's no
longer the project — that's operations.

1.2 Operations — and the project/operations boundary

Operations are ongoing and repetitive: producing the same output day after day to sustain the
business. Running the filling line every shift, doing routine PMs, paying invoices — operations.

Project Operations

Duration Temporary (has an end) Ongoing

Output Unique result Repetitive output

Goal Achieve objective, then close Sustain the business

Example Installing the new line Running the line every day

The boundary matters because projects hand off to operations at the end (transition/closure),
and because the exam loves to test whether you can classify a scenario. A recurring monthly
report is operations; building the system that generates it is a project.

Exam trap. "A team performs the same maintenance procedure every week."
That's operations, not a project — repetitive and ongoing. But "a team develops a
new standardized maintenance procedure to roll out across all plants" is a project
(unique result, temporary).

1.3 Programs and portfolios — the hierarchy

Projects don't exist in isolation. PMI organizes work in three tiers:

-​ Project: a single temporary effort with a unique result.

-​ Program: a group of related projects managed together to get benefits you couldn't
get by managing them separately. The key word is related — the projects share a
common objective, and coordinating them produces synergy. A program manager
focuses on the interdependencies between projects and on delivering the combined
benefit.
-​ Portfolio: a collection of projects, programs, and operations managed as a group to
achieve strategic objectives. A portfolio is about doing the right work — choosing,
prioritizing, and balancing investments so the organization's resources go to what
matters most. The projects in a portfolio need not be related; what unites them is that
they all compete for the same strategic resources.
The clean way to remember the difference in focus:

-​ Portfolio management = doing the right work (selection, prioritization, strategic

alignment).
-​ Program management = managing related work together for combined benefit
(coordination of interdependencies).
-​ Project management = doing the work right (delivering a specific result).

Real-world example. Your company's strategy is "modernize all manufacturing by

2028."

-​ The portfolio is every initiative competing for the modernization budget:

new lines, an ERP upgrade, a sustainability program, ongoing operations.
Leadership decides which to fund.
-​ A program within it might be "Plant-wide Digitalization" — several related
projects (SCADA upgrade, CMMS rollout, IoT sensors) coordinated so the
combined data platform delivers a benefit none of them could alone.
-​ A project within that program is the specific "CMMS rollout."

Exam trap. "Related projects managed together for benefit" = program.

"Projects/programs grouped for strategic objectives, not necessarily related" =
portfolio. The discriminators are related (program) vs strategic alignment / not
necessarily related (portfolio).

1.4 Practice questions — Chapter 1

Q1. A company builds 50 identical-looking modular homes on 50 different lots over two years. Is
each home a project? Answer: Each can be treated as a project (or as phases of one program),
because each is temporary and unique (different lot, conditions, permits). The "identical"
design doesn't remove uniqueness — context differs. The exam point: uniqueness isn't only
about the design; it's about the whole delivery context.

Q2. Leadership is choosing which of twelve proposed initiatives to fund this year based on
strategic fit and ROI. What management discipline is this? Answer: Portfolio management —
selecting and prioritizing the right work for strategic objectives.

Q3. A manager coordinates five related projects so their shared infrastructure delivers a benefit
none could deliver alone. What is this? Answer: A program — related projects managed
together for combined benefit.
Chapter 2 — Project Life Cycles: Predictive, Iterative,
Incremental, Adaptive, Hybrid
A project life cycle is the series of phases a project passes through from start to finish. How
you move through those phases — how much you plan up front, how often you deliver, how you
handle change — defines the development approach. This is foundational because ~half the
exam is agile/hybrid, and almost every situational question hides an assumption about which
approach you're in.

2.1 Predictive (plan-driven / "waterfall")

You define scope, schedule, and cost in detail up front, then execute against that plan.
Change is possible but is controlled formally (through integrated change control). You deliver
the product typically once, near the end.

-​ Best when: requirements are well understood and stable, the work is well understood,
and the risk of change is low. Construction, infrastructure, regulated manufacturing.
-​ Strength: predictability — stakeholders know early what they'll get, when, and for how
much.
-​ Weakness: poor at absorbing change; if requirements shift late, rework is expensive.

Example. Pouring a building's foundation. You can't "iterate" a foundation — you

plan it fully, get it right, and build on it. Predictive fits.

2.2 Iterative and Incremental (the building blocks of agile)

These two words get confused constantly, so pin them down:

-​ Iterative = you repeat cycles to refine and improve the same thing. You build a rough
version, get feedback, and improve it over successive passes. Think of an artist
sketching, then refining the same drawing.
-​ Incremental = you deliver in finished pieces that each add usable functionality. You build
and hand over a working slice, then another, then another. Think of building a house
room by room, each room finished and usable.

Agile typically combines both: deliver working increments (incremental) while refining based on
feedback (iterative).

Example. Building a reporting dashboard. Incremental: deliver the

production-output chart first (usable on its own), then add the downtime chart, then
the OEE chart. Iterative: show a rough version of the output chart, get the operators'
feedback, refine it next cycle.
2.3 Adaptive / Agile
Scope is flexible and evolves; you work in short timeboxes (iterations/sprints), deliver working
increments frequently, and welcome change by reprioritizing a backlog. Requirements are
expected to emerge and shift.

-​ Best when: requirements are uncertain or volatile, the environment changes fast, and
frequent feedback reduces risk. Software, R&D, product development.
-​ Strength: fast feedback, early value, resilience to change.
-​ Weakness: less up-front predictability of the exact final scope and total cost.

2.4 Hybrid
A blend — use predictive where the work is stable and adaptive where it's uncertain, within the
same project. This is extremely common in the real world and well represented on the exam.

Example. A new product launch: the manufacturing line installation runs

predictively (fixed engineering, regulated, sequential), while the companion mobile
app is built in sprints (uncertain features, fast feedback). One project, two
approaches — hybrid.

2.5 Choosing an approach (the continuum)

Think of a dial from fully predictive to fully adaptive. Push toward adaptive when requirements
are uncertain, change is likely, feedback is valuable, and the team can deliver incrementally.
Push toward predictive when requirements are firm, the process is well understood, change is
costly, and compliance demands up-front definition. Tailor the dial to the work — there is no
single "right" approach.

Exam trap. Questions signal the approach with vocabulary. "Sprint," "backlog,"
"product owner," "iteration" → adaptive; answer in agile terms. "Baseline," "WBS,"
"change control board," "phase gate" → predictive; answer in predictive terms.
Read for these cues before choosing.

2.6 Phase gates

Between phases, a phase gate (a.k.a. stage gate, kill point, or review) is a decision point where
leadership reviews progress against the business case and decides whether to continue,
change, or stop. This enforces the "deliver value" principle — a project that no longer makes
business sense should be stopped at a gate, even if it's technically on track.
2.7 Practice questions — Chapter 2
Q1. A team delivers a usable login feature, then later a usable payments feature, each complete
on its own. Iterative or incremental? Answer: Incremental — each delivery is a finished, usable
piece.

Q2. A team shows a rough prototype, gathers feedback, and refines the same feature over
three cycles. Iterative or incremental? Answer: Iterative — repeated refinement of the same
thing.

Q3. A regulated chemical plant build with stable, fully-specified requirements should lean toward
which approach? Answer: Predictive — stable requirements, high cost of change, compliance
needs up-front definition.

Chapter 3 — Process Groups and Knowledge Areas

The predictive backbone of project management is organized two ways that intersect: five
Process Groups (the logical flow of managing a project) and ten Knowledge Areas (the
subject domains). Each gets a deep chapter later; here you need the map and the common
misconceptions.

3.1 The five Process Groups

1.​ Initiating — authorize the project or phase. Key outputs: project charter, initial
stakeholder identification. This is where the PM is formally empowered.
2.​ Planning — define and refine objectives and plan how to achieve them. Produces the
project management plan and all baselines. The largest group by number of
processes.
3.​ Executing — do the work; coordinate people and resources to produce deliverables.
This is where most of the budget is spent.
4.​ Monitoring & Controlling — track, review, and regulate progress; manage changes.
Runs throughout the project, in parallel with the others.
5.​ Closing — finalize all activities to formally close the project or phase; hand off, release
resources, capture final lessons learned.

Critical misconception to kill: Process Groups are not phases and not sequential in a strict
waterfall sense. They overlap and iterate. You plan, execute, discover something, re-plan,
execute more. Monitoring & Controlling is continuous. A phase is a chunk of the project (e.g.,
"design phase"); within each phase you may run all five process groups.
 Example. In the "design" phase of your line installation you initiate the phase, plan
the design work, execute the drawings, monitor progress against the design
schedule, and close the phase with a design review. Then the "installation" phase
runs its own cycle.

3.2 The ten Knowledge Areas (the map)

1.​ Integration — the glue; the only area the PM uniquely owns; coordinates everything.
2.​ Scope — what's in and out; requirements, WBS.
3.​ Schedule — time; activities, sequencing, critical path.
4.​ Cost — budget, estimating, earned value.
5.​ Quality — fitness for purpose; prevention over inspection.
6.​ Resource — people and physical resources.
7.​ Communications — the right info to the right people at the right time.
8.​ Risk — uncertainty, threats and opportunities.
9.​ Procurement — buying goods/services; contracts.
10.​Stakeholder — identifying and engaging the people who affect or are affected.

Each Knowledge Area has processes spread across the Process Groups. (Example: Cost has
"Plan Cost Management" and "Estimate Costs" and "Determine Budget" in Planning, and
"Control Costs" in Monitoring & Controlling.) You'll get the full deep treatment of each in Parts
III–V.

3.3 Practice questions — Chapter 3

Q1. True or false: Monitoring & Controlling happens only after Executing finishes. Answer:
False. M&C runs continuously, in parallel with Executing (and the others), throughout the
project.

Q2. In which Process Group is the project charter created? Answer: Initiating.

Q3. Which Knowledge Area does the project manager uniquely own and use to coordinate all
others? Answer: Integration.

Chapter 4 — Organizational Structures and Their Effect on the

PM
The structure of the organization heavily shapes how much authority the project manager
has and how hard it is to get resources. The exam tests this constantly because the "right"
action often depends on whether you're a powerful PM or a near-powerless coordinator.
4.1 The spectrum
Structure PM authority Resource Who controls PM role is…
availability the budget

Functional Little to none Little Functional Part-time, often

manager a coordinator

Weak matrix Low Low Functional Coordinator/exp

manager editer

Balanced Moderate Moderate Mixed Full-time PM,

matrix shared power

Strong matrix Moderate–high Moderate–high PM (mostly) Full-time PM

Projectized High to total High PM Full-time, full

authority

-​ Functional: the classic siloed org (engineering, maintenance, finance). People report to
functional managers; the PM (if any) has little authority and must influence and negotiate
for everything.
-​ Matrix: a blend. Team members have two bosses — their functional manager and the
PM. The "weak/balanced/strong" label tells you which boss has more power. Matrix
creates the classic resource tug-of-war the exam loves.
-​ Projectized: the organization is built around projects. The PM has high authority,
controls the budget, and the team reports to the PM. When the project ends, the team is
reassigned.

Example. You're a maintenance manager in a functional plant. To get an

electrician's time for your improvement project, you must negotiate with the
electrical functional manager — you can't just assign them, because they don't
report to you. That negotiation-first reality is exactly what the exam expects you to
recognize.

Exam trap. When a question says you're in a weak matrix or functional org and
asks how to get resources, the answer is negotiate with the functional manager
first — and escalate only if that fails. Don't pick "assign the resource" (you can't) or
"escalate immediately" (premature).

4.2 The PMO (Project Management Office)

A PMO standardizes and supports project work. Three types by degree of control:
 -​ Supportive — provides templates, training, best practices, and a repository. Low
control. Acts as a consultant. Example: "Here are our standard templates if you'd like to
use them."
-​ Controlling — provides support and requires compliance (frameworks, methodologies,
governance). Moderate control. Example: "You must use the approved methodology
and pass our gate reviews."
-​ Directive — actually manages the projects; PMs report into the PMO. High control.
Example: "The PMO assigns the project manager and runs the project."

Exam trap. The discriminator is the degree of control. "Templates and guidance,
optional" = supportive. "Must comply" = controlling. "PMO runs the projects" =
directive.

4.3 Practice questions — Chapter 4

Q1. In a strong matrix, who generally has more authority over project priorities — the PM or the
functional manager? Answer: The project manager (that's what "strong" means), though power
is still shared.

Q2. A PMO mandates a methodology and audits compliance but does not run the projects.
Which type? Answer: Controlling.

Q3. You're a project coordinator in a functional org and need a specialist's time. First move?
Answer: Negotiate with their functional manager.

Chapter 5 — Organizational Process Assets (OPA) vs Enterprise

Environmental Factors (EEF)
This pair is one of the most-tested foundational distinctions, and one of the most confused. Get
it crisp.

5.1 OPA — things your organization has created that help you run the
project
Organizational Process Assets are the organization's internal, owned knowledge and
process artifacts. They're things you can use and update. Two families:

1.​ Processes, policies, procedures — templates, checklists, standardized methods,

guidelines, the change control process. (Generally these you use but don't change
mid-project.)
 2.​ Organizational knowledge bases — historical information and lessons learned, past
project files, estimating databases, configuration management knowledge, financial data.
(These you both use and update.)

The mental test: "Did my organization make this, and can I draw on it or add to it?" → OPA.

Examples of OPA: your company's project charter template; the lessons-learned

repository from past line installations; the standard risk checklist; historical cost
estimates for similar work; the approved change request form.

5.2 EEF — conditions you operate within but don't control

Enterprise Environmental Factors are conditions that influence the project but are not under
the project team's control. They can be internal to the company or external.

-​ Internal EEFs: organizational culture and structure, geographic distribution of

facilities, available infrastructure and IT systems, resource availability, employee
capability.
-​ External EEFs: government regulations and standards, market conditions, legal
constraints, the political climate, currency exchange rates, physical environment,
industry standards.

The mental test: "Is this a condition I have to work within, that I didn't create and can't simply
change?" → EEF.

Examples of EEF: a new food-safety regulation; the company's risk-averse culture;

the going market rate for contractors; the ERP system you must use; exchange-rate
volatility affecting imported parts.

5.3 The classic confusions

-​ Organizational culture = EEF (a condition you operate within), not OPA. People miss
this because culture is "internal." Internal ≠ OPA; the test is created-and-usable-asset
(OPA) vs condition-you-work-within (EEF).
-​ Lessons learned / historical data = OPA (created knowledge you draw on).
-​ Government regulations = EEF (external condition).
-​ Templates and standard processes = OPA.

Exam trap. "The team consults the lessons-learned register from a similar past
project." → OPA. "A new environmental regulation affects the design." → EEF. "The
company's hierarchical, risk-averse culture slows decisions." → EEF (internal, but
still a condition, not an asset).
5.4 Practice questions — Chapter 5
Q1. Classify: the organization's standard WBS template. Answer: OPA (a created, reusable
process asset).

Q2. Classify: a newly enacted safety standard the product must meet. Answer: EEF (external
regulatory condition).

Q3. Classify: the organization's risk-averse culture. Answer: EEF (internal condition you operate
within — not an OPA).

Q4. Classify: the historical cost database from past projects. Answer: OPA (organizational
knowledge base).

Chapter 6 — The Project Manager: Role, Influence, and Tailoring

6.1 The PM's sphere of influence

A project manager influences far more than just the team. Concentric circles: the project (lead
the team, deliver the result) → the organization (work with sponsors, functional managers, the
PMO, other PMs) → the industry and profession (standards, continuing development) →
across disciplines (interacting with diverse specialists). The PM is the integrator and the
communication hub — which is why ~90% of the role is communication.

6.2 The PMI Talent Triangle

PMI frames the skills a modern PM needs as a triangle (updated wording, same spirit):

-​ Ways of Working (technical) — the craft of managing: predictive, agile, hybrid

methods, scheduling, EVM, risk, etc.
-​ Power Skills (leadership) — interpersonal skills: communication, emotional
intelligence, conflict resolution, motivation, influence.
-​ Business Acumen (strategic) — understanding the organization, strategy, and how the
project delivers business value.

The exam (and modern practice) emphasizes power skills and business acumen heavily, not
just technical mechanics. A PM who can schedule perfectly but can't lead people or connect
work to value will fail the exam's situational questions.
6.3 Servant leadership (introduced here, deep in Part II)
The dominant leadership stance the exam rewards: the leader serves the team — removing
impediments, coaching, protecting focus, and enabling self-organization — rather than
commanding. Keep this lens on every People-domain question.

6.4 Tailoring
No single process set fits every project. Tailoring is deliberately selecting and adjusting the
processes, tools, techniques, life cycle, and governance to fit the project's context — its size,
complexity, risk, industry, regulatory environment, and organizational culture. Tailoring is
expected, not optional; the exam treats a PM who blindly applies a fixed method to every project
as doing it wrong.

Example. A two-week internal tool build doesn't need the full risk-management
apparatus of a multi-year regulated plant project. You tailor down. Conversely, a
high-risk, high-visibility project warrants more rigorous controls. You tailor up.

6.5 Practice questions — Chapter 6

Q1. Which leg of the Talent Triangle covers conflict resolution and emotional intelligence?
Answer: Power Skills (leadership).

Q2. A PM applies the identical heavyweight process to a tiny low-risk project and a huge
regulated one. What's the error? Answer: Failure to tailor — the approach should fit each
project's context.

Chapter 7 — Principles and Performance Domains (the modern

lens)
The current exam is built on the Examination Content Outline (ECO) — three domains,
People/Process/Business — but it's informed by the latest standard's principles and
performance domains. You don't need to memorize them word-for-word, but understanding
them makes the situational questions click, because they encode the mindset.

7.1 The twelve principles (the "why" behind good behavior)

In plain terms, a good project manager and team:

1.​ Be a diligent, respectful, caring steward — act ethically and responsibly with
resources and trust.
 2.​ Create a collaborative team environment — culture and shared ownership.
3.​ Effectively engage stakeholders — proactively, throughout.
4.​ Focus on value — the ultimate measure of success.
5.​ Recognize and respond to system interactions — see the project as a system in a
bigger system (holistic thinking).
6.​ Demonstrate leadership behaviors — at every level, not just the PM.
7.​ Tailor based on context — fit the approach to the situation.
8.​ Build quality into processes and deliverables — prevention over inspection.
9.​ Navigate complexity — recognize and address ambiguity and complexity.
10.​Optimize risk responses — address threats and opportunities.
11.​Embrace adaptability and resiliency — recover and adjust.
12.​Enable change to achieve the envisioned future state — help people adopt the
change (change management).

Notice how each principle is an exam instinct: focus on value, engage stakeholders early, build
quality in, tailor, embrace change, lead and serve.

7.2 The eight performance domains (the "where the work happens")
1.​ Stakeholders — engagement throughout.
2.​ Team — building and leading a high-performing team.
3.​ Development Approach and Life Cycle — predictive/adaptive/hybrid choices.
4.​ Planning — organizing and coordinating the work.
5.​ Project Work — managing the execution, processes, and resources.
6.​ Delivery — producing the scope and quality that delivers value.
7.​ Measurement — assessing performance (EVM, metrics, KPIs).
8.​ Uncertainty — risk, ambiguity, complexity, volatility.

These map closely onto the deep chapters ahead. When you read Part III's Schedule and Cost
chapters, you're really living in the Planning, Project Work, and Measurement domains.

7.3 Practice questions — Chapter 7

Q1. "On time and on budget, but the expected benefit won't materialize." Which principle says
this is still a failure? Answer: Focus on value — value is the ultimate measure of success.

Q2. A PM helps end users adopt a new system, not just deliver it. Which principle? Answer:
Enable change (change management toward the future state).
Part I wrap-up and what's next
You now have the scaffolding: what projects/programs/portfolios are, how life cycles and
approaches differ, how the process groups and knowledge areas fit together, how organizational
structure and the PMO shape your authority, the OPA/EEF distinction, the PM's role and the
Talent Triangle, and the principles/performance domains that encode the mindset.

Self-check before moving on. Can you, from memory: (1) state the two defining words of a
project and why they matter; (2) distinguish program from portfolio by their focus; (3) tell iterative
from incremental; (4) place functional/matrix/projectized on an authority spectrum; (5) classify
five items as OPA or EEF; (6) name the three legs of the Talent Triangle? If any are shaky,
re-read that section — these exact distinctions get tested.

Part II — People domain (deep) is next: leadership styles, servant leadership in depth, team
development through Tuckman with real coaching moves, the full set of motivation theories,
conflict management with worked scenarios, emotional intelligence, communication models,
stakeholder engagement mechanics, negotiation and power, and leading virtual and diverse
teams — each with examples, traps, and practice questions.

Say "continue" and I'll build Part II at this same depth.