Value Delivery System

A System for Value Delivery (PM Standard, Section 2)

PMBOK 8 Standard Section 2 describes the system in which projects deliver value: how value is created, what environmental factors influence projects, how product management relates to project management, what functions support project delivery, and what roles execute them.

The section is built from five subsections:

• 2.1 Creating Value — how projects produce or enhance value within an organization’s value delivery system.
• 2.2 Project Environment — internal and external factors that influence project value delivery.
• 2.3 Product Management Considerations — how portfolios, programs, projects, and products relate.
• 2.4 Functions Associated With Projects — the work functions that drive delivery.
• 2.5 Project Management Roles — the roles that perform those functions.

---

2.1 Creating Value

Organizations create value for stakeholders. The expected value of any project investment — financial or nonfinancial — should meet or exceed the target threshold. Value delivery today also extends to societal impact and sustainability, not only organizational objectives.

Business value is a net quantifiable benefit, tangible or intangible, that contributes to the organization’s health and well-being during the project, at the end, or in the long term:

Tangible	Intangible
Monetary assets	Goodwill
Productivity	Brand recognition and trademarks
Profitability	Public benefit
Stockholder equity	Acquired knowledge
Market share	Infrastructure capabilities
Compliance	Reputation
Utility	Employee well-being
Environmental improvements	Environmental awareness

Projects meet or exceed expected value thresholds when they:

• Create a new product, service, or result that meets customer or end-user needs
• Deliver within the performance baseline when that represents a high-value outcome
• Contribute to community development, environmental sustainability, ethical responsibility
• Improve efficiency, productivity, effectiveness, responsiveness, or employee well-being
• Enable an organizational transition to its desired future state
• Sustain benefits enabled by previous programs, projects, or business operations

2.1.1 Value Delivery Components

Portfolios, programs, projects, products, and operations all generate value — individually or collectively. Together they form an integrated system to maximize and sustain value delivery while ensuring alignment with strategy (Figure 2-2).

• Portfolio management is the central framework linking strategy to execution; optimizes resource utilization across programs, projects, products, and operations.
• Operations support and influence PPP, plus essential business functions (payroll, supply chain).
• Components interact dynamically with each other and shape strategic outcomes.

The value delivery system sits inside the organization’s internal environment (policies, procedures, methodologies, frameworks, governance) which itself sits within the larger external environment (economy, competition, legislation).

How value flows through the system: components create deliverables → which produce outcomes → which create benefits (and possibly disbenefits — negative consequences) → which create value. A value delivery system works most effectively when information and feedback are shared consistently across all components, keeping the system aligned with strategy and attuned to the environment (Figure 2-3).

2.1.2 Assessing Project Success

PMBOK 8 measures success on two dimensions that must both be evaluated:

1. Success of project outcomes — effectiveness in realizing intended value. May be realized during the project, immediately after, or in the short/long term. Includes strategic objectives (sales targets, ROI, new customers, first-to-market, technology improvements, regulatory compliance, sustainability goals).
2. Success of project management processes — efficiency of execution, measured by adherence to constraints (cost, scope, time, quality). Delivers on time, on budget, to required standards, with effective resource use and stakeholder expectations met.

Both matter. PM process success ensures efficient execution; outcome success delivers the target business value — whenever that value is realized.

Sydney Opera House (PMBOK 8 example) — initial budget AUS$7M,planned4years.Actual:AUS$102M, 14 years. PM-process failure, but a UNESCO World Heritage site visited by 10.9M annually — outcome success that exceeded expectations many times over. The successful outcome would have been even stronger had scope been delivered earlier at lower cost.

Montreal Highway 15 overpass (2016, counter-example) — well-managed CA$11M construction. But it did not align with the redevelopment plans for the adjacent Champlain Bridge. Demolished a year after completion. PM-process success without outcome success.

---

2.2 Project Environment

Projects operate within internal and external organizational environments. Two major categories of influence:

