2. Purpose of the Standard for Project Management — §1.1

The Standard for Project Management provides a basis for understanding project management and how it facilitates intended outcomes. It applies across all industries (business, government, nonprofit), geographic regions, organizational sizes, and development approaches (predictive, adaptive, or hybrid). Rather than prescribing a single method, the Standard describes the system within which projects operate — governance, functions, the project environment, organizational culture, cross-functional teams, interactions with portfolios and programs, and the relationship between project management and other disciplines such as product management.

Per the Standard, effective project management is a strategic competency that enables organizations to:

• Align project deliverables to business strategy and associated goals
• Compete more effectively
• Ensure long-term sustainability and growth
• Drive positive change
• Respond to the impact of business environment changes
• Create a positive impact for society at large

3. Key Terms and Concepts — §1.2

The Standard defines a small set of foundational terms that recur throughout both the Standard and the PMBOK® Guide:

2. Focus on Value — §3.4

Value — also called project value — is the ultimate success indicator and driver of every project. It can be measured (e.g., return on investment) or observed qualitatively (e.g., testimonials, societal benefit), and represents the overall worth of project outcomes and net benefits to stakeholders. Every project exists to pursue objectives worth more than what is invested to pursue them. The business case and organizational strategy give the team the information needed to make decisions that meet or exceed intended value; desired outcomes should be iteratively assessed and updated using quality gates, feedback loops, and regular reviews.

Principle in action (paraphrased): a company rolling out a new internal technology system could take the conventional route — pick the product with the most features for the price, then customize it to satisfy every stakeholder request. A value-focused approach instead aligns the rollout with the actual business outcome (maximizing adoption), discovers the organization's culture prizes simplicity over feature complexity, and deliberately ships a simpler, less-customized solution — which drives higher usage and satisfaction than the feature-heavy alternative would have.

5. Integrate Sustainability Within All Project Areas — §3.7

This principle means meeting present needs without compromising future generations' ability to meet their own — considering people, planet, society, and value while carrying out project activities, and addressing environmental, social, and economic impacts. It shows up at the tactical, operational, and strategic levels of a project, and connects to the triple bottom line: evaluating a company's bottom line from the perspective of profit, people, and the planet.

The Sustainability Pyramid (Figure 3-7) ranks strategies for handling a project's externalities, from most to least desirable:

• Avoid negative outcomes altogether (most desirable)
• Minimize negative outcomes generated
• Compensate stakeholders for negative outcomes created (least desirable, but still better than ignoring the impact)

Sustainability risk arises when a project fails to balance societal, economic, and environmental considerations — e.g., prioritizing cost over environmental stewardship, ignoring community impact, or underestimating sustainability-related compliance requirements.

3. Organizational Governance Frameworks — §1.3.2

Organizational governance provides direction and control through policies, processes, procedures, and decisions to meet strategic and operational goals — typically overseen by an executive committee or organizational leaders, ensuring transparency, oversight, compliance, resiliency, and adaptability. Project governance is distinct: it focuses on the specific processes and frameworks needed to manage individual projects effectively. Both are essential and connected — project governance operationalizes organizational governance at the project level.

Governance can and should be tailored: lightweight for adaptive approaches, moderate or combined for hybrid projects, and comprehensive for large, predictive portfolios, programs, and projects. Applying the right level matters — too much governance wastes resources; too little risks poor strategic alignment and weak performance.

4. Functions Associated With Projects — §2.4

These seven functions describe what needs to happen on a project — not who does it. Each can be performed by an individual, a team, or a combination of roles, and the same function might sit with a project manager in one organization and a scrum master in another:

• Provide Oversight and Coordination — aligning effort, removing obstacles, maintaining focus; can be centralized (predictive), decentralized/self-organizing (agile), or hybrid.
• Solicit and Manage Feedback — gathering perspectives from customers, end users, or product owners; especially critical in adaptive/hybrid work due to higher ambiguity.
• Facilitate and Support — building consensus, resolving conflicts, coordinating meetings; commonly performed by PMs, scrum masters, team leads, business analysts, or change management specialists.
• Perform Work — the actual execution of project tasks.
• Apply Expertise — contributing specialized knowledge to the project's work.
• Provide Organizational Direction and Insight — connecting the project to wider organizational strategy.
• Provide Resources — securing funding, physical resources, personnel, and authority; often championed by portfolio managers and sponsors at the organizational level, then allocated by functional/resource managers.

1. Key Concepts of Project Governance

The fundamental objective of any project is to create positive value that justifies the investment and effort undertaken. Governance provides the oversight and course-corrections that steer a project toward its broader goals. Two key concepts anchor this domain:

