Pooyan: Project Delivery Methods

2026-01-19T15:32:45Z

Project Delivery Methods

New page

'''<big>This page is under construction ...</big>'''
''See also [[Project_Definition|Project Definition]], [[Project_Development|Project Development]], [[Project_Execution|Project Execution]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]].''
''See also [[Project_stakeholder|Project stakeholder]], [[Management_control|Management control]], [[Civil_Engineering_Projects|Civil Engineering Projects]] ...''

== Basic considerations ==
A ''project delivery method'' is the integrated contracting and organizational approach used to finance, design, procure, construct, and transition a project to acceptance (and sometimes operations).

Delivery methods matter in RiskWiki because they:
* allocate uncertainty and risk among stakeholders (through contracts),
* determine who controls which artifacts (requirements, designs, specifications),
* affect the feasibility boundary between conceptual and detailed design,
* shape interfaces (and therefore interface risk),
* govern how change is priced, approved, and implemented.

[[#top|Top of current page]]

== Semantic, Epistemic and Logical frameworks ==
''(Under construction)''

=== Semantic framework ===
Common semantic confusion:
* delivery method vs procurement method vs contracting strategy (related but not identical),
* treating “design-build” as a single uniform model (it contains many variants),
* confusing commercial scope splits with legal responsibility (e.g., engineer-of-record obligations).

Working distinction:
* Delivery method is the combined set of roles, contract structures, and decision rights used to deliver the facility.

=== Epistemic framework ===
Delivery methods shift which party is responsible for retiring which uncertainties (e.g., investigations, interface definition, constructability, means-and-methods, performance verification).
This reshapes:
* the project’s risk profile,
* the timing of risk retirement,
* and the governance controls needed.

=== Logical framework ===
A delivery method is a structured allocation of:
* responsibilities,
* authority,
* interfaces,
* and risk-bearing capacity
among stakeholders.

Contracts are a key mechanism for memorializing that allocation.

[[#top|Top of current page]]

== Common delivery methods (working list) ==
(Under construction.)

Typical civil-engineering delivery methods include:
* Design–Bid–Build (DBB)
* Design–Build (DB)
* Construction Manager at Risk (CMAR)
* Construction Manager / General Contractor (CM/GC)
* Engineering, Procurement, Construction (EPC) (more common in industrial domains)
* Public–Private Partnership (P3 / PPP) (many variants)

[[#top|Top of current page]]

== Delivery methods and the conceptual vs detailed design split ==
In many delivery environments, design responsibility is split into two broad components:
* '''Conceptual design''' (often owner/owner’s agent): expresses requirements and a solution hypothesis.
* '''Detailed design''' (often contractor’s design team): produces constructible details.

A practical demarcation concept:
* If a design element’s feasibility is not yet demonstrated (technical / regulatory / constructability), it should be treated as a development risk rather than an execution assumption.

[[#top|Top of current page]]

== Typical role allocation (illustrative) ==
''(Illustrative only; actual allocations vary by law, agency policy, and contract language.)''

{| class="wikitable"
! Delivery method !! Owner/sponsor role !! Designer role !! Builder role !! Typical risk/uncertainty implications
|-
| DBB || Defines requirements; holds design contracts || Designs for owner || Builds to completed design || Owner retains more design integration risk; contractor retains means/methods; interfaces often at contract boundaries
|-
| DB || Defines performance/requirements; reviews compliance || Designer is often under DB entity || DB entity integrates design + build || Integration shifts toward DB entity; owner retains requirement clarity risk; feasibility depends on quality of conceptual definition
|-
| CMAR || Defines requirements; holds design contract; CM provides precon services || Designs for owner || CM holds trade contracts and cost/schedule commitments || Early constructability input can reduce development uncertainty; change and interface management becomes central
|-
| CM/GC || Defines requirements; holds design contract; negotiates with CM/GC || Designs for owner with CM/GC input || CM/GC constructs (often with negotiated pricing) || Enables earlier feasibility testing and risk retirement; requires disciplined governance to avoid scope drift
|-
| P3 / PPP (variant) || Procures outcomes; governs performance || Often under private consortium || Often under private consortium || Transfers some long-term performance/financing risk; requires strong definition of acceptance and operations requirements
|}

[[#top|Top of current page]]

== Interfaces to uncertainty and risk management ==
Delivery methods influence:
* what counts as a “requirement risk” vs “design risk” vs “construction risk”,
* who funds which risks (contingency vs allowances vs management reserve),
* who owns interface uncertainty (package boundaries),
* how claims/disputes arise and are resolved.

A useful analytical exercise:
* pick one contract package with difficult interfaces and map (1) requirements, (2) design artifacts, (3) procurement packages, (4) construction tasks, and (5) startup/acceptance steps—then identify where feasibility can break.

[[#top|Top of current page]]

== Working definition of the term ==
Project delivery method
:A project delivery method is the integrated set of contracting structures, organizational roles, procurement approach, and decision rights used to define, develop, execute, and achieve acceptance of a project, including the allocation of uncertainty and risk among stakeholders.

[[#top|Top of current page]]

== Limitations of the definition ==
(Under construction.)
* Terminology and legal meanings vary across jurisdictions and agencies.
* “Delivery method” is frequently used as shorthand for only the procurement method; RiskWiki uses a broader meaning including governance and role allocation.

== Beneficial Outcomes ==
(Under construction.)
Clear delivery-method selection and documentation improves:
* alignment of responsibilities with capability,
* transparency of risk allocation,
* feasibility of schedule and cost commitments,
* interface control and claims avoidance.

== See also ==
* [[Project_Definition|Project Definition]]
* [[Project_Development|Project Development]]
* [[Project_Execution|Project Execution]]
* [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]]
* [[Project_stakeholder|Project stakeholder]]
* [[Management_control|Management control]]

== Learning Outcomes ==
(Under construction.)
The reader should be able to:
* describe how delivery methods allocate uncertainty among parties,
* explain conceptual vs detailed design as a delivery-method boundary,
* identify delivery-method-driven interface risks.

== Notes ==
(Under construction.)

== References ==
(Under construction.)

[[Category:Definition]]

Project Delivery Methods - Revision history

Pooyan: Project Delivery Methods