All of Chapter 1 on one page: Part 1 introduces the field, PMBOK and the 12 principles, Part 1.2 walks the 8 performance domains, and Part 1.3 covers tailoring and the models, methods and artifacts you tailor with. Ideas that appear in more than one part are written out once, with "Also in" links to the other places they show up.
What project management is, where it came from, who does it, PMBOK, the System for Value Delivery and the 12 principles.
1. The application of knowledge, skills, tools, and
techniques to project activities to meet project requirements.
2. Project management refers to guiding the project work to
deliver the intended outcomes. Project teams can achieve the
outcomes using a broad range of approaches (e.g., predictive,
hybrid, and adaptive).
People PMI projects employers will need in project-management-oriented roles by 2027.
New PM employees needed each year to meet global talent demand by 2030 (PMI 2021 Talent Gap report).
Wasted per every $1 billion spent on projects, per PMI's Pulse of the Profession® report.
Projected size of Saudi Arabia's AI market by 2030 under the Smart Government Strategy — ~12.4% of GDP.
Saudi Arabia's 2025 government tech spending (SR93B) — the highest in the world, 21.7% of national spending.
Top skills employers want in new grads — team-work, problem-solving, verbal communication — all core PM skills.
Also in Part 1.2 · Development Approach domain · Part 1.3 · choosing the initial approach
A profession growing "at a very rapid pace" — understanding where it came from explains why PMI, certification, and PMOs exist today.
Some argue that building the Egyptian pyramids was a project, as was building the Great Wall of China — massive, coordinated, goal-directed endeavors, even without the word "project management" yet.
Led by Dr. Oppenheimer: a three-year, $2 billion (1946 dollars) project. It had a separate project manager and technical manager — an early split between managing the project and managing the technical work, which is still a live distinction today.
As the number and complexity of projects grew, organizations began forming Project Management Offices (PMOs) — organizational units responsible for coordinating the project management function across the organization.
Several global dynamics are forcing organizations to rethink their practices: talent development for project/program managers is a top concern, basic PM techniques are now core competencies, organizations want more agile approaches, and benefits realization is a key success metric.
The Project Management Institute (PMI) is the leading organization advancing the PM profession. PMI provides certification as a Project Management Professional (PMP®), and the number of people earning PMP® certification is increasing quickly (active holders roughly doubled from ~510K in 2012 to a peak above 1.25M around 2021–2022).
Ethics, loosely defined, is a set of principles that guide decision making based on personal values of "right" and "wrong." Project managers often face ethical dilemmas. To earn PMP® certification, applicants must agree to PMI's Code of Ethics and Professional Conduct — and several PMP® exam questions relate to professional responsibility, including ethics.
Project managers are mainly responsible for all issues related to the software project; issues vary by scale, but the common ones are: Schedule, Budget, Quality, Delivery of products, and Locking in resources. In practice, most of a PM's time is consumed chasing and collecting the status of project tasks.
Job descriptions vary, but most include planning, scheduling, coordinating, and working with people to achieve project goals. 97% of successful projects were led by experienced project managers, who can often help influence success factors.
Skills PMs needBe comfortable with change · Understand the organizations they work in and with · Be able to lead teams to accomplish project goals.
People skills · Leadership · Listening · Integrity/ethical behavior/consistency · Building trust · Verbal communication · Building teams · Conflict resolution/management · Critical thinking/problem solving · Balancing priorities · Negotiating · Influencing the organization · Mentoring · Process and technical expertise.
Financial, physical, and human resources.
Structured engagement with stakeholders.
Lower costs, improved productivity.
Increased reliability, higher profit margins.
Positive impact on meeting strategic goals.
Less stress, fewer overworked personnel.
The reference standard the rest of this course — and this chapter's vocabulary — is built on.
The Standard for Project Management provides a basis for understanding project management and how it enables intended outcomes. It applies regardless of industry, location, size, or delivery approach (predictive, hybrid, or adaptive). It describes the system within which projects operate — including governance, possible functions, the project environment, and the relationship between project management and product management.
Stakeholders · Team · Development Approach & Life Cycle · Planning · Project Work · Delivery · Measurement · Uncertainty.
The domains are written out once, in full, in Part 1.2 (definitions, memory hook, outcome checks), so they are not repeated here.
An end result or consequence of a process or project. Broader than outputs/artifacts — focuses on the benefits and value the project was undertaken to deliver.
Projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives. Example: a company's R&D programs, marketing campaigns, or infrastructure upgrades.
Related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually. Example: a company-wide digital transformation initiative.
A temporary endeavor undertaken to create a unique product, service, or result. "Temporary" means a beginning and an end to the work or a phase of it. Projects can stand alone or be part of a program or portfolio.
An artifact that is produced, is quantifiable, and can be either an end item in itself or a component item.
The person assigned by the performing organization to lead the project team, responsible for achieving the project objectives — facilitating team work and managing processes to deliver intended outcomes.
A set of individuals performing the work of the project to achieve its objectives.
The members of the project team who are directly involved in project management activities (a subset of the full project team).
A collection of strategic business activities aimed at building, sustaining, and/or advancing an organization. Portfolios, programs, projects, products, and operations can all be part of it.
The worth, importance, or usefulness of something. Different stakeholders perceive it differently: customers via features/functions, organizations via business value (benefits minus cost), and society via community or environmental contribution.
Provides a context for value delivery, governance, project functions, the project environment, and product management.
Creating a new product, service, or result that meets customer/end-user needs.
Creating positive social or environmental contributions.
Improving efficiency, productivity, effectiveness, or responsiveness.
Enabling changes needed for organizational transition to a desired future state.
Sustaining benefits enabled by previous programs, projects, or operations.
Portfolios, programs, projects, products, and operations can be used individually and collectively to create value. Working together, they compose a system for delivering value aligned with the organization's strategy. Any project or program could include products, and operations can directly support/influence portfolios, programs, and projects (as well as functions like payroll, supply chain, finance, HR, customer service).
A value delivery system works best when information and feedback are shared consistently among all components, keeping the system aligned with strategy and in harmony with the environment.
Senior Leadership shares strategy with Portfolios → Portfolios share desired outcomes, benefits, and value with Programs & Projects → Programs & Projects pass deliverables + support/maintenance info to Operations.
Operations feed back updates, fixes, and adjustments to Programs & Projects → Programs & Projects report performance information and progress to Portfolios → Portfolios report portfolio performance to Senior Leadership. Outcomes/benefits/value performance analysis flows the whole loop back to Senior Leadership.
Works alongside the value delivery system to enable smooth workflows, manage issues, and support decision making. A governance framework can include oversight, control, value assessment, integration among components, and decision-making capabilities — plus an integrated structure for evaluating changes, issues, and risks. Project governance is aligned with program and/or organizational governance, and includes defining the authority to approve changes.
People drive project delivery by executing functions — fulfilled by one person, a group, or combined into defined roles. Coordination can be decentralized (teams self-organize/self-manage) or centralized (a designated project manager leads) — and centralized projects can still include self-organized sub-teams for portions of the work.
| # | Function | Example |
|---|---|---|
| 1 | Provide oversight and coordination | Monitoring progress and performance |
| 2 | Present objectives and feedback | Defining success criteria and desired outcomes |
| 3 | Facilitate and support | Hosting meetings, workshops, stand-ups |
| 4 | Perform work and contribute insights | Completing assigned deliverables |
| 5 | Apply expertise | Advising on technical/domain-specific matters |
| 6 | Provide business direction and insight | Identifying market trends or customer needs |
| 7 | Provide resources and direction | Allocating budget, personnel, infrastructure |
| 8 | Maintain governance | Enforcing regulatory and internal standards |
Factors internal to the organization, arising from the org itself, a portfolio, a program, another project, or a combination. Includes artifacts, practices, and internal knowledge — e.g. process assets, governance documentation, data assets, knowledge assets, infrastructure, information technology software.
Factors external to the organization can enhance, constrain, or have a neutral influence on project outcomes — e.g. marketplace conditions, social/cultural influences, regulatory environment, commercial databases, academic research, industry standards, financial considerations, physical environment.
Also in Part 1.3 · organization and environment factors
Portfolio, program, and product management are beyond the scope of the PMI standard and this course — but understanding each discipline and the relationships between them provides useful context for projects whose deliverables are products. Product management involves integrating people, data, processes, and business systems to create, maintain, and develop a product or service throughout its product life cycle.
The product life cycleA series of phases representing a product's evolution — from introduction, through growth and maturity, to retirement. Product management may initiate programs or projects at any point in the life cycle to create or enhance specific components, functions, or capabilities. The initial product may begin as a project's deliverable, and later programs/projects can add value throughout the cycle (e.g. Project 1: initial creation → Projects 2–3: more features/additions → Projects 4–6: revisions → Project 7: retirement — all under Portfolio Governance).
Principles are foundational guidelines for strategy, decision making, and problem solving — but unlike laws or rules, PM principles are not prescriptive. They guide behavior; they don't dictate a single "correct" method. They're internally consistent (no principle contradicts another), though practical dilemmas can still arise, and they can overlap with general management principles.
Be a diligent, respectful, and caring steward.
Create a collaborative project team environment.
Also in Part 1.2 · Team domain
Effectively engage with stakeholders.
Also in Part 1.2 · Stakeholder domain
Focus on value.
Also in Part 1 · System for Value Delivery · Part 1.2 · Delivery domain
Recognize, evaluate, and respond to system interactions.
Demonstrate leadership behaviors.
Tailor based on context.
Also in Part 1.3 · Tailoring
Build quality into processes and deliverables.
Navigate complexity.
Optimize risk responses.
Also in Part 1.2 · Uncertainty domain (threats, opportunities)
Embrace adaptability and resiliency.
Enable change to achieve the envisioned future state.
The 8 domains as one system, each with definitions and an outcome → check table.
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.
Also in Part 1 · the 12 principles that drive every domain
"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.
Also in Part 1 · principles 2, 6 and 11
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).
Also in Part 1.3 · step 1 of tailoring selects this approach
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. |
Also in Part 1 · principles 9 (Complexity) and 10 (Risk)
Fitting the approach to the work, and the toolkit you tailor with.
Tailoring is the deliberate adaptation of the development approach, governance, processes, methods, and artifacts to a project’s context. The goal is “just enough” discipline to deliver value and manage risk—not maximum or minimum process.
Novelty, complexity, safety, architecture, quality attributes, physical/software coupling.
Size, duration, budget, dependencies, uncertainty, delivery cadence, procurement.
Culture, governance, policies, process assets, distributed structure, maturity.
Regulation, market volatility, technology change, sustainability, geopolitical constraints.
Skills, team size, location, autonomy, stakeholder access, trust and experience.
Also in Part 1 · principle 7, Tailoring · Part 1 · internal vs external environment
Record consequential tailoring decisions, rationale, constraints, owner, and review point. This creates transparency and prevents “we have always done it this way” from becoming the process.
Also in Part 1.2 · predictive, hybrid, adaptive in detail
A simplified representation that explains behavior or relationships: situational leadership, communication models, motivation models, conflict models, complexity frameworks, change models.
A means for accomplishing work: estimating, workshops, interviews, retrospectives, earned value analysis, root-cause analysis, prioritization, testing, planning poker.
A template, document, deliverable, or visual: charter, backlog, roadmap, risk register, schedule, business case, requirements, burn chart, dashboard, lessons learned.
Model: Cynefin/complexity. Methods: prototypes and experiments. Artifacts: hypotheses, experiment results, ordered backlog.
Model: stage-gate. Methods: traceability and formal reviews. Artifacts: approvals, test evidence, requirements matrix.
Model: adaptive lifecycle. Methods: asynchronous refinement and virtual reviews. Artifacts: shared backlog, decision log, definition of done.
Does this activity or artifact improve a decision, reduce risk, enable delivery, or satisfy a real obligation?
Is the evidence detailed enough for its audience and consequence—without avoidable duplication?
Do roles, cadence, governance, lifecycle, methods, and tools reinforce one another?
How quickly does the approach expose incorrect assumptions, defects, and changing needs?
Can the team actually use it? A theoretically perfect process that people bypass is not effective.
Are mandatory policy, contractual, regulatory, safety, security, and audit needs demonstrably met?
Review at retrospectives, phase gates, releases, major risk events, team changes, and shifts in external conditions. Use outcomes—cycle time, defects, rework, value, risk exposure—not document count.
The breakdown above explains tailoring in practice; these are the exact lists from the Chapter 1.3 deck.
| Slide topic | What to remember |
|---|---|
| Definition | Deliberate adaptation of the PM approach, governance and processes to the environment and the work at hand. |
| Why tailor (3) | More commitment from team members who helped tailor · customer-oriented focus · more efficient use of resources. |
| What to tailor (5) | Life cycle and development approach · processes (added, modified, removed, blended, aligned) · engagement (people, empowerment, integration) · tools · methods and artifacts. |
| Tailoring process (4) | Select initial approach → tailor for the organization → tailor for the project → implement ongoing improvement. |
| Tailoring for the project | Product/deliverable: compliance/criticality, type, industry market, technology, time frame, stability of requirements, security. Project team: size, geography, organizational distribution, experience, access to customer. Culture: buy-in, trust, empowerment, organizational culture. |
| Situation → suggestion | Poor quality → feedback loops and QA. Team unsure → guidance, training, verification. Approval delays → fewer approvers up to value thresholds. Too much WIP/scrap → value stream mapping, kanban. Disengaged stakeholders → deeper engagement. No visibility → collect and discuss measures. Surprise issues → root causes. |
| Model families | Situational leadership (Situational Leadership II, OSCAR) · communication (cross-cultural, channel effectiveness, gulf of execution and evaluation) · motivational (hygiene vs motivators, intrinsic vs extrinsic, hierarchy of needs, Theory X/Y/Z) · change (ADKAR, 8-step process, Satir, Transition) · complexity (Cynefin, Stacey matrix) · team development (Tuckman, Drexler/Sibbet) · other (conflict, negotiation, planning, process groups, Salience). |
| Method categories | Data gathering and analysis · estimating · meetings and events · other. |
| Artifact categories | Strategy · logs and registers · plans · hierarchy charts · baselines · visual data · reports · agreements and contracts · other. |
| Avoid anything that | Duplicates effort · isn't useful · gives incorrect or misleading information · caters to individual over team needs. |
Everything from the three parts grouped by type, each tagged with the part it came from.
These are the specific mix-ups this chapter sets up — drill these before anything else.
Eight domains that sound similar in places — here's where the exam traps live.
A prior project is evidence, not a universal recipe. Reassess its assumptions.
Combining fashionable practices without understanding interfaces creates friction.
“Agile” does not erase knowledge-transfer, compliance, architecture, or operating needs.
The initial approach is a hypothesis. Update it when results or context disagree.
| Term | One-line definition |
|---|---|
| Product | A quantifiable artifact produced — an end item or component. |
| Project | A temporary endeavor to create a unique product, service, or result. |
| Program | Related projects/programs managed together for benefits not available individually. |
| Portfolio | Projects, programs, subsidiary portfolios, and operations grouped for strategic objectives. |
| # | Principle | One-line gist |
|---|---|---|
| 1 | Stewardship | Act responsibly and ethically. |
| 2 | Team | Foster trust, respect, open communication. |
| 3 | Stakeholders | Involve stakeholders proactively. |
| 4 | Value | Prioritize outcomes that deliver value. |
| 5 | Systems Thinking | Understand interactions within/beyond the project. |
| 6 | Leadership | Lead with integrity, adaptability, empathy. |
| 7 | Tailoring | Adapt methods, tools, and approaches. |
| 8 | Quality | Embed quality from the start. |
| 9 | Complexity | Embrace uncertainty and complexity. |
| 10 | Risk | Identify, assess, and respond to risks. |
| 11 | Adaptability & Resiliency | Be flexible and ready to pivot. |
| 12 | Change | Support transformation and continuous improvement. |
| # | Domain |
|---|---|
| 1 | Stakeholders |
| 2 | Team |
| 3 | Development Approach and Life Cycle |
| 4 | Planning |
| 5 | Project Work |
| 6 | Delivery |
| 7 | Measurement |
| 8 | Uncertainty |
| # | 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 |
Quick self-check, separate from the Practice Lab below.
Self-check before the Practice Lab. No reload, no scrolling away.
Same shape of question this chapter's terminology gets tested with — grounded directly in the slide definitions.
Exam-style scenario questions grounded directly in the slide content.