• Leading indicators — reveal upcoming trends or changes before they become problems. If a trend looks unfavorable, the team should investigate the root cause and act. Examples: backlog size, lack of a risk management process, disengaged stakeholders, poorly defined success criteria. Preferred whenever possible, because they can prevent rework.
• Lagging indicators — measure deliverables or events after the fact (easier to measure, but reactive). Examples: number of deliverables completed, schedule/cost variance, resources consumed.

2. Governance Frameworks & Models

Project governance is the framework, functions, and processes that guide project management decisions and activities to optimize value delivery — applicable across predictive, adaptive, and hybrid approaches.

• Structured governance — typically used on more predictive projects; one or more internal/external constituents govern performance per organizational requirements; usually composed of an executive sponsor, a PMO leader, a governance board, and a PM providing project-level oversight.
• Self-governance — typically used on more adaptive projects; the team itself ensures value is delivered. Instead of a PMO leader there may be a group of PMs collectively accountable, or responsibilities distributed across the team rather than held by one titled PM. Key risk: fragmented decision-making — mitigated with clear, measurable common objectives, leading indicators, and feedback mechanisms.
• Guided self-governance — specific to agile/adaptive teams: autonomy to make decisions and manage work, but within light governance and clear-set boundaries/guardrails rather than heavy bureaucracy. Daily coordination meetings are one concrete example of a self-governing mechanism.

3. Metrics and Mechanisms for Effective Project Governance

Regardless of the governance model chosen, effective governance requires three core components:

• Target metrics clearly aligned with organizational strategic goals (e.g., ROI indicators, indicators of whether due-date performance decisions are effective, whether the current baseline still carries the highest possible value).
• Clear signaling/alarm mechanisms for those metrics, giving decision-makers a sense of whether current delivery is bringing the team closer to the strategic goal.
• Effective feedback mechanisms that let governance/integration decision-makers assess the success of their decisions and improve over time.

4. Additional Considerations for Predictive Environments

Predictive project environments may call for two additional governance components:

• Escalation — useful in hierarchical organizations where decision-making authority includes individuals outside the project team, or where higher-ranking individuals can more effectively remove persistent obstacles or resolve conflicts.
• Investment control — formal stewardship of project investment funding, common in public corporations, government agencies, and certain financial entities (e.g., retirement funds). Frequently includes a thorough risk evaluation of possible ROI. Example: lender-financed construction projects with defined decision points in the design and build phases to confirm the next funding round still makes business sense.

5. Governance Processes & Tailoring Considerations

Governance touches every Focus Area, not just Initiating:

• Initiating — the business case establishes the validity of a portfolio component, program, or project, aligning stakeholders on priorities and constraints.
• Executing — shared understanding of broader goals informs technical decisions and motivates the team, reflected in Manage Project Execution and Manage Project Knowledge.
• Monitoring & Controlling — Monitor and Control Project Performance governs effective adaptation to change toward continued value creation.
• Closing — all projects and phases eventually end, achieving their desired impact or being terminated when the value impact is no longer achievable.

Tailoring: governance can be lightweight for adaptive, moderate/combined for hybrid, and comprehensive for large predictive work. Lean/agile projects may embed governance entirely within the team's own artifacts and events rather than a separate governance structure. Tailoring is typically set during Initiate Project or Phase but may be revisited iteratively, and considerations include identifying control boards/committees/stakeholders and defining status reporting requirements.

6. Interactions With Other Performance Domains

Governance is interrelated with all other performance domains, notably:

• Scope — often the most important domain interaction, since scope is where the project's core value lies.
• Schedule — time-sensitive value propositions make this interaction critical.
• Finance — value is sensitive to cost, affecting cost overruns/underruns.
• Stakeholders — well-applied governance ensures the right people are engaged at the right time.
• Resources — requires attention to how resources are allocated across the whole organization, not just one project.
• Risk — risk responses should align with strategic objectives under clear governance to optimize risk-adjusted returns.

7. Check Results — Governance Performance Domain

Getting governance right requires balance tailored to industry, organizational structure, and project context, considered by stakeholders ranging from executives to PMO leaders to agile practitioners. Sample target outcomes from Table 2-5 include:

• Governance processes are in place, effective, and continuously improved throughout the project (not set once and forgotten).
• The team understands agreed-upon processes/protocols/team agreements, documented and aligned with other organizational governance artifacts.
• Projects have an appropriate level of oversight by leadership and third-party stakeholders.
• Lessons learned/retrospectives are managed throughout the project — not only at the end.
• Effective signaling mechanisms tied to target outcomes are in place, and the governance checklist is used regularly.
• The team has awareness of — and acts appropriately on — governance structure, internal/external auditing, compliance, and customer governance requirements.