• Enterprise Environmental Factors (EEFs) — conditions not directly influenced by the project team that impact, constrain, or direct the project. Inputs to many planning processes. Can enhance or constrain options; positive or negative.
• Organizational Process Assets (OPAs) — internal plans, processes, documents, templates, and knowledge repositories used by the performing organization.

2.2.1 EEFs

Internal EEFs:

• Organizational culture, structure, governance (vision, mission, values, leadership styles, hierarchy, ethics, codes of conduct)
• Geographic distribution of facilities and resources
• Infrastructure (existing facilities, equipment, IT hardware, capacity)
• Information technology systems (task/cost/schedule tools, configuration management, work authorization)
• Resource availability (contracting/purchasing constraints, staffing levels, collaboration agreements)
• Employee capability (expertise, skills, competencies, specialized knowledge)
• Financial capability (external funding options, additional financial resources)

External EEFs:

• Marketplace conditions (competitors, customer behavior, market share, brand)
• Social and cultural influences (political climate, codes of conduct, ethics, perceptions)
• Legal restrictions (country/local laws, data protection, business conduct, employment, procurement)
• Academic research (industry studies, benchmarking, empirical data, emerging trends)
• Government or industry standards (regulatory standards for products, environment, safety, quality)
• Financial considerations (FX rates, interest rates, inflation, tariffs, taxes, geography)
• Physical environmental elements (weather, geopolitics)
• Emerging technologies and innovations (AI, automation, blockchain, IoT)
• Public health and safety regulations (health protocols, travel restrictions, public safety mandates)

2.2.2 OPAs

OPAs are internal to the organization and may include any artifact, practice, or knowledge from the performing organizations. They include lessons learned and historical information. Often inputs to PM processes (completed schedules, risk data, earned value data). The project team may update OPAs throughout the project.

Two categories:

• Policies, processes, and procedures — typically not updated by the project; established by the PMO or another function outside the project. Examples: tailoring guidelines, product and project life cycles, templates (PM plans, registers, contracts, risk), preapproved supplier lists, change control procedures, traceability matrices, issue/defect management, resource control policies, work authorization processes, performance measurement guidelines, verification/validation processes, SLAs, project closure guidelines.
• Organizational knowledge repositories — updated throughout the project. Configuration management repositories; financial data; historical information and lessons learned; issue/defect data; metrics; project files from previous projects (scope, cost, schedules, baselines, calendars, risk/stakeholder registers).

2.2.3 Organizational Structures

PMBOK 8 (Table 2-1) lists structure types and their typical influence on projects:

Structure	PM Authority	PM Role	Resource Availability
Organic / simple	Low	Part-time, not designated	Low
Functional (centralized)	Low	Part-time	Low
Multidivisional	Low	Part-time	Low
Matrix — weak	Low	Part-time, not designated	Low
Matrix — balanced	Low to moderate	Part-time, embedded as a skill	Low to moderate
Matrix — strong	Moderate to high	Full-time, designated	Moderate to high
Project-oriented (composite, hybrid)	High to almost total	Full-time, designated	High to almost total
Virtual / network	Low to moderate	Full-time or part-time	Low to moderate
Hybrid	Mixed	Mixed	Mixed

No one-size-fits-all. The optimal structure depends on size, industry, geography, strategic objectives, and project complexity.

---

2.3 Product Management Considerations

Product management integrates people, data, processes, and business systems to create, develop, and maintain a product or service throughout its life cycle. The product life cycle is a series of phases representing the product’s evolution: introduction → growth → maturity → decline/retirement.

Project life cycles are not the same as product life cycles. A product can outlive many projects; a project can initiate work at any point in the product’s life cycle.

Five relationship patterns between portfolio/program/project/product management (Figure 2-5):

