Project Delivery Methods
This page is under construction ... See also Project Definition, Project Development, Project Execution, Project Life Cycle and Phase Models. See also Project stakeholder, Management control, 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.
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.
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)
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.
Typical role allocation (illustrative)
(Illustrative only; actual allocations vary by law, agency policy, and contract language.)
| 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 |
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.
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.
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 Development
- Project Execution
- Project Life Cycle and Phase Models
- Project stakeholder
- 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.)