1. Key Concepts — Product Scope vs. Project Scope

• Product scope — the features, functions, and characteristics of the product, service, or result: what it should look like and do.
• Project scope — the work performed to deliver that product/service/result with its specified features and functions. Scope encapsulates the project's expected value, making it arguably the most important component of any project's baseline.
• Requirement — a condition or capability necessary in a product/service/result to satisfy a business need.
• Quality as a feature — quality is integral to scope, including both functional and nonfunctional requirements (e.g., a bridge's scope includes not just "a bridge" but target thresholds for sturdiness, longevity, and maintainability).

2. WBS, Backlog & the Value Breakdown Structure (VBS)

• WBS (predictive/hybrid) — hierarchical decomposition of the total scope of work into manageable, assignable, trackable work packages.
• WBS Dictionary — elaborates each WBS component (scope descriptions, milestones, responsible parties, resource needs, acceptance criteria), used for complex/interdependent deliverables.
• Product backlog (adaptive) — the WBS equivalent: a dynamic, prioritized list of work items broken into epics and user stories, supporting continuous prioritization and value-driven scope management.
• Value Breakdown Structure (VBS) — a hierarchical structure connecting project scope and its intended value to product scope; top-level items are major deliverables, each carrying a value estimate (a dollar figure or a % of total expected project value), used to prioritize deliverables and estimate the "drag cost" of critical path items.
• Scope baseline — in predictive environments: the approved scope statement + WBS + WBS dictionary, forming part of the Performance Measurement Baseline (PMB) alongside schedule and cost, changed only via formal change control. In adaptive environments: reset at the start of each iteration, with the product owner dynamically approving changes without formal change control.
• Definition of Done (DoD) — a checklist of criteria a deliverable must meet to be considered ready for customer use (adaptive projects).

3. Scope Processes

• Plan Scope Management — creates the scope management plan, providing guidance so value is delivered to stakeholders.
• Elicit and Analyze Requirements — determines, documents, and manages stakeholder needs; in adaptive approaches, requirements are collected as user stories prioritized in a backlog.
• Define Scope — develops a detailed or high-level description of the project, product, and expected value, plus a quality management plan; done up front in predictive, or at the start of each iteration in adaptive.
• Develop Scope Structure — subdivides deliverables/work into smaller components: the WBS in predictive, or the product backlog breakdown (epics/features/user stories) in agile.
• Validate Scope — formalizes acceptance of completed deliverables.
• Monitor and Control Scope — ongoing monitoring/management of scope changes and measurement of deliverable quality/value against the scope baseline.

4. Tailoring Considerations — Scope

Adaptive and hybrid life cycles — scope is refined through iterations; hybrid is especially challenging since the overall project has fixed scope/schedule/cost baselines while subteams work in iterations against a backlog, requiring a more deliberately tailored approach.

Design-phase-heavy industries (pharmaceutical, construction) — invest heavily in early scope definition to prevent costly changes later; "strategic rescoping" during the design phase allows a comprehensive evaluation of direction before substantial resources are committed.

Useful scope metrics: Scope Definition Accuracy % = (Planned Scope Items Correctly Delivered ÷ Total Planned Scope Items) × 100, plus Requirements Stability % and Scope Creep %.

5. Interactions With Other Domains

Scope has a strong two-way relationship with nearly every domain, since "scope encapsulates a project's expected value" — but the most load-bearing interactions are:

• Schedule & Finance — scope, schedule, and cost together form the Performance Measurement Baseline (PMB), so a scope change ripples directly into both.
• Quality — treated as integral to scope, not separate, so scope management inherently includes quality management activities.
• Governance — as covered on Day 5, Scope–Governance is called out as often the most important domain interaction, since scope is where core value lies.
• Stakeholders — scope must reflect stakeholder-validated requirements; Validate Scope is literally a stakeholder-facing acceptance process.

6. Check Results — Scope Performance Domain

• Scope items are clearly defined in the project scope statement or backlog.
• Deliverables meet acceptance criteria and stakeholder expectations, confirmed through Validate Scope.
• Requirements remain stable, or changes are controlled — tracked via Requirements Stability % and Scope Creep %.
• The WBS or backlog includes sustainability-related activities where relevant (e.g., tracking and managing CO2 emissions from project activity).
• Stakeholder satisfaction with deliverables is confirmed through interviews, observation, and end-user feedback.

1. Key Concepts of Schedule Management

Schedule management covers the processes needed to oversee timely project completion. The schedule should stay flexible throughout the project to adjust for knowledge gained, evolving risk understanding, external influences, and value-add activities. With timelines continuously shrinking, it's often impossible to build a fully detailed schedule up front — even in predictive projects — so practitioners increasingly build schedules progressively via rolling wave planning: outline broad milestones and key activities first, then refine as more information becomes available.

• Estimate — a quantitative assessment of a variable's likely amount (e.g., effort or duration).
• Effort — the number of labor units required to complete an activity.
• Duration — the number of work periods needed to complete an activity with the estimated resources (effort and duration are related but distinct).
• Schedule forecasts — predictions based on current progress and performance trends, updated and reissued as the project executes.
• Schedule flexibility — essential for adapting to change, managing risk, optimizing resources, and supporting incremental delivery.

2. Schedule Models & the 4-Step Develop Schedule Process

The Develop Schedule process follows four steps:

• 1. Define Activities — identify and document the actions needed to produce deliverables, decomposing work packages into schedule activities.
• 2. Determine Sequence — establish logical relationships/dependencies using schedule network diagrams, the precedence diagramming method, and leads/lags.
• 3. Estimate Effort and Duration — for each activity.
• 4. Adjust — using what-if analysis, simulation, critical path/critical chain methods, resource optimization (resource leveling), schedule compression, or agile release planning.

Outputs include the schedule baseline, project schedule, and schedule data.

3. Scheduling Approaches: Predictive, Lean/Flow-Based & Location-Based

• Lean scheduling — based on lean/on-demand delivery principles; minimizes waste, maximizes value. Deliverables are not pre-assigned to the team — work is pulled when capacity exists, via pull-planning sessions defining essential activities, durations, and trade handoffs. Steps: master scheduling → phase scheduling → look-ahead planning.
• Location-based scheduling (LBS) — allocates quantities to defined locations, factoring production rates, crew sizing, task logic, and splitting/buffering needs (common in construction).
• Flow-based/Kanban scheduling — used in adaptive environments; work items flow continuously through a system with work-in-progress (WIP) limits rather than fixed-length iterations, and a new item is pulled in as soon as capacity frees up.

4. Schedule Compression & the Critical Path / Critical Chain Methods

Critical Path Method (CPM) identifies the sequence of activities representing the longest path through the project — which equals the shortest possible project duration. It uses a forward pass (earliest start/finish dates) and backward pass (latest start/finish dates without delaying the project). Example: if Activity A starts Day 1 with a 3-day duration, its early finish is Day 3 (EF = ES + Duration − 1). If an activity must finish by Day 10 (LF = 10) with a 4-day duration, its late start is Day 7 (LS = LF − Duration + 1). The gap between late and early dates is total float; activities with zero total float form the critical path.

Critical Chain Project Management (CCPM) uses nearly identical logic but also accounts for resource constraints — calling for a resource-loaded, resource-leveled critical path (RLCP), synonymous with "the critical chain." Instead of task-level buffers, CCPM aggregates variability into a single project buffer, released only when/where needed to protect the project due date, tracked via the Buffer Protection Index (BPI) (distinct from SPI, which measures variance from the schedule baseline rather than protecting the due date).

Schedule compression techniques (shorten duration without cutting scope):

• Crashing — add resources, overtime, or expedited delivery to critical-path activities to shorten duration for the least incremental cost. Increases cost/risk; only works on critical-path activities.
• Fast tracking — perform normally sequential activities/phases in parallel for part of their duration (e.g., starting foundation construction before drawings are finalized). Increases rework risk and coordination needs.

5. Tailoring Considerations — Schedule

Tailoring factors include the development approach and life cycle (heavily influencing scheduling detail and frequency), industry norms (some industries tolerate more risk than others, requiring more or less rigorous scheduling), and schedule-and-deliverable alignment — ensuring a given WBS element is described by a schedule with a commensurate level of detail, since mismatched granularity creates confusion about what will be done and when. Available scheduling methods to tailor from include the critical path method, critical chain method, location-based scheduling, the Last Planner System, Gantt charts, and Kanban.

6. Interactions With Other Performance Domains

Schedule interacts closely with Governance, Scope, Finance, Stakeholders, Resources, and Risk. Scope, Schedule, and Finance are especially tightly linked — a change in any one will likely impact the other two (recall from Day 6: together they form the Performance Measurement Baseline). Schedule is also, in parallel, indirectly connected to Stakeholders, Resources, and Risk to maintain overall project balance.

7. Check Results — Schedule Performance Domain

• Scheduling approaches are consistent with the project deliverables.
• Sufficient buffers (floats, contingency reserves, alternate network strategies) are built in for known constraints and risks.
• Stakeholders are involved in schedule development — low involvement may lead to an unrealistic or poorly developed schedule.
• Appropriate scheduling tools and techniques (e.g., CPM) were used.
• Schedule documentation includes task dependencies, durations, resource allocations, and milestones.
• A holistic approach to delivery is developed with no gaps or misalignment; project phases are represented from launch to close with appropriate exit criteria.

1. Key Concepts of Project Finance

The Finance domain addresses the use and allocation of monetary resources, internal and external, to the performing organization — relating to costs, funding, and the value proposition.

• Funding — how a project acquires financial resources: internal budgets, customer contracts, grants, or crowdfunding. PMs may lead or support these activities.
• Financial constraints — budget is the primary constraint but not the only one; a project may be restricted to specific resource types (e.g., CapEx vs. OpEx, internal vs. external personnel), each carrying different budget strategies.
• Contingency reserve — time/money for known risks with active response strategies, usually inside the initial project budget.
• Management reserve — time/money set aside for unknown-unknowns, in addition to the schedule/cost baseline, typically released at senior leadership's discretion.
• Cost baseline — the approved, time-phased project budget excluding management reserves (and sometimes excluding contingency reserves too, depending on organizational convention), changed only via formal change control.

2. Financial Processes — Estimating, Budgeting & Ongoing Control

The Finance domain covers planning, estimating, budgeting, financing, funding, managing, measuring, and controlling costs so the project can optimize value. Financial measures are used to evaluate performance against plan, track resource utilization and budget expended, and demonstrate accountability. Monitor and Control Finances runs throughout the project — not just at the start — to catch deviations, optimize resource allocation, and keep the project aligned with financial goals.

3. Cost of Quality (CoQ)

Cost of Quality breaks into two categories:

• Conformance costs — Prevention costs (preventing poor quality up front) and Appraisal costs (evaluating, measuring, auditing, testing).
• Nonconformance costs — Failure costs, internal and external: money spent during and after the project because of failures to meet stakeholder needs/expectations.

Spending on prevention and appraisal upfront typically reduces the much larger cost of failures later — echoing the "prevention over inspection" theme from Day 2's Embed Quality principle.

4. Earned Value Management (EVM) — Conceptual Overview

EVM objectively measures project performance by integrating scope, schedule, and cost data:

• Planned Value (PV) — the authorized budget assigned to scheduled work.
• Earned Value (EV) — the measure of work performed, expressed in terms of the budget authorized for that work.
• Actual Cost (AC) — the realized cost incurred for work performed.
• Cost Variance (CV) = EV − AC (budget surplus or deficit at a point in time).
• Cost Performance Index (CPI) = EV ÷ AC (cost efficiency ratio).
• Estimate to Complete (ETC) — expected cost to finish remaining work.
• Estimate at Completion (EAC) = actual cost to date + ETC.

5. Tailoring Considerations — Finance

• Development approach — iterative approaches use time-phased budgeting and continuous funding assessment, flattening the spend curve versus predictive's more front-loaded planning.
• Product/industry — heavily regulated industries (financial, pharmaceutical) may require formal controls for compliance (e.g., SOX, GDPR) to protect financial data integrity.
• Procurement strategy — make-or-buy decisions connect directly to financial tailoring; buy decisions require selecting a contract type (fixed-price vs. time & materials) based on risk distribution and cost certainty.
• Organization size/risk tolerance — small projects need conservative reserves given limited financial flexibility; government-sector projects typically need a larger buffer given public accountability and regulatory scrutiny.

6. Interactions With Other Domains

Finance is one of the key pillars of project success, providing access to necessary resources. Financial resources/constraints have a direct two-way impact on Governance, Scope, and Schedule; Finance is also impacted, more indirectly, by Stakeholders and Risk. The overarching goal is maximizing value delivery, connecting project results to organizational strategy.

7. Check Results — Finance Performance Domain

The headline check outcome: the project contributes to business objectives and the advancement of organizational strategy — financial success is measured not merely by "staying under budget," but by whether the spending actually advanced strategic goals. Supporting outcomes include financial measures being actively used to evaluate performance, appropriately sized reserves being available when needed, and financial tailoring decisions (iterative budgeting, compliance controls) being followed as designed.

1. Key Concepts of Stakeholders

The Stakeholders domain covers engagement from identification through monitoring across the whole project life cycle. Anyone impacted by — or who feels they may be impacted by — the project counts as a stakeholder. This domain is closely linked to communications management; key skills to develop include negotiation and conflict management.

Stakeholders can be internal or external, individuals, groups, or organizations (Figure 2-31 examples: Project Team, PM Team, PM, PMO, Governing Bodies, Sponsor, Steering Committees, Customers, End Users, Suppliers/Vendors, Regulatory Bodies, Local Communities, Family). A project can have a handful of stakeholders or millions; their influence, power, and interest can change as the project unfolds, and some will be supportive, some neutral, and some opponents.

2. Stakeholder Identification & Classification Techniques

• Power/interest grid (or power/influence, impact/influence grid) — groups stakeholders by authority level and concern/influence; best for smaller, simpler stakeholder communities.
• Salience model — classifies stakeholders by power, urgency, and legitimacy (or proximity in an adapted version); useful for large, complex stakeholder networks.
• Directions of influence — classifies stakeholders as upward, downward, outward, or sideward relative to the project team.
• Stakeholder cube — a refinement combining grid elements into a three-dimensional model, giving a richer, multidimensional view and helping shape communication strategies for large/complex communities.

3. The Stakeholder Engagement Assessment Matrix

Classifies each stakeholder's engagement level into five categories:

• Unaware — unaware of the project and its impacts.
• Resistant — aware but resistant to change from the project.
• Neutral — aware but neither supportive nor unsupportive.
• Supportive — aware and supportive of the work and its outcomes.
• Leading — aware and actively engaged in ensuring the project succeeds.

The matrix plots "C" (current engagement level) against "D" (desired level) for each stakeholder — the gap between C and D drives how much communication effort that stakeholder needs. Closing this gap is a core element of monitoring stakeholder engagement.

4. Stakeholder Processes

• Identify Stakeholders — selects individuals/groups with a stake, analyzing interests/influence/impact; performed periodically, doubling as a risk-management strategy as the environment evolves.
• Plan Stakeholder Engagement — develops strategies based on needs, expectations, and potential impact.
• Plan Communications Management — plans how to communicate; overlaps with identification/analysis/prioritization.
• Manage Stakeholder Engagement — communicates and works with stakeholders, addresses issues, increases support and minimizes resistance.
• Manage Communications — sets up and conducts communications: timely collection, creation, distribution, storage, retrieval, and disposition of information.
• Monitor Stakeholder Engagement and Monitor Communications — assess effectiveness and refine strategies as the project evolves.

5. Tailoring Considerations — Stakeholders

Agile projects use continuous feedback via daily coordination meetings and real-time platforms. Large-scale implementations (e.g., ERP rollouts) may need formal, scheduled updates (biweekly newsletters, monthly town halls) across hierarchical levels. Global/multicultural projects need inclusive strategies — multilingual updates, monthly virtual forums — to sustain engagement across cultural backgrounds. In general, a complex project with many stakeholders needs a more sophisticated communications plan than a smaller project with limited, well-known channels.

6. Interactions With Other Performance Domains

Stakeholders "permeate all aspects of projects" — they define/prioritize requirements and scope, shape planning, and determine acceptance/quality criteria. Stakeholders can either lower or increase project uncertainty, especially if the right ones aren't identified early and updated throughout. Stakeholders closely interact with Governance (skills to engage governance bodies/leadership) and Finance (stakeholders often define budgets, make funding decisions, oversee financial controls).

7. Check Results — Stakeholders Performance Domain

• Stakeholder engagement is maintained (feedback via interviews/surveys, periodic alignment checks, indicators like Net Promoter Score).
• The communications management plan is reviewed periodically and tailored to stakeholder needs.
• Stakeholder agreement with project objectives is achieved (feedback on increments in adaptive projects).
• Risk responses are identified and successfully implemented (issue log/risk register/stakeholder register review).
• Project plans are integrated with suppliers'/vendors' perspectives.

1. Key Concepts — Human, Physical/Material & Virtual Resources

The Resources domain covers how effectively/efficiently a project team plans for and utilizes its available resources: human resources (the project team) and physical/virtual resources (equipment, materials, supplies, facilities, infrastructure, software, testing environments, licenses, services, information, documents). Different skills are needed to manage people vs. physical/virtual resources.

Key role distinction: the Project Manager focuses on this project's overall performance, guiding and empowering their specific team, while the Resource Manager focuses on the organization's entire pool of resources, allocating staff/equipment across many projects. In many organizations, the PM must negotiate with resource managers rather than unilaterally assigning staff.

2. Resource Processes

• Plan Resource Management — establishes the approach and level of management effort based on project type/complexity.
• Estimate Resources — estimates team resources plus type/quantity of physical or virtual resources; closely coordinated with Estimate Costs, since resource needs drive the budget.
• Acquire Resources — obtains the team, physical, or virtual resources needed.
• Lead the Team — the people process: motivating, developing, empowering the team via colocation, virtual teams, recognition/rewards, training, emotional intelligence, leadership styles, the Tuckman ladder, coaching/mentoring.
• Monitor and Control Resourcing — ensures physical/virtual resources are available as planned, tracks planned vs. actual use, releases resources when no longer needed (team members are covered separately, in Lead the Team).

3. Team Development Stages (Tuckman Ladder) & Emotional Intelligence

The Tuckman ladder describes team development stages (a team can get stuck, regress, or skip a stage if members have worked together before):

• Forming — members meet, learn roles; tend to be independent and not very open.
• Storming — the team addresses project work, technical decisions, and the PM approach; can turn counterproductive if members aren't collaborative.
• Norming — members begin working together, adjusting habits, learning to trust one another.
• Performing — a well-organized, interdependent unit that works through issues smoothly.

Emotional intelligence has four converging components (Figure 5-11): Self-Awareness (realistic self-assessment), Self-Management (controlling disruptive impulses), Social Awareness (empathy, reading nonverbal cues), and Social Skills (building rapport, managing groups).

4. High-Performing Teams & Virtual Teams

High-performing team factors: open communication, trust, shared ownership, shared understanding, collaboration, adaptability, resilience, empowerment/autonomy, and recognition.

Virtual teams face heightened challenges (varying work styles, time zones, no in-person contact). Recommended practices: audio/video/virtual conferencing for meetings; ongoing contact via messaging; collaboration sites; a shared project team site; scheduling time to get to know remote members; and creating a team charter defining ways of working.

Employee well-being is a modern concern: "quiet quitting" (doing the minimum, not volunteering, reduced engagement) is countered by mental health initiatives, flexible schedules, and generous time off.

5. Tailoring Considerations — Resources

Leadership style should adapt to team experience: experienced, self-managing teams need less oversight, while teams new to a project type need more structured leadership. Adaptive, high-variability projects make resource planning less predictable, requiring flexible agreements and lean methods to control costs. Virtual team formation may need explicit guidance on collaboration tools (see Topic 4), and employee well-being concerns increasingly shape resource tailoring decisions.

6. Interactions With Other Domains

Resources interacts with all other performance domains. Stakeholders, Resources, and Risk together significantly impact outcomes measured by schedule, cost, and scope. Resources also compete across projects — other projects may need the same people/equipment at the same time, impacting cost, schedule, risk, scope, and quality. Estimate Resources is closely coordinated with Estimate Costs to keep resource planning aligned with the overall budget.

7. Check Results — Resources Performance Domain

Sample outcomes: resource efficiency is tracked (actual usage vs. planned usage); asset management is effective (material scrap rate, equipment downtime tracked); shared ownership and vision are present across the team; the team demonstrates trust, collaboration, and resilience; resource allocation supports the project without unnecessary competition or delay.

1. Key Concepts — Individual vs. Overall Project Risk

Individual project risk is an uncertain event/condition that, if it occurs, has a positive or negative effect on one or more objectives. Overall project risk is the combined effect of uncertainty on the project as a whole — not simply the sum of individual risks; it can exceed that sum, since it also captures ambiguity and complexity.

• Risk appetite — the degree of uncertainty an organization/individual will accept in anticipation of a reward.
• Risk threshold — the acceptable variation around an objective reflecting risk appetite (e.g., ±5% around a cost objective = lower risk appetite than ±10%).
• Risk exposure — the aggregate measure of potential impact of all risks at a given point in time.

Risk categories can be organized via a Risk Breakdown Structure (RBS) — e.g., Technical, Management, Commercial, and External categories, each with subcategories.

2. Risk Identification & Analysis

Identify Risks identifies project threats and opportunities — separating real risks from mere concerns is an important part of this process. It begins at project conception and continues iteratively, since initial identification is always incomplete. Perform Risk Analysis combines Qualitative analysis (evaluates probability/impact plus manageability, timing, relationships between risks) and Quantitative analysis (assesses the combined effect of risks/uncertainties on objectives; not always required). Plan Risk Management should begin at project conception and be completed early.

3. Risk Response Strategies — Threats

• Avoid — eliminate the threat or protect the project from it (remove the cause, extend schedule, change strategy, reduce scope); for high-priority, high-probability, high-impact threats.
• Mitigate — reduce probability and/or impact; early mitigation beats repairing damage after the fact.
• Transfer — shift ownership to a third party who bears the impact (insurance, bonds, warranties); usually involves a risk premium.
• Escalate — when the threat is outside the project's scope or the response exceeds the PM's authority; managed at portfolio/program/org level.
• Accept — acknowledge with no proactive action; for low-priority threats. Can be Active (establish a contingency reserve) or Passive (periodic review only).

4. Risk Response Strategies — Opportunities & Overall Project Risk

Opportunity strategies mirror the threat strategies:

• Exploit — take focused action to guarantee the opportunity happens, raising probability to 100%.
• Enhance — increase probability and/or impact of a positive opportunity.
• Share — transfer ownership to a third party better positioned to capture it (joint ventures, risk-sharing partnerships).
• Escalate and Accept — work the same way as for threats, just applied to a positive outcome.

The same five categories also apply to overall project risk, not just individual risks — e.g., an overall-level Avoid might mean removing high-risk scope elements, or even canceling the project as the most extreme form of avoidance.

5. Risk Register, Risk Report & Implementing Responses

Plan Risk Responses develops actions to address both overall project risk exposure and individual risks. Implement Risk Responses actually executes those plans — a distinct step from planning; plans that are never executed provide no protection. Monitor Risks tracks and analyzes risks, implements response plans, and evaluates effectiveness throughout the project.

Key artifacts: the risk register (identified risks, responses, owners, related data, updated continuously) and the risk report (overall project risk plus summary-level individual risk information). Project resilience — the ability to absorb impacts and recover quickly — is especially relevant to "black swan" events and true unknown-unknowns.

6. Tailoring Considerations & Interactions

Predictive projects typically apply heavier, upfront risk management — scope is fixed, so time/cost flex to absorb risk. Adaptive projects manage risk iteratively via self-governance, since time/cost are more fixed (timeboxed/budgeted) while scope flexes instead. Hybrid projects blend both approaches. Effective risk response requires integrating scope management, schedule planning, financial considerations, stakeholder engagement, and communication — Risk touches essentially every other domain.

7. Check Results — Risk Performance Domain

Sample outcomes: a realistic approach to evaluating uncertainty, risks, and responses; the project responds to uncertainty within budget, schedule, and performance constraints; the team understands the consequences of issues and risks; risk conditions stay within threshold; project performance and outcomes are realized by leveraging and tracking the realization of opportunities (not just avoiding threats); the risk management approach evolves throughout the project as new constraints emerge.

Task 1: Develop a Common Vision

• Help ensure a shared vision with key stakeholders
• Promote the shared vision
• Keep the vision current
• Break down situations to identify the root cause of a misunderstanding of the vision

Cross-reference: project vision as part of the agile project charter (Day 19), and stakeholder alignment techniques (Day 9).

Task 2: Manage Conflicts

• Identify conflict sources
• Analyze the context for the conflict
• Implement an agreed-on resolution strategy
• Communicate conflict management principles with the team and external stakeholders
• Establish an environment that fosters adherence to common ground rules
• Manage and rectify ground rule violations

Cross-reference: ground rules and team agreements as part of team chartering (Day 19), and servant-leader facilitation of team dynamics (Day 18).

Task 3: Lead the Project Team

• Establish expectations at the team level
• Empower the team
• Solve problems
• Represent the voice of the team
• Support the team's varied experiences, skills, and perspectives
• Determine an appropriate leadership style
• Establish clear roles and responsibilities within the team

Cross-reference: situational leadership (Day 13), servant leadership (Day 18), Tuckman ladder and emotional intelligence (Day 10).

Task 4: Engage Stakeholders

• Identify stakeholders
• Analyze stakeholders
• Analyze and tailor communication to stakeholder needs
• Execute the stakeholder engagement plan
• Optimize alignment among stakeholder needs, expectations, and project objectives
• Build trust and influence stakeholders to accomplish project objectives

Cross-reference: the full Stakeholders Performance Domain, including the engagement assessment matrix and classification models (Day 9).

Task 5: Align Stakeholder Expectations

• Categorize stakeholders
• Identify stakeholder expectations
• Facilitate discussions to align expectations
• Organize and act on mentoring opportunities

Cross-reference: stakeholder classification models — power/interest grid, salience model, stakeholder cube (Day 9).

Task 6: Manage Stakeholder Expectations

• Identify internal and external customer expectations
• Align and maintain outcomes to internal and external customer expectations
• Monitor internal and external customer satisfaction/expectations and respond as needed

Cross-reference: Monitor Stakeholder Engagement process and the Net Promoter Score check outcome (Day 9).

Task 7: Help Ensure Knowledge Transfer

• Identify knowledge critical to the project
• Gather knowledge
• Foster an environment for knowledge transfer

Cross-reference: lessons learned register and organizational learning (Days 12, 15); mentoring/coaching under servant leadership (Day 18).

Task 8: Plan and Manage Communication

• Define a communication strategy
• Promote transparency and collaboration
• Establish a feedback loop
• Understand reporting requirements
• Create reports aligned with sponsors and stakeholder expectations
• Support reporting and governance processes

Cross-reference: Plan/Manage/Monitor Communications processes (Day 9); active listening as a cross-cutting tool (Day 13); Governance's reporting/escalation mechanisms (Day 5).