1. Program management within a product life cycle — related projects, subsidiary programs, and program activities support a long-running product.
2. Project management within a product life cycle — portfolio governance charters individual projects to perform enhancements, improvements, or other outcomes within an ongoing product business.
3. Product management within a portfolio — entire product life cycle is managed within a single portfolio’s boundaries, ensuring product investments align with strategy.
4. Product management within a program or project — product responsibilities are scoped as components or stand-alone projects, focused on requirements and scope.
5. Product management across programs and projects — a product spans multiple programs/projects, requiring coordination across them.

Supporting roles bridge the disciplines:

• Product owner — maintains and prioritizes the product backlog; ensures the development team focuses on delivering valuable features.
• Business analyst — gathers and documents requirements; ensures project scope and product functionality align with business needs.

---

2.4 Functions Associated With Projects

People drive project delivery by fulfilling essential functions. Functions can be performed by an individual, a team, or a combination of roles. PMBOK 8 frames seven non-exhaustive functions:

2.4.1 Provide oversight and coordination

Align efforts, remove obstacles, maintain focus. May include preliminary evaluation/analysis, executive consulting on objectives and performance, business analysis, tendering, contract negotiations, business case development, and follow-on benefits realization activities before formal closure. Typical roles: project managers (formally assigned), scrum masters (leading the team to perform activities themselves).

Coordination types:

• Centralized coordination — designated PM or similar role provides leadership and guidance (predictive projects).
• Decentralized coordination — team self-organizes and self-manages (agile projects).
• Hybrid/mixed coordination — centralized overall with self-organized portions of the work.

2.4.2 Solicit and manage feedback

Gather perspectives, insights, direction, and expectations from individuals involved. Greater need in adaptive/hybrid because elements are explored within increments under ambiguity. Customer, end user, or product owner engages for periodic reviews. A customer representative may participate with the team. Feedback can be collected in person or virtually, analog or digital.

2.4.3 Facilitate and support

Tailored oversight, coordination, and encouragement. Build consensus, resolve conflicts, support decisions, coordinate meetings, support people through change, address obstacles. Includes evaluating performance and providing feedback to help people learn, adapt, improve. Roles: PMs, scrum masters, team leads, business analysts, change management specialists.

2.4.4 Perform work

Provide knowledge, skills, and experience to deliver products and realize outcomes. Full-time or part-time, colocated or virtual. May harness automation and AI to streamline execution, reduce error, enhance productivity.

2.4.5 Apply expertise

Contribute specialized knowledge, vision, and skills in a subject area. Experts identify uncertainties and blind spots, evaluate progress and success. Internal team members or external specialists. Accelerates progress and helps achieve intended outcomes efficiently.

2.4.6 Provide organizational direction and insight

Guide and clarify the project/product direction. Prioritize requirements/scope based on value, dependencies, technical/operational risks. Engage stakeholders, customers, and teams to collaboratively define direction. In adaptive/hybrid, direction comes from regular review cycles and feedback loops; in predictive, from milestone checkpoints. Typical roles: portfolio managers, project sponsors, product owners.

2.4.7 Provide resources

Secure and provide funding, physical resources, personnel, and authority. Portfolio managers and project sponsors secure resources and champion the project at the organizational level. Functional and resource managers allocate the right personnel, equipment, and expertise; address resource gaps throughout the life cycle.

---

2.5 Project Management Roles

Functions (2.4) may be performed by various individuals or teams. Key roles:

2.5.1 Project Management Team

May be a single PM or a multi-person team. Essential for guiding the assigned team to achieve goals and deliver value while considering flexibility, adaptability, and tailoring. Typically involved from initiation through closing — sometimes in evaluation/feasibility before initiation, and post-project benefit analysis.

Title variation. In some organizations, “project manager” may not be the title — “project leader,” “project lead,” “product owner,” “product manager,” “scrum master,” “agile coach,” “agile delivery manager,” “team lead” may share PM responsibilities. The essence of project management lies in the characteristics of the project itself rather than the title of the individual.

Competencies (Figure 2-7):

