Forget "phases you walk through one at a time." A performance domain is a group of related activities that's critical to delivering the project — and all eight of them are active concurrently, from day one to close-out, interacting and leaning on each other the whole way. This chapter is the map of that whole system before you zoom into any single piece of it.
Definitions, straight from the slides, before anything else.
Productive relationships with everyone who can affect or be affected by the project.
The people producing the deliverables — management vs. leadership, culture, high performance.
Predictive, hybrid, or adaptive — and the phases that connect start to finish.
Estimates, schedules, budgets, resources, procurement — organizing the coordinated path.
Establishing processes, managing physical resources, and fostering learning.
Scope and quality that actually realize the business value the project was chartered to deliver.
Metrics, baselines, dashboards — turning data into timely, appropriate action.
Risk, ambiguity, complexity, and volatility — and how to work with each of them.
"Technical project management skills are important, but having the interpersonal and leadership skills to work effectively with stakeholders is maybe more important." — straight off the slide.
Addresses activities and functions associated with stakeholders. A stakeholder is an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio. Stakeholder analysis systematically gathers and analyzes quantitative and qualitative information to determine whose interests should be taken into account throughout the project — including internal and external stakeholders, and those supportive, unsupportive, or neutral.
Outer ring: Suppliers, Customers,
End Users, Regulatory Bodies. Middle ring: Governing Bodies, PMOs,
Steering Committees. Inner ring (closest to the work): Project Manager,
Project Management Team, Project Team.
| Productive working relationship | Observed relationships; movement of stakeholders along a continuum of engagement indicates relative satisfaction. |
| Stakeholder agreement with objectives | A significant number of scope/requirement changes may indicate stakeholders are not engaged or aligned. |
| Beneficiaries supportive; opponents contained | Stakeholder behavior; surveys, interviews, focus groups; a review of the issue & risk registers. |
Addresses activities and functions associated with the people responsible for producing project deliverables that realize business outcomes.
| Decentralized | Centralized |
|---|---|
| Middle/low-level managers have decision-making power | A few upper-management members have decision-making power |
| Authority given to those closer to stakeholders | Authority given to those at the top of the chain of command |
| Organizations are self-sufficient | More standardization |
| Faster decision making | More control |
| More expensive | Less expensive |
| More creativity | Limited creativity |
Transparency, integrity, respect, positive discourse, support, courage, celebrating success — modeled by the PM to keep the environment safe, respectful, nonjudgmental.
Addresses activities and functions associated with the development approach, cadence, and life cycle phases of the project.
Requirements defined, collected, analyzed upfront. Used with significant investment/high risk needing frequent reviews & change control. Scope, schedule, cost, resources, risk are well-defined early and relatively stable. Reduces uncertainty early; heavy upfront planning.
Combines predictive + adaptive elements. Useful when requirements carry uncertainty/risk, or when deliverables can be modularized / built by different teams.
For requirements with high uncertainty/volatility that will change throughout the project. Clear vision set upfront; requirements refined via feedback. Iterative + incremental; iterations often 1–2 weeks with a demo at the end. Team is heavily engaged in planning each iteration.
Product variables: degree of
innovation, requirements certainty, scope stability, ease of change, delivery options,
risk, safety requirements, regulations.
Project variables: stakeholders (adaptive needs heavy involvement; product owner
prioritizes work), schedule constraints (early delivery favors iterative/adaptive), funding
availability (funding uncertainty favors adaptive; an MVP needs less investment and
enables market testing).
Organizational variables: structure, culture, capability, team size & location.
The timing/frequency of deliveries — single, multiple, or periodic. For digital products, continuous delivery ships feature increments immediately via small batches + automation (seen in DevOps, #noprojects, Continuous Digital).
Addresses activities and functions associated with the initial, ongoing, and evolving organization and coordination necessary for delivering project deliverables and outcomes.
Predictive: start with high-level
deliverables, decompose via a scope statement and/or WBS.
Iterative/Incremental:
themes/epics → features → user stories/backlog items. Novel or risky work is prioritized
to reduce uncertainty before major investment (the last responsible moment: defer
a decision until the cost of further delay would exceed the benefit).
| Mandatory | Contractually required or inherent in the work. Usually cannot be modified. |
|---|---|
| Discretionary | Based on best practices or preferences. May be modifiable. |
| External | Between project and non-project activities. Usually cannot be modified. |
| Internal | Between one or more project activities. May be modifiable. |
A high-level release plan sets features per release; each release has 2+ iterations; each iteration adds value (features, risk reduction, experimentation). Future-release planning stays high-level so it can still change based on feedback. Often uses timeboxes: team estimates what it can do, self-manages, demonstrates completed work, then reprioritizes the backlog.
Work Cost Estimates aggregate into the Cost Baseline (time-phased budget, allocated across the schedule) → add Contingency Reserve → add Management Reserve → Project Budget.
Physical resources = anything that isn't a person (materials, equipment, software, licenses...). Planning includes supply chain, logistics, lead time for delivery/movement/storage. A make-or-buy analysis identifies what's built in-house vs. purchased externally once high-level scope is known — this impacts both team and schedule.
| Progresses organized, coordinated, deliberate | Performance review vs. baselines shows the project is on plan; variances within thresholds. |
| Holistic approach to delivering outcomes | Delivery schedule, funding, resource availability, procurements show no gaps or misalignment. |
| Evolving information is elaborated | Initial vs. current information about deliverables/requirements shows appropriate elaboration. |
| Time spent planning is appropriate | Plans/documents show a level of planning appropriate for the project. |
| Planning info sufficient for expectations | Communications plan and stakeholder info show communications are sufficient. |
| Process exists for adapting plans | Backlogs show adaptation; change logs/change control board minutes show the process is applied. |
Addresses activities and functions associated with establishing project processes, managing physical resources, and fostering a learning environment.
The PM and team establish and periodically review the processes used to conduct the work — e.g. reviewing task boards for bottlenecks, work-flow rate, or impediments. Process tailoring optimizes process for the project's needs: large/critical projects generally carry more process than small/less-significant ones. Ways to optimize: lean production methods, retrospectives / lessons learned, asking "where is the next best funding spent?" Teams spend just enough time on process-conformance review to maximize benefit while still satisfying governance needs — time spent tracking conformance is time not spent delivering outcomes.
Constraints — fixed delivery dates, regulatory compliance, a predetermined budget, quality policies — can shift throughout the project. A new stakeholder requirement may mean expanding schedule and budget; a budget cut may mean relaxing a quality requirement or reducing scope. This ongoing balancing act may involve presenting alternatives to the customer/sponsor/product owner, or may be entirely within the team's own authority to trade off.
Project managers usually don't have contracting authority — they work with contracting officers/professionals who know contracts, laws, and regulations. Organizations have rigorous policies identifying who has authority, its limits, and the process to follow. Before going out to bid, the PM and technically qualified team members work with contracting professionals to develop the RFP, statement of work (SOW), and terms and conditions.
| Term | Meaning / example |
|---|---|
| Bid Documents | All documents used to solicit information, quotations, or proposals from prospective sellers. |
| Bidder Conference | Pre-bid meetings ensuring vendors share a common understanding. Also: contractor/vendor/pre-bid conferences. |
| Request for Information (RFI) | Learning what capabilities/vendors exist before deciding on a solution (e.g. exploring software platforms). |
| Request for Proposal (RFP) | Inviting vendors to bid on building a specific, already-decided solution. |
| Request for Quote (RFQ) | Asking multiple vendors for best price/timeline on a well-defined need (e.g. 500 laptops to spec). |
Addresses activities and functions associated with delivering the scope and quality that the project was undertaken to achieve.
Development approaches that release deliverables throughout the life cycle can start delivering value to the business early — and business value often keeps accruing long after the project itself has ended. A business case document provides the justification and a projection of anticipated value; its format varies with the chosen development approach and life cycle.
Much of the cost tied to quality is borne by the sponsoring organization — reflected in policies, procedures, and work processes — even though it's employed by the project (overhead, training, process audit). The COQ methodology is used to find the right balance between investing in prevention and appraisal, versus risking defect/product failure.
| Projects contribute to business objectives | Business plan + strategic plan + authorizing documents demonstrate alignment. |
| Projects realize the outcomes they were initiated to deliver | Business case and underlying data show the project is still on track. |
| Benefits realized in planned time frame | Benefits realization plan, business case, schedule show financial metrics/deliveries on track. |
| Team has clear understanding of requirements | Predictive: little change in initial requirements. Evolving: clarity may not emerge until well into the project. |
| Stakeholders accept & are satisfied | Interviews, observation, end-user feedback; complaint/return levels. |
Addresses activities and functions associated with assessing project performance and taking appropriate actions to maintain acceptable performance.
Measuring takes time and effort that could otherwise go into productive work — so teams should only measure what's relevant and useful.
| Category | Examples |
|---|---|
| Deliverable | Errors/defects, measures of performance, technical performance measures |
| Delivery | Work in progress, lead time, cycle time, process efficiency |
| Baseline performance | Start/finish dates, effort & duration, schedule variance |
| Resources | Planned vs. actual resource utilization & cost |
| Business value | Cost-benefit ratio, ROI, Net Present Value (NPV) |
| Stakeholders | Net Promoter Score (NPS), mood chart, morale, turnover |
| Forecasts | Estimate to Complete (ETC), Estimate at Completion (EAC), Variance at Completion (VAC) |
Dashboards: status summaries
(schedule/resources/budget with color-coded status: on track, complete, concern, issue,
on hold, canceled, not started).
Information radiators: burndown charts (work
remaining), burnup charts (work completed), combined burn charts (both at once), plus risk
logs.
Visual controls: task boards, burn charts, cycle time / lead time
tracking.
| Reliable understanding of project status | Audit measurements/reports show if data is reliable. |
| Actionable data for decision making | Measurements indicate whether performance is as expected or shows variance. |
| Timely, appropriate actions to stay on track | Leading indicators and/or current status lead to timely decisions. |
| Achieving targets via reliable forecasts | Comparing past forecasts to present performance, and planned vs. actual, shows likelihood of realizing intended value. |
Addresses activities and functions associated with risk and uncertainty.
| Systems-based | Decoupling (disconnect parts to simplify + reduce connected variables); Simulation (learn from similar unrelated scenarios). |
|---|---|
| Reframing | Diversity (view from diverse perspectives, brainstorm, Delphi-like convergence); Balance (mix forecasting + lagging data so variations counteract each other). |
| Process-based | Iterate (build incrementally, learn each cycle); Engage (build in stakeholder engagement to reduce assumptions); Fail safe (build redundancy / graceful degradation for critical elements). |
Negative risks are called threats; positive risks are called opportunities. All projects have risk since they're unique undertakings with varying degrees of uncertainty. Overall project risk is often a function of complexity, ambiguity, and volatility together — responses apply to the whole project, not one event; if overall risk is too high, the organization may cancel the project.
A frequent rhythm of review and feedback from a broad set of stakeholders helps navigate risk proactively. Daily standups can surface potential threats and opportunities; reports of blockers can become threats if they keep delaying progress; reports of breakthroughs may point to opportunities worth leveraging. Frequent demos of increments, interim designs, or proof-of-concepts also surface both.
| Awareness of the environment (technical/social/political/market/economic) | The team incorporates environmental considerations when evaluating uncertainty, risks, and responses. |
| Proactively exploring and responding to uncertainty | Risk responses align with the prioritization of constraints (budget/schedule/performance). |
| Awareness of interdependence of variables | Actions addressing complexity, ambiguity, and volatility are appropriate. |
| Capacity to anticipate threats/opportunities | Systems for identifying, capturing, responding to risk are appropriately robust. |
| Little/no negative impact from unforeseen events | Scheduled delivery dates are met; budget performance within threshold. |
| Opportunities realized | Teams use established mechanisms to identify and leverage opportunities. |
| Reserves used effectively | Teams proactively prevent threats, limiting reserve use. |
| # | Domain | Addresses | Signature term / idea |
|---|---|---|---|
| 1 | Stakeholders | Activities/functions associated with stakeholders | Stakeholder analysis; the 3-ring map |
| 2 | Team | People producing deliverables | Management vs. leadership; centralized vs. distributed |
| 3 | Development Approach & Life Cycle | Development approach, cadence, life cycle phases | Predictive / hybrid / adaptive |
| 4 | Planning | Initial/ongoing/evolving org & coordination | Accuracy vs. precision; dependencies |
| 5 | Project Work | Processes, physical resources, learning | RFI / RFP / RFQ; explicit vs. tacit knowledge |
| 6 | Delivery | Scope & quality the project was chartered to achieve | Definition of Done; Cost of Quality |
| 7 | Measurement | Assessing performance, taking action | Leading vs. lagging indicators; SMART |
| 8 | Uncertainty | Risk and uncertainty | Risk/Ambiguity/Complexity/Volatility; AETMA / EESEA |
Eight domains that sound similar in places — here's where the exam traps live.
Self-check before the Practice Lab. No reload, no scrolling away.
Exam-style scenario questions grounded directly in the slide content.