• Social responsibilities — give back to the profession and society; respect cultural/social norms; strive for self-development.
• Power skills — people skills (adaptability, EI); critical thinking; team motivation; negotiation; conflict resolution.
• Business acumen — strategic thinking; align project with organizational context; project selection criteria; industry knowledge; financial analysis.
• Ways of working — apply standards, methodologies, frameworks; choose appropriate approach (predictive/adaptive/hybrid); brainstorming techniques; change management techniques.
• Results — actual work and execution; problem-solving (e.g., root cause analysis); deal with enterprise politics (influence, negotiation, power).

Situational leadership is especially relevant — PM teams must adjust leadership style to the team’s needs, time sensitivity, and project complexity. Shift from directive in critical phases to supportive when team autonomy is beneficial.

Technology impact. Tools support scheduling, resource allocation, repetitive task automation, data visualization, brainstorming, real-time communication. AI/ML offer predictive insights, risk identification, schedule optimization. Cloud computing enables global team collaboration. The PM team should ensure data accuracy and output neutrality (avoid bias) and align with the IT department on cybersecurity.

2.5.2 Sponsor, Customer, or Product Owner

Provide decision leadership outside the PM team’s authority. Communicate vision/goals/expectations, keep the project aligned with business objectives, facilitate executive decisions, help secure resources, advocate for the team, address issues or remove obstacles beyond the PM team’s authority. Critical for sustainability and ESG goals. Their presence and degree of involvement raises the likelihood of project success; absence adversely impacts the project.

Further detail in the Stakeholders performance domain (Guide § 2.5).

2.5.3 Project Team

The set of individuals performing the project’s work and directly responsible for achieving objectives. Size, composition, and skill level depend on type, scale, complexity, and organizational maturity. May use decentralized coordination (self-organize and self-manage — agile), centralized coordination (under PM leadership — predictive), or a hybrid governance model. Regardless of coordination style, supportive leadership and continuous engagement are key.

Further detail in the Resources performance domain (Guide § 2.6).

2.5.4 End Users and Other Key Stakeholders

PM teams should engage in continuous dialogue with end users, influencers, customers, regulators, and other key stakeholders. Goals: capture and integrate feedback throughout the life cycle, ensure mutual alignment, build credibility. Includes iterative verification and validation. Prioritizing end-user satisfaction minimizes the risk of delivering something that doesn’t meet expected utility — the integration of end-user feedback refines the outcome and confirms relevance.

---

Related

• Introduction — § 1 foundations
• Project Life Cycles — § 4
• Organizational Project Management (OPM)
• Business Case
• Benefits Management
• Governance Domain
• Stakeholders Domain
• Focus on Value

Exam angle

• Two-dimensional success. Wrong = judge success only by on-time/on-budget. Right = also evaluate whether intended outcomes and benefits were realized. The Sydney Opera House example anchors this — process failure + outcome success.
• Counter-example matters too. Montreal Highway 15: well-managed construction (process success) but no outcome success — wrong scope for the broader context. Process success without outcome success is still failure.
• Disbenefits exist. Outcomes can also create negative consequences. Answers that assume “outcomes = benefits only” miss this.
• Operations are not separate from value delivery. Operations support and interact with PPP within the same system. Wrong answers silo operations from projects.
• EEFs ≠ OPAs. EEFs are conditions the project team doesn’t directly control (some internal, some external). OPAs are internal assets (templates, processes, knowledge repositories) the team often consumes and can update. Mixing them up is a common trap.
• Product life cycle ≠ project life cycle. A product can outlive multiple projects. A project initiates work at points in the product’s life cycle. Wrong answers conflate the two.
• Title ≠ function. PM responsibilities can be carried out by a scrum master, product owner, project lead, or team. Wrong answers fixate on the formal title.
• Sponsor presence matters. Sponsors are not optional figureheads — their active engagement raises success likelihood; absence drags projects down. Wrong answers reduce the sponsor to a name on the charter.
• End-user engagement is continuous. Verification and validation are iterative throughout the life cycle, not a one-shot acceptance test at the end.