Risk Engineering - User contributions [en]

User:Pooyan/Civil Engineering Project Risk Taxonomy

2026-08-10T19:01:58Z

Pooyan: Create version 0.10 review draft; proposed C01-C14 civil-infrastructure risk taxonomy

'''''Review draft — version 0.10, August 10, 2026. Keep in Draft/User space; not yet approved for publication.'''''



'''A civil engineering project risk taxonomy''' is a controlled vocabulary for identifying, organizing, comparing, and aggregating uncertainties that may affect the objectives of a civil-infrastructure project or program. The taxonomy presented here is designed for complex heavy-civil and transit work. It proposes fourteen control domains grouped into four clusters and supplements them with separate tags for uncertainty character, causal source, life-cycle stage, physical and contractual location, affected objective, and ownership.

The purpose is practical: a risk should be traceable from its source through the location or work affected, the party able to control it, the evidence that a response has been implemented, and the residual exposure retained by the project. The taxonomy is therefore more than a list of things that may go wrong, but less than a quantitative risk model.

:''This page complements [[Uncertainty and Risk in Civil Engineering Practice]], which examines scientific, legal, economic, policy, and engineering taxonomies of uncertainty. That article asks how uncertainty arises and how knowledge can fail. This page asks where project risk is managed in civil-infrastructure practice.''

==Purpose and scope==

A useful taxonomy should be sufficiently comprehensive to support risk identification, sufficiently stable to permit comparison over time, and sufficiently clear to permit aggregation across disciplines and contracts. It should not force every dimension of a risk into one hierarchy.

This taxonomy is intended to:

* provide a common language across owners, designers, construction managers, contractors, operators, oversight bodies, and funding agencies;
* reduce omissions during risk identification and stage-gate reviews;
* connect each risk with the professional process, control, and deliverable used to manage it;
* preserve traceability from program to reach, package, work breakdown structure (WBS), Standard Cost Category (SCC), estimate item, schedule activity, and contract provision;
* distinguish physical exposure from contractual allocation and financial bearing;
* support aggregation without creating duplicate “cost risk” and “schedule risk” records for the same underlying uncertainty; and
* provide structured inputs to qualitative assessment and quantitative risk analysis without predetermining either result.

The C01-C14 structure is a new 2026 working taxonomy informed by project experience and crosswalked to Federal Transit Administration (FTA) practice. Its empirical reliability and classification consistency have not yet been validated. It is '''not''' an official FTA category system, a risk tier, an SCC structure, or a contingency formula.

The codes are direction-neutral: the same domains may be used for threats and opportunities. Direction is recorded separately so that an opportunity is not forced into a threat-only vocabulary.

===Development history and provenance===

The 2017 archived article [https://web.archive.org/web/20170227055023/http://riskengineering.org/Uncertainty_and_Risk_in_Civil_Engineering_Practice ''Uncertainty and Risk in Civil Engineering Practice''] compared scientific, legal, economic, policy/regulatory, and engineering approaches to uncertainty. It did not contain the C01-C14 structure. The present page is a 2026 applied extension developed for civil-infrastructure projects and should not be represented as recovered historical text.

{| class="wikitable"
! Version
! Source and status
! Material editorial changes
|-
| Working source (2026)
| Four clusters and C01-C14 labels presented in project risk-model working materials and an author review transcript. Not a published standard.
| The source used “safe service and governance” for C12-C14 and placed support-of-excavation wording with utilities/relocations.
|-
| Draft 0.9 (2026)
| First standalone article draft.
| Renamed the fourth cluster “Assurance and governance”; placed ground-driven support-of-excavation uncertainty in C02 and method/temporary-works uncertainty in C08; separated taxonomy from the computational model.
|-
| Draft 0.10 (2026)
| Review revision for subject-matter validation.
| Added category-boundary rules, separated uncertainty character from causal source, corrected the FTA phase/profile distinction, qualified controls and evidence, and added provenance and publication safeguards.
|}

==Taxonomy, register, RBS, WBS, and impact classification==

{| class="wikitable"
! Construct
! Function
! Important boundary
|-
| '''Risk taxonomy'''
| A reusable and version-controlled vocabulary of risk domains, definitions, inclusions, exclusions, aliases, and examples.
| It does not contain the project's actual risk events and does not assign contingency.
|-
| '''Risk breakdown structure (RBS)'''
| A hierarchical representation of sources or domains of risk. A taxonomy may be rendered as an RBS.
| It is not the scope or work breakdown structure.
|-
| '''Risk register'''
| The live set of identified project risks, including cause, uncertain event, effects, assessment, response, owner, evidence, and status.
| A register uses the taxonomy; it is not the taxonomy.
|-
| '''Work breakdown structure (WBS), asset breakdown, SCC, and schedule'''
| Descriptions of what will be designed, procured, built, tested, operated, paid for, or scheduled.
| They locate exposure but do not by themselves explain why uncertainty arises.
|-
| '''Impact classification'''
| The objectives affected, such as cost, time, safety, quality, environment, service, benefits, or community.
| Consequences are tags, not primary source categories. One risk can affect several objectives.
|}

==Risk, uncertainty, and deviation from good practice==

ISO 31000 frames risk around the effect of uncertainty on objectives and emphasizes integration of risk management into governance, strategy, planning, reporting, policy, values, and culture.<ref name="ISO31000">International Organization for Standardization, [https://www.iso.org/standard/65694.html ''ISO 31000:2018, Risk management — Guidelines'']. ISO reports that the 2018 edition remains the published edition; [https://www.iso.org/standard/88574.html a third edition] is under development as of 2026.</ref> This broad framing accommodates threats and opportunities and avoids reducing risk to a synonym for failure.

A deviation from context-appropriate good practice can be an important source of risk because it may weaken detection, analysis, decision-making, implementation, or assurance. It is not, however, a complete definition of risk. Ground variability, floods, market shocks, third-party decisions, and other sources of exposure may remain even when the project follows good practice.

The defensible proposition is therefore:

:'''Good practice does not eliminate risk. When it is appropriate, current, implemented, and effective, it may reduce avoidable epistemic uncertainty, reduce likelihood or consequences, or improve detection and preparedness. It supports making residual risk more visible, allocable, and governable.'''

For that reason, each category below is mapped to illustrative controls and evidence. An artifact supports a claim of implementation only when it is current, actually used, independently checked where appropriate, and shown to satisfy stated acceptance criteria. A plan or stated intention alone does not demonstrate that risk has been reduced.

==A faceted model==

Every risk should be coded across several independent dimensions. The fourteen categories answer only the control-domain question below.

{| class="wikitable"
! Facet
! Question answered
! Typical values
|-
| '''Uncertainty character'''
| Is the uncertainty primarily reducible through knowledge, inherent variability, or both?
| Epistemic; aleatory; mixed
|-
| '''Causal-source tag'''
| What kind of mechanism originates the uncertainty?
| Physical/natural; technical; organizational/behavioral; institutional/legal; economic/market; mixed
|-
| '''Control domain'''
| Which professional process has primary responsibility for managing the source?
| C01-C14
|-
| '''Local stage/maturity tag'''
| At what actual maturity is the affected unit or package?
| Project development; engineering; procurement; award; construction; testing; closeout
|-
| '''Physical and commercial location'''
| Where does the exposure reside?
| Program; reach; site; asset; package; WBS; SCC; estimate item; schedule activity; contract clause
|-
| '''Impact'''
| Which objectives may be affected?
| Cost; time; safety; quality; environment; community; service; performance; benefits; reputation
|-
| '''Control and allocation'''
| Who originates, controls, bears, monitors, and accepts the residual exposure?
| Owner; designer; contractor; supplier; operator; third party; shared
|}

This faceted structure preserves the insight of the earlier uncertainty taxonomies while producing a vocabulary suited to project controls. A single flat list cannot reliably represent cause, stage, location, consequence, and ownership at the same time.

==Four clusters and fourteen control domains==

The category codes are intended to remain stable through the life cycle after validation and adoption. Their relative importance changes with actual maturity, delivery strategy, context, and demonstrated controls.

===K01 — Definition and site===

{| class="wikitable sortable"
! Code
! Domain
! Includes and typical risk sources
! Illustrative controls and evidence (tailor to context)
|-
| C01
| '''Scope, requirements, and configuration'''
| Business need; operating concept; alternatives; functional and performance requirements; physical limits; exclusions; scope growth; inconsistent baselines; unapproved changes; benefits and acceptance criteria.
| Project-definition book; requirements register and traceability matrix; approved scope narrative and boundary maps; configuration/change-control procedure and authority; WBS/SCC/schedule scope bridge; assumptions, exclusions, and decision log.
|-
| C02
| '''Geotechnical and subsurface'''
| Ground and groundwater model; geological hazards; contamination; obstructions; mixed face; settlement; tunneling and excavation behavior; support of excavation; ground treatment; production and downtime; differing site conditions.
| Hazard-led investigation program; geotechnical data and factual reports; conceptual and updated ground model; Geotechnical Design Report and Geotechnical Baseline Report where appropriate; independent review; baselines by reach/package; instrumentation, monitoring, action levels, and response plans; explicit estimate/schedule links.
|-
| C03
| '''Utilities, SUE, and relocations'''
| Incomplete records; unknown or mislocated utilities; ownership; utility condition and criticality; conflicts; betterments; outages; approvals; relocation design; protection; cost sharing; enabling work.
| Utility-owner matrix; Subsurface Utility Engineering quality plan and verified mapping; conflict and criticality matrix; utility agreements; relocation/protection designs; outage and handback plans; advance-work schedule; cost, package, and schedule responsibility map.
|-
| C04
| '''Right-of-way, property, and access'''
| Permanent and temporary acquisition; easements; relocation and resettlement; condemnation; railroad possession; work zones; shafts and portals; staging, laydown, haul routes, and community/business access.
| Real estate acquisition and management plan; parcel and ownership map; appraisal/acquisition/relocation schedule; access and possession agreements; staging and logistics plan; lawful-right dates aligned to package need dates; engagement and grievance evidence where people or businesses are affected.
|-
| C05
| '''Environmental, permits, and commitments'''
| Environmental review; permits; environmental justice and distributional effects; cultural resources; contaminated media; noise and vibration; water; air; biodiversity; waste; mitigation commitments; climate and natural-hazard requirements.
| Environmental and social assessment; permit and approval matrix; environmental-commitment register; mitigation hierarchy and monitoring plan; climate-vulnerability/resilience assessment where material; condition-to-drawing/specification mapping; responsible owner and acceptance evidence.
|}

===K02 — Design and interfaces===

{| class="wikitable sortable"
! Code
! Domain
! Includes and typical risk sources
! Illustrative controls and evidence (tailor to context)
|-
| C06
| '''Third-party, railroad, and stakeholder interfaces'''
| Partner agencies; railroads; municipalities; utilities; authorities having jurisdiction; operator and emergency-service requirements; adjacent projects; community commitments; force-account work; approvals and agreements.
| Stakeholder and interface management plans; interface register; Interface Control Documents; responsibility and approval matrix; cross-package boundary drawings; signed agreements; integrated interface schedule; decision/escalation path; bilateral acceptance record.
|-
| C07
| '''Design completeness, coordination, and quality assurance'''
| Design criteria; surveys and data; discipline coordination; quantities; specifications; errors and omissions; design maturity; constructability inputs; value engineering; model fitness; novel technology or methods.
| Basis of design and controlled criteria; design management and QA/QC plans; maturity and quantity-confidence assessment; interdisciplinary and independent reviews; calculation checks; comment and decision logs; BIM/common-data-environment controls where used; reconciled basis of estimate.
|-
| C08
| '''Constructability, temporary works, and production'''
| Construction method; sequencing and staging; workfront availability; temporary support; groundwater control; maintenance of traffic/operations; spoil and material movements; site logistics; contractor methods; productivity and downtime.
| Constructability and value-engineering reviews; construction-method and staging studies; site-utilization plans; temporary- and enabling-works register; production and logistics ranges; early market/contractor input when permitted; owner performance criteria; implemented-action log.
|}

===K03 — Commercial and delivery===

{| class="wikitable sortable"
! Code
! Domain
! Includes and typical risk sources
! Illustrative controls and evidence (tailor to context)
|-
| C09
| '''Market, procurement, escalation, supply chain, and workforce'''
| Inflation and price volatility; bidder appetite; package scale; labor and specialist capacity; supplier concentration; long-lead materials/equipment; logistics and trade restrictions; bonding, insurance, domestic-content, and competition constraints.
| Market sounding; procurement and packaging strategy; year-of-expenditure escalation basis; bidder/supplier and workforce capacity assessment; long-lead and critical-supply register; prequalification where appropriate; independent price checks; price-shock triggers and fallback actions.
|-
| C10
| '''Delivery, contract, claims, and risk allocation'''
| Delivery-method fit; packaging; design responsibility; ambiguous scope; incentives; measurement/payment; insurance; bonds; differing site conditions; changes; notices; records; disputes; counterparty default; transferred, retained, shared, or uninsurable risk.
| Delivery-options and sponsor-capability analysis; package map; responsibility and risk-allocation matrices; commercial principles; equitable geotechnical and quantity mechanisms; change/notice/record procedures; claims-avoidance review; dispute ladder; accepted contract terms and retained-risk provision.
|-
| C11
| '''Schedule model, access integration, logistics, and controls'''
| Missing or defective schedule logic; calendars; resources; production assumptions; forecasting and progress data; integration of property, utility, permit, interface, access, operating-window, logistics, cash-flow, and handoff dependencies; critical and near-critical paths; float consumption.
| Integrated master schedule and basis; traceable calendars and production assumptions; package and external-interface logic; risk-to-activity links; quantitative schedule risk analysis when appropriate; integrated access/logistics plan; milestone ownership; forecast validation; mitigation and schedule-contingency decisions. Use the originating physical, commercial, or third-party category when the schedule is only a consequence.
|}

===K04 — Assurance and governance===

{| class="wikitable sortable"
! Code
! Domain
! Includes and typical risk sources
! Illustrative controls and evidence (tailor to context)
|-
| C12
| '''Safety, physical security, and quality'''
| Worker and public safety; fire/life safety; malicious physical acts; emergency preparedness; code and authority requirements; quality failure; inspection and test capability; nonconformance; safety/security certification.
| Hazard analysis and controlled hazard log; safety and security management/certification plans; threat and vulnerability assessment; QA/QC plans; independent assurance; inspection and test plans; nonconformance/corrective-action records; verified mitigation and formal acceptance.
|-
| C13
| '''Systems integration, digital/cyber, testing, and commissioning'''
| Civil-systems interfaces; requirements and configuration; software and legacy systems; BIM/data interoperability; IT and operational technology; cyber and vendor exposure; reliability, availability, maintainability, and safety; integration testing; training; operational readiness and handover.
| Systems engineering management plan; architecture and requirements baseline; Interface Control Documents; verification/validation matrix; RAM and cybersecurity/OT plans; data governance; integrated test and commissioning plan; safety certification; training, O&M, asset-information, and handover acceptance.
|-
| C14
| '''Governance, management, and funding'''
| Sponsor authority and capacity; decision rights; organizational interfaces; leadership continuity; staffing and competence; ethics and integrity; risk culture; estimate/schedule governance; funding and cash timing; contingency authority; independent oversight; information and AI governance.
| Project Management Plan and subplans; Risk and Contingency Management Plan; governance/RACI and delegated authorities; management-capacity and staffing plan; financial plan; risk/change/contingency committees and thresholds; independent review; controlled decision, source, model, and configuration records.
|}

==Primary-category decision rules==

Select the category that best represents the dominant source and the professional process with practical control. Do not choose a category merely because it contains a likely consequence. Use a secondary category only when a distinct coupled cause materially affects the response or ownership.

{| class="wikitable"
! Boundary
! Use the first category when…
! Use the second category when…
|-
| '''C02 / C08 / C10'''
| C02: the dominant uncertainty is ground, groundwater, contamination, obstruction, or subsurface behavior. C08: it is the selected construction method, temporary works, production, or workfront sequencing.
| C10: the dominant uncertainty is the contractual baseline, allocation, payment mechanism, notice, change, or claims treatment. A ground condition does not become C10 solely because it may produce a claim.
|-
| '''C03 / C06'''
| C03: the dominant uncertainty is utility identity, position, condition, conflict, outage, relocation, or protection.
| C06: the dominant uncertainty is a utility owner's agreement, approval, decision, force-account performance, or organizational interface.
|-
| '''C04 / C11'''
| C04: the dominant uncertainty is the legal or physical right to property, possession, easement, staging area, or access.
| C11: the right exists, but schedule logic, operating windows, sequencing, logistics integration, progress data, or forecasting is uncertain.
|-
| '''C05 / C06'''
| C05: the dominant uncertainty is a substantive environmental condition, permit requirement, mitigation commitment, or compliance condition.
| C06: the requirement is understood, but a third party's review, approval, agreement, or coordination is the uncertain mechanism.
|-
| '''C07 / C13'''
| C07: the dominant uncertainty concerns discipline design criteria, calculations, coordination, quantities, specifications, or design QA.
| C13: it concerns system architecture, cross-system requirements, software/data interfaces, cybersecurity/OT, verification, integrated testing, commissioning, or operational handover.
|-
| '''C09 / C10'''
| C09: the dominant source is the external market, competition, escalation, workforce, supplier capacity, long-lead supply, insurance, or bonding market.
| C10: it is the owner's delivery choice, procurement/contract structure, responsibility, risk allocation, commercial terms, change, or claims process.
|-
| '''C12 / C13'''
| C12: the dominant uncertainty is a safety, physical-security, quality, inspection, certification, or assurance outcome.
| C13: it is the integration, configuration, verification, test, or commissioning process. A safety consequence remains an impact tag unless safety assurance is itself the uncertain mechanism.
|-
| '''C11 / impact tags'''
| C11: the schedule model, control data, forecasting, or integration of access/logistics dependencies is itself the source.
| Use time as an impact tag when delay is the consequence of a source classified elsewhere, such as an unknown utility (C03) or late permit (C05).
|}

==Cross-cutting 2026 lenses==

Several important exposures cross multiple control domains. Creating a new primary category for each would encourage duplication, so they should be retained as mandatory secondary lenses or flags.

* '''Climate, natural hazards, resilience, and cascading dependencies.''' Apply where present or future climate conditions, acute hazards, chronic changes, recovery, service continuity, or dependence on power, communications, water, transportation, or other infrastructure materially affects the risk. Climate-risk assessment should address both vulnerability and present/future conditions.<ref name="ISO14091">International Organization for Standardization, [https://www.iso.org/standard/68508.html ''ISO 14091:2021, Adaptation to climate change — Guidelines on vulnerability, impacts and risk assessment''].</ref>
* '''Digital engineering, cyber/OT, data, and AI.''' Apply where a common data environment, BIM, digital twin, automation, cloud/vendor dependency, AI-assisted decision, software, SCADA, IoT, or operational technology is a material source or control. OT has distinct safety, reliability, and performance requirements and should not be treated as ordinary office IT.<ref name="NIST80082">National Institute of Standards and Technology, [https://csrc.nist.gov/pubs/sp/800/82/r3/final ''SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security''], 2023.</ref>
* '''Social acceptance, equity, and affected communities.''' Apply where distributional effects, land/resettlement, cultural heritage, vulnerable groups, transparency, consultation, disclosure, or grievance resolution are material. These are governable project conditions rather than public-relations afterthoughts.<ref name="WBESF">World Bank, [https://www.worldbank.org/en/projects-operations/environmental-and-social-framework ''Environmental and Social Framework''].</ref>
* '''Supply-chain and workforce concentration.''' Apply where lower-tier suppliers, specialist labor, critical materials/equipment, geopolitical/trade constraints, industrial action, or logistics concentration create correlated exposure.
* '''Emerging, systemic, interdependent, and cascading risk.''' Apply when the mechanism is novel, weakly understood, capable of affecting several packages or objectives, or capable of propagating through connected systems. The flag triggers wider scenario and dependency review; it is not an “other” category.

==Risk statement and minimum record==

Each risk should be written as a causal proposition:

:'''Because of [source/cause], there is uncertainty that [event or condition], which may affect [objective(s)] by [consequence].'''

At minimum, a governed record should contain:

# unique risk ID and common snapshot date;
# cause, uncertain event/condition, and consequences;
# one primary C01-C14 category and no more than two justified secondary categories;
# uncertainty character: epistemic, aleatory, or mixed, plus one or more independent causal-source tags;
# threat, opportunity, or mixed direction;
# program, reach/site, asset, package, WBS, SCC, estimate, schedule, and contract links as applicable;
# actual maturity profile of the affected unit, not merely the program's administrative milestone;
# affected objectives and time proximity;
# source owner, response/action owner, party with practical control, contractual bearer, and residual owner;
# inherent assessment, current controls, evidence reference, and residual assessment;
# treatment action, cost, due date, acceptance criteria, reviewer, and decision authority;
# dependencies, common causes, correlations, and linked risk-chain IDs;
# retirement test and specific conditions requiring reopening; and
# mapping to baseline uncertainty, estimate adjustment, schedule allowance, or discrete risk event to prevent double counting.

===Worked example===

''Because available records and field verification do not establish the horizontal and vertical position of a critical utility, there is uncertainty that the station excavation will encounter an unplanned conflict, which may require redesign, relocation, and delayed access to the workfront.''

* Primary category: C03 — Utilities, SUE, and relocations.
* Secondary category: C06 only if utility-owner decisions or agreement interfaces materially drive the uncertainty.
* Uncertainty character: principally epistemic. Causal-source tags: technical, plus organizational/behavioral if a third party controls access, design, or approval.
* Impacts: cost, time, service, and possibly safety; these are tags rather than separate risks.
* Physical links: station, excavation package, utility WBS/SCC items, affected schedule activities, and relevant contract provisions.
* Controls/evidence: verified SUE, test pits, conflict matrix, accepted relocation/protection design, utility agreement, outage window, and integrated schedule.
* Retirement: only after the utility is verified and the conflict is physically avoided, protected, or relocated and accepted. Substantial progress alone is not closure.

==FTA terminology and local stage/maturity tags==

FTA Oversight Procedure 40 uses four risk-register types—'''Requirements, Design, Market, and Construction'''—in Appendices E and O. Its cost model in Appendix J separately uses four partial Beta Range Factors (BRFs), plus a fixed '''Post-Construction''' factor. These are related constructs, but they are not five equivalent risk-register types.<ref name="FTAOP40">Federal Transit Administration, [https://www.transit.dot.gov/sites/fta.dot.gov/files/2024-11/Oversight-Procedure-40-Risk-and-Contingency-Review.pdf ''Oversight Procedure 40 — Risk and Contingency Review''], October 2023, especially Appendices E, J, and O.</ref>

OP40 also uses '''risk profile''' for a nonduplicated cost/phase partition in its quantitative process. The term should therefore not be used for the local maturity labels below. The C01-C14 domains may be crosswalked to the four FTA risk-register types when an FTA review requires it, but the two structures answer different questions.

Projects may define local '''stage/maturity tags''' when each tag has objective entry/exit evidence. The following list is illustrative and must be tailored rather than treated as a universal FTA sequence:

# concept and option development;
# FTA Project Development, where applicable—use the current statutory and FTA entry/exit criteria, not a local design-percentage proxy;
# Entry into Engineering, where applicable—an administrative program milestone with formal prerequisites, not a synonym for a design percentage or record of decision;
# grant agreement or other funding commitment—a funding/commercial gate, not a design-maturity proxy;
# controlled design-maturity review, such as a locally defined 60-percent package review;
# solicitation and procurement, ending at contract award;
# award and notice to proceed—record separately when they occur on different dates;
# early and mid-construction, using package-specific physical progress and completed hold points rather than program-wide percentages alone;
# completion of dominant high-exposure subsurface or structural work, if the project defines a local “deep-work complete” hold point with scope, evidence, and reopening conditions;
# systems integration, testing, safety certification, and operational readiness;
# revenue service or beneficial use; and
# contractual closeout and final account, recorded separately from operational opening.

Different packages and reaches may carry different tags on one program snapshot. Each affected unit should be assigned the tag supported by current evidence. A local tag should never be presented as an FTA term unless the governing FTA document uses it.

No risk is retired simply because a project passed a named stage. FTA guidance similarly cautions that risks should be retired only when the relevant condition is actually resolved and may need to be reopened when circumstances change.<ref name="FTAOP40" />

==Relationship to controls, evidence, and residual risk==

For each material category at a stage gate, the project should be able to demonstrate:

# the relevant source of uncertainty and affected unit have been identified;
# an accountable owner and decision authority have been assigned;
# a proportionate control has been designed and implemented;
# an artifact or record demonstrates implementation;
# a competent reviewer has compared the evidence with stated acceptance criteria;
# WBS/SCC/estimate/schedule/contract links remain current;
# residual exposure and its bearer are explicit; and
# retirement and reopening conditions are defined.

Contractual transfer does not remove the underlying physical risk. Transfer may change price, incentives, control, or the party that initially bears a loss, but the program retains exposure to performance failure, insolvency, interface effects, disputes, service delay, and other residual consequences. The taxonomy therefore records practical control and contractual/financial allocation separately.

==Relationship to quantitative analysis and contingency==

The taxonomy is an identification and governance structure. It does not assign a probability, tier, weight, or contingency percentage to a category.

Quantitative analysis should distinguish:

* '''base or background uncertainty''' in quantities, unit rates, production, and duration;
* '''identified project-specific threats and opportunities''' represented as discrete or conditional events; and
* '''bias, correlation, and common-cause effects''' that can invalidate a simple sum of independent estimates.

FTA's risk process likewise separates general uncertainty from project-specific risks and requires category, SCC, contract-package, and schedule linkages in the risk register.<ref name="FTAOP40" /> The taxonomy supports that process by improving completeness and traceability. The approved agency/owner quantitative risk method determines funding contingency; category counts and management tiers do not.

Reliable cost and schedule analysis should be grounded in the technical baseline, WBS, assumptions, data, estimating/scheduling methods, sensitivity and risk analysis, documentation, and updates with actual performance.<ref name="GAOCost">U.S. Government Accountability Office, [https://www.gao.gov/products/gao-20-195g ''Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Program Costs''], GAO-20-195G, 2020.</ref>

==Coding and maintenance rules==

# Classify the dominant '''control domain''', not the consequence. Cost and schedule are normally impact tags.
# Use one primary category. Use no more than two secondary categories and state why they are necessary.
# Distinguish risk from an issue already occurring, an assumption, a fixed constraint, and routine baseline variability.
# Do not duplicate a risk in several registers. Use common IDs and linked records across program, package, and discipline views.
# Use “other” only as a temporary code. Review all such entries and update the taxonomy when a recurring gap is demonstrated.
# Once version 1.0 is approved, keep C01-C14 stable through the life cycle. Add detail below the top level or through secondary lenses rather than frequently renumbering categories.
# Record the code version and maintain a mapping for merged, renamed, or deprecated subcodes.
# Review the taxonomy at formal stage gates and after material changes in delivery strategy, regulation, technology, market conditions, or operating context.
# Test whether controls and evidence are associated with improved outcomes before using taxonomy-based scores as predictive coefficients.
# Preserve identified-risk and background-uncertainty boundaries so contingency is not counted twice.

==Governance and proposed status==

This page is proposed as version 0.10 for professional review. Before adoption:

* assign an overall taxonomy owner and a discipline steward for every category;
* complete a crosswalk to the project's FTA, owner, or agency risk categories;
* test classification consistency using historical risks and independent reviewers;
* review category boundaries with geotechnical, utilities, real estate, environmental/social, design, construction, commercial, project-controls, safety/security, systems/cyber, operations, finance, and governance specialists;
* document disputed classifications and revise definitions, inclusions, and exclusions;
* validate every internal link and category against the approved canonical-title crosswalk; keep this review version in a Draft/User namespace without production categories; and
* approve version 1.0 through configuration control.

Calibration of weights, stage distributions, management tiers, or cost/schedule outcomes is a separate research and model-governance activity. Those values should not be inferred from this page.

==Limitations==

No taxonomy proves that all risks have been identified. Categories can improve the breadth and consistency of inquiry, but novel and interacting risks may cross boundaries or remain unrecognized. Classification also involves judgment; reasonable practitioners may select different primary categories when causal chains are complex.

The C01-C14 structure deliberately organizes risk around the professional process that primarily controls it. It is therefore an operational governance taxonomy rather than a pure ontology of causal sources. Cause-event-effect statements, cross-cutting lenses, dependency links, and the other facets above are necessary to avoid mistaking a convenient filing system for a complete explanation of risk.

==See also==

* [[Uncertainty and Risk in Civil Engineering Practice]]
* [[Project Definition]]
* [[Project Life Cycle and Phase Models]]
* [[Project Delivery Methods]]
* [[Management control|Management Control]]
* [[Management plans and sub-plans|Management Plans and Sub-Plans]]

==References==

<references />

* Federal Transit Administration, [https://www.transit.dot.gov/sites/fta.dot.gov/files/2025-02/Project-and-Construction-Management-Guidelines-January-2025.pdf ''Project and Construction Management Guidelines''], January 2025.
* International Organization for Standardization, [https://www.iso.org/standard/79637.html ''ISO 31073:2022, Risk management — Vocabulary''].
* International Electrotechnical Commission, [https://www.iso.org/standard/72140.html ''IEC 31010:2019, Risk management — Risk assessment techniques''].
* World Bank, [https://projects.worldbank.org/en/projects-operations/environmental-and-social-framework/brief/environmental-and-social-standards ''Environmental and Social Standards''].

Uncertainty and Risk in Civil Engineering Practice

2026-08-10T19:01:26Z

Pooyan: Restore native revision 219 (24 Nov 2024); add provenance note and link to 2026 taxonomy draft

:'''''Restoration note (August 2026).''' This article restores the site's native revision of 24 November 2024 (revision 219). The 20 January 2026 rewrite remains available in the [[Special:History/Uncertainty_and_Risk_in_Civil_Engineering_Practice|revision history]]. A proposed applied extension is under review at [[User:Pooyan/Civil Engineering Project Risk Taxonomy|Civil Engineering Project Risk Taxonomy]].''

'''Life is short and the art long; the occasion instant, experiment perilous, decision difficult.''' (Hippocrates as quoted in Fox,)
:''See also [[Project Definition]] , [[Project Life Cycle and Phase Models]] , [[Project Delivery Methods]]''
:''See also [[Technical Outcomes for Civil Engineering:Risk and Uncertainty]]''
==Basic Considerations==
As human beings,'' ... being alive means seeking opportunities and taking risks.'' As knowledge professionals
living in the 21st century, this means coping with an increasingly complex number of uncertainties for humans
living in this environment. We seek to understand better how these uncertainties can be characterized and
managed. The essence of this article and the experience for engineers in general and civil engineers in particular is
that manageable uncertainty is, by definition, termed risk, and its kindred cousin is termed hazard. This causes us to experience the
:" ''... human dread of and fascination for risk and the increasingly important role of risk analysis within societies ...'' " <ref name="McDaniels"> McDaniels, Timothy, and Mitchell Small. Risk analysis and society: an interdisciplinary characterization of the field. Cambridge University Press, 2004, page 1 </ref> (Ibid.)
and, by extension, civil engineering. McDaniels et al. argue that risk management has been
fundamental to our social and governance development for the past 10,000 years. The scale and shape of the
uncertainties faced in this period shaped the societies that have developed today. The central thrust of this effort
over the centuries has been to reshape and re-frame our understanding and conception of uncertainty from one of
complete unknowing and simple acceptance as our fate in life to one of management (cf "''Against the Gods''"
concept in Bernstein's book <ref name = Bernstein">Bernstein, Peter L., and Jesse Boggs. Against the gods. Simon & Schuster 1997.</ref>.
: ''All the knowledge professions and disciplines have struggled with managing uncertainty, for it is impossible to manage unbounded uncertainty.'' <ref group="note">See McDaniels et al. 2004 for an extensive discussion and bibliography on the historical development of Risk Analysis and some key milestones in risk analysis in the 20th century.</ref>
As outlined below, professions such as civil engineering have successfully acted in the face of uncertainty. It lies in the profession's ability to reduce a wide variety of uncertainties into increasingly smaller and crucially bounded subsets that can be managed. These are called 'risks. More recently, this process has evolved, and individual disciplines such as Civil Engineering (CE) have developed their knowledge and models to perform risk analysis. Risk is also taught as a distinct discipline and specialty practice within civil engineering. Still, it has some unique features that set it apart from other more classical practices within CE. As such, it is one of the first of some very specialized CE practices that use knowledge about civil engineering knowledge, or meta-knowledge. Other examples of civil engineering metaknowledge are project controls and quality controls.
==Semantic, Epistemic and Logical frameworks==
The semantic, epistemic, and logical frameworks for uncertainty and risk have several dimensions and layers of logical frameworks. The semantics problems include interchangeable usages for risk and uncertainty and hazard, uncertain and imperfect, and a lack of definitional material or context. The semantical scheme for this article will be to proceed from the distinction between certainty and uncertainty through marginal refinements and reductions of uncertainty up to the point of causal uncertainties. Beyond this point of semantics will be the logic frameworks or the subject of taxonomies of professional knowledge. First, it is about simple, testable phenomena, and then, it moves on to complex taxonomy schemes for artificially constructed phenomena or engineering projects.
<ref group="note">TBD</ref>
==Semantics framework==
===Certainty and Uncertainty===
''''' There is no such thing as absolute certainty, but there is assurance sufficient for the purposes of human life.''''' ([https://en.wikipedia.org/wiki/John_Stuart_Mill John Stuart Mill]) <br>
'''''If you tried to doubt everything, you would not get as far as doubting anything. The game of doubting itself presupposes certainty.''''' ([https://en.wikipedia.org/wiki/Ludwig_Wittgenstein Wittgenstein] # 115 from On [https://en.wikipedia.org/wiki/On_Certainty Certainty]) <br>
It is important to note that the references to epistemic or epidemiological knowledge in this article are assumed to relate to three forms of knowledge, namely:
* Knowledge that ( [https://en.wikipedia.org/wiki/Descriptive_knowledge descriptive or declarative or propositional knowledge])
* Knowledge how ( or "[https://en.wikipedia.org/wiki/Procedural_knowledge know-how]"), and
* [https://en.wikipedia.org/wiki/Knowledge_by_acquaintance Knowledge by acquaintance].
'''Certainty''' has been defined as "an epistemic property" of knowledge in all its forms and the state of our beliefs about that knowledge.
<ref>Certainty, Stanford Encyclopedia of Philosophy, accessed on September 12, 2015, at http://plato.stanford.edu/entries/certainty/#ConCer </ref>
Certainty about any belief about knowledge implies that it is not subject to doubt or skepticism. This immunity to criticism can be dogmatically based, emphasizing the importance of a propositional-based sense of truth over experiential, sensory perceptions. <ref>Definition of [https://en.wikipedia.org/wiki/Dogmatic_theology Dogmatic theology or belief], accessed at Wikipedia</ref>
: '''The demarcation line between dogmatic and non-dogmatic beliefs lies in the presence and recognition of specific criteria and information that would make the believer change their beliefs.'''
An empirical framework of [https://en.wikipedia.org/wiki/Testability testability] and [https://en.wikipedia.org/wiki/Falsifiability falsification] is required to recognize this and limit dogmatism. For example, one could argue that people would change their minds if God asked them to. Similarly, one could construct a concept of epistemic as opposed to dogmatic belief certainty as the ability to know anything that one chooses to know and can be known or [https://en.wikipedia.org/wiki/Omniscience inherent omniscience].

A second kind of certainty is epistemic, when conviction reflects the highest possible support for a belief. In this sense, knowledge is separate from beliefs, although someone may have beliefs about a property, such as certainty of knowledge. Logically, it has been shown that there will be unprovable statements within the system for any such knowledge system. Secondly, the knowledge system cannot demonstrate its own consistency. ([https://en.wikipedia.org/wiki/Gödel%27s_incompleteness_theorems Gödel's incompleteness theorems])
: '''Certainty, in real life, is useless or often damaging (the idea is that "total security from error" is impossible in practice, and a complete "lack of doubt" is undesirable)''' ([[https://en.wikipedia.org/wiki/Certainty Physicist Carlo Rovelli]])
'''Uncertainty''', on the other hand, arises immediately in the slightest amount of doubt or criticism.
<ref group="note"> The Merriam-Webster dictionary defines uncertainty as “the quality or state of being uncertain,” which is something of a circular definition. Likewise, one could define uncertainty as the state of not being certain.

Synonyms are distrust, doubt, misgiving, mistrust, reservation, skepticism, and suspicion. Another writer added indefinite, indeterminate, not certain to occur, problematical, unreliable, untrustworthy, unknown beyond doubt, dubious, doubtful, not clearly identified or defined, not constant, variable, and fitful to the list.
:(Han, Paul KJ, William MP Klein, and Neeraj K. Arora. "Varieties of Uncertainty in Health Care: A Conceptual Taxonomy." Medical Decision Making 31.6 (2011): 828-838.)
Han et al. noted that any definition of uncertainty clearly encompasses "...numerous types, sources, and manifestations of uncertainty, and ...(any) ...useful working definition of uncertainty needs to specify the concept underlying these varied meanings of the term."</ref>
Implicit in this definition of uncertainty as a “state of” is ...
"...a conceptualization of uncertainty as a subjective, cognitive experience of people—a state of mind rather than a feature of the objective world. Furthermore, the defining feature of this state appears to be a lack of knowledge about some aspect of reality. Importantly, however, the concept of uncertainty also implies a subjective consciousness or awareness of one’s lack of knowledge, without which one could not feel uncertain; uncertainty is a form of “meta-cognition” ...(or its main component, meta-knowledge)... —a knowing about knowing." (Han, 2011, op. cit., Emphasis added)
Similarly, uncertainty could be defined as "...any departure from the unachievable goal of complete [https://en.wikipedia.org/wiki/Determinism determinism]."
<ref name="Walker1">Walker, W. E., Harremoës, P., Rotmans, J., Van Der Sluijs, J. P., Van Asselt, M. B., Janssen, P., & Krayer von Krauss, M. P. (2003). Defining uncertainty: a conceptual basis for uncertainty management in model-based decision support. Integrated assessment, 4(1), 5-17.</ref>
Reasoning under uncertainty is very different than performing the same under certainty. In reasoning under certainty, one has complete knowledge and deduces without doubt and equally important, without limitation, thereby concluding free from error. Reasoning under uncertainty, one works in a state of incomplete, inconsistent, and limited knowledge; doubts cloud any statements or assertions and thereby taint any deductions/inferences resulting in the potential for error. <ref group="note">Implicit in this definition of uncertainty as a “state of” is ...
"...a conceptualization of uncertainty as a subjective, cognitive experience of people—a state of mind rather than a feature of the objective world. The defining feature of this state, furthermore, appears to be a lack of knowledge about some aspect of reality. Importantly, however, the concept of uncertainty also implies a subjective consciousness or awareness of one’s lack of knowledge, without which one could not feel uncertain; uncertainty is a form of “meta-cognition” ...(or alternatively, its main component, meta-knowledge)... —a knowing about knowing." (Han, 2011, op. cit., Emphasis added)</ref>
:'''Knowledge professions reason in a state of incomplete, inconsistent and limited knowledge with doubts that cloud any statements or assertions and taint any deductions/inferences resulting in the potential for error.'''
:''' It is also important to note the semantical and logical correlation between 'reasoning under uncertainty' or 'acting in the face of uncertainty' with the 'potential for' or 'presence of' error. The presence of uncertainty is invariably linked to the potential presence of error.''' The [https://en.wikipedia.org/wiki/Contingency_(philosophy) contingent] nature of uncertainty logically implies the contingent nature of error.
:'''Knowledge Professions use error as a proxy for uncertainty such that within discipline knowledge frameworks, uncertainty can be managed.''' The rationale for this belief is that error can be reliably described, quantified, explained, and ultimately reduced in ways that uncertainty cannot.

'''Uncertainty''' implies a range of variation that is impossible in certainty. Concepts and definitions of uncertainty are unbounded and vast but start from the point of complete and total ignorance. In describing uncertainty, statements can range from complete ignorance to relatively high degrees of belief that there is less potential for error in our reasoning or action. The latter is based upon confidence in justified knowledge, favorable past experience, and reliable parameters/models. One can't make that statement about ranges in certainty. If certainty, by definition, precludes doubt of any type or nature, then how could that be graduated to any degree? <br>
Uncertainty, on the other hand, can be reduced through disciplined efforts to acquire knowledge. In short, we can reduce or even manage uncertainty (to a degree); how can certainty be improved? Are there higher degrees of perfection? The answer is no. We reason from an uncertain starting point. Yet this effort presumes, as Mill and Wittgenstein postulated, that we can develop or acquire an increasing degree of belief or conviction that there is less potential for error in our reasoning or action. This position assumes that some way exists to identify what a lesser degree of uncertainty would look like.
:'''Knowledge professions acquire an increasing belief or conviction that there is less potential for error in their reasoning or action based on justified knowledge, favorable past experience, and reliable parameters/models.'''
Uncertainty is, in some form, amenable to description and explanation through observation and analysis. It is explainable and predictable to such a degree that it interests professionals such as scientists and engineers. Professional knowledge of this type has explanatory or predictive power, albeit limited in scope and application to relevant subjects such as physical objects or phenomena and functionality.
:'''The very act of reducing the scope of uncertainty to a limited set of phenomena implies choice and, ultimately, the decision to act in the face of such uncertainty, but acting or judging in this manner adds more value than doing the same under relative ignorance.'''
'''Uncertainty''', as described above, implies a hybrid nature. Examples of this are economic or decision-theoretic applications. In economics, [https://en.wikipedia.org/wiki/Perfect_information perfect information] allows one within the limiting framework of perfect competition in economic games to make decisions with 'perfect knowledge.' The crucial difference here is the distinction between '[https://en.wikipedia.org/wiki/Perfection perfection],' broadly, a state of completeness and lawlessness, and 'perfect, which can be thought of as an analytical limit that is approachable but can never be attained. Arbitrarily delimiting the realm of knowledge into defined, finite boundaries allows the simulated production of perfect choice, assumed crucially, to be free from error. The hybrid nature of this form of 'simulated' certainty produced within boundaries defined by assumptions and, therefore, clouded by doubt is itself a form of uncertainty. The importance of this is the semantical and logical association that exists between certainty and perfection versus the hybrid concept of a perfect anything, whether knowledge, infraction, competition, etc., or in the case of engineering, elastic, permeable, conductive, etc., being contained within an admittedly imperfect matrix of uncertainty.
:'''Simply put, a finite, heavily bounded piece of uncertain knowledge can be improved through the simulated use of [https://www.merriam-webster.com/dictionary/assumed assumedly] perfect information, but the perfection of knowledge cannot be attained or simulated.'''
Engineering and Economics, for example, simulate finite elements of perfect knowledge or information, heavily bounded with assumptions and a range of applications. By doing so, these professions reduce the bounds and variability of uncertainty and thereby manage it. Using these hybrid models to acquire knowledge takes place in an economy (regulated or institutional) and environment (transparent and structured), which puts pressure on the various professions to recognize and use qualitative and quantitative knowledge better to reduce uncertainties in their activities. The challenges in this reflect the nature of the profession's or discipline's knowledge (e.g., scientific, engineering, or medical), the policies and structure of the relevant professional knowledge bodies, process objectives, constraints, and "the elusive demands of politics." <ref name="siren">Walker, Vern R. "The siren songs of science: toward a taxonomy of scientific uncertainty for decision-makers." Conn. L. Rev. 23 (1990): 567.</ref>
One common theme runs through all of these efforts to address the presence of uncertainty in professional activities. <br>
:"The available scientific information upon which a decision must be made is almost always a mixture of engineering knowledge and uncertainty. Regardless of the information or methodology, there is the potential for error. This is true regardless of the relevant science, whether archaeology or aeronautics, economics or engineering, pharmacology or toxicology or epidemiology. Achieving the best social decisions requires not only understanding and using what we know but also appreciating and weighing the extent of our uncertainty. In making the best use of ... information in ... decision-making, it is still true that the beginning of wisdom is knowing what it is we do not know." (Vern, Op. cit., Reformatted and engineering substituted for scientific) <br>
'''Driven by practical objectives and benefiting from past experience, knowledge professions such as engineering start by reasoning from uncertainty to develop explanations, calculate, and make predictions. This professional knowledge converges on but never reaches certainty, producing a "legitimacy" from the fruitfulness of its use.''' <ref>Randomness Is Unpredictability, Antony Eagle, The British Journal for the Philosophy of Science, Vol. 56, No. 4 (Dec., 2005), pp. 749-790 </ref> <br>
[[#top|Top of current page]]

=== Bias and Uncertainty ===
Up to this point, the concept of error, as outlined in uncertainty, could easily be simulated by a truly random variable. There should be no detectable differences around the unseen or specified statistical mean. However, several instances in experience point to a tendency towards one extreme or a pattern of error, a collective that is in itself an error of errors, namely [https://en.wikipedia.org/wiki/Bias bias].

Arguably, this could be part of the choice uncertainty discussion below, but it makes more sense to be looked at on its own. Acting in the face of uncertainty is an exercise of personal knowledge or experience. Whether using professional knowledge or individual experience, the potential is there to make a series of choices that, in some instances, make errors more likely than they would be if considered in the context of a statistical analysis.

This tendency for an individual to make the same error in a predictable or repeatable manner is termed bias. Personal experience, beliefs, knowledge, data, and models all have inherent built-in factors, errors, or defects that create predictable error patterns when applied in decision-making. Walker (1998) argues implicitly that such bias can also be considered systemic error. This type of uncertainty is difficult to identify except on theoretical grounds when the magnitude and direction of the bias are known. Most of these biases, whether systemic or knowledge-based, individual or practice-based, require disciplined efforts to "validate" such methods, models, and judgments at all layers while bounding the uncertainty.
: This is the challenge to professional knowledge that must be overcome, namely, developing and validating models and methods for managing bounded uncertainty that minimize this tendency towards repeatable groups of error or bias. Therefore, from this point forward, the discussion will refer to 'uncertainty and its proxies, error, and bias.'
===Propagating Error and Uncertainty===
Partitioning uncertainty and its proxies, error, and bias into logically distinct subsets involves or is associated with multiple-step execution or choice frameworks. Combining those measurements or choices into single parameters or choices involves, in some cases, assembling the data/information in a unique or limited range of sequences. This implies that associated errors in observing, calculating, or choosing will have unequal impacts or consequences depending on where in the chain the error occurs. Also implied in this is the possibility that subsequent errors will be causally linked to some degree. (In statistical practice, this depends upon whether the errors are independent of each other or correlated, specifically, co-variant.)
:'''Professions develop knowledge of how uncertainty and its proxies, error, and bias propagate through an ordered and normative series of observations or choices. This allows the profession to prioritize error and bias reduction to achieve an optimized reduction of uncertainty.'''
[[#top|Top of current page]]
===Cognition, Metacognition and Uncertainty===
The concept of choice and the resultant error in uncertainty can be further delimited depending on the role of [https://en.wikipedia.org/wiki/Cognition cognition], [https://en.wikipedia.org/wiki/Metacognition meta-cognition], and independent external elements. The rationale for this argument is that such choice activity in the face of uncertainty is a conscious, cognitive act.

An argument could be made that such cognition is a prerequisite for exercising choice and introducing error, as presented and discussed above. The counterfactual to this argument is the example of uninformed choice. Choices introduce as much as errors or more as informed choices could be made. (???) Choice, in this sense, is indifferent to knowledge. Purposeful choice in an environment of objectives requires knowledge, method, and experience, but uninformed, speculative choice does not.
:"''' Cognition''' is the set of all mental abilities and processes related to knowledge, attention, memory and working memory, judgment and evaluation, reasoning and "computation," problem-solving and decision making, comprehension and production of language, etc. Human cognition is conscious and unconscious, concrete or abstract, as well as intuitive (like knowledge of a language) and conceptual (like a model of a language). Cognitive processes use existing knowledge and generate new knowledge." (Wikipedia)
:"'''Metacognition''' is "cognition about cognition", or "knowing about knowing" and can take many forms. It includes knowledge about when and how to use particular strategies for learning or problem-solving. There are generally two aspects of [https://en.wikipedia.org/wiki/Metacognition metacognition]: knowledge about cognition and regulation of cognition."
Some types of metacognition knowledge are:
:'''Person knowledge''' (declarative knowledge), which is understanding one's own capabilities.
:'''Task knowledge''' (procedural knowledge), which is how one perceives the difficulty of a task, which is the content, length, and type of assignment.
:'''Strategic knowledge''' (conditional knowledge) is one's capability to use strategies to learn information. (Accessed at Wikipedia)
Like metacognitive knowledge, metacognitive regulation or "cognitive control" contains three essential skills.
:'''Planning:''' refers to the appropriate selection of strategies and the correct allocation of resources that affect task performance.
:'''Monitoring:''' refers to one's awareness of comprehension and task performance.
:'''Evaluating:''' refers to appraising the final product of a task and the efficiency at which the task was performed. This can include re-evaluating strategies that were used. (Accessed at Wikipedia)
Nothing has been said up to this point that limits this structure to an individual, or a collective, or two entities making cognitive choices that are incompatible or inconsistent to varying degrees. Interpretations of this scheme include an individual professional exercising judgment in a decision that, in turn, relies upon the collective judgment and decision of the discipline as an underlying basis versus the decision of another individual to oppose/protest or otherwise contest that decision. Thus, the framework of cognitive/meta-cognitive applies to individuals, collectives, and controversies. In economic theory, this could be recast to cognitive/meta-cognitive roles in the theory of rational choice, economics of regulatory practice, and game theory.
:By solving useful problems in the face of inherent uncertainty, discipline-specific frameworks of cognitive/meta-cognitive activity apply to individuals, collectives, and controversies. In economic theory, this could be recast to cognitive/meta-cognitive roles in the theory of rational choice, the economics of regulatory practice, and game theory.
[[#top|Top of current page]]

===Probability and Uncertainty===
Probability is a [https://en.wikipedia.org/wiki/Coherence_theory_of_truth coherent] approach to uncertainty in the physical and mathematics or "classical" domains such as engineering. <ref>See Colyvan for a critique of this claim, Colyvan Mark. "Is probability the only coherent approach to uncertainty?." Risk Analysis 28.3 (2008): 645-652.</ref> and is the "...is certainly the best-known and most widely used formalism for quantifying uncertainty.<ref>Morgan, Millett Granger, Max Henrion, and Mitchell Small. Uncertainty: a guide to dealing with uncertainty in quantitative risk and policy analysis. Cambridge University Press, 1992.</ref> [https://en.wikipedia.org/wiki/Cox%27s_theorem Cox’s theorem] ("Any measure of belief is [https://en.wikipedia.org/wiki/Isomorphism isomorphic] (but not necessarily equal) to a probability measure") is a well-known argument for the validity of that argument.
<ref group="note">Cox wanted his system to satisfy the following conditions:<br>
Divisibility and comparability – The plausibility of a statement is a real number and is dependent on the information we have related to the statement.
:Common sense – Plausibilities should vary sensibly with the assessment of plausibilities in the model.
:Consistency – If the plausibility of a statement can be derived in many ways, all the results must be equal.
Cox's theorem has come to be used as one of the justifications for the use of Bayesian probability theory. (For example, in Jaynes Jayne, Probability Theory: The Logic of Science, Cambridge University Press (2003). — preprint version (1996) at http://omega.albany.edu:8008/JaynesBook.html; Chapters 1 to 3 of published version at http://bayes.wustl.edu/etj/prob/book.pdf</ref>

Another writer, [https://en.wikipedia.org/wiki/Frank_Knight Knight] (1921,1956), presented the following taxonomy of probabilities:
<ref>As presented and discussed in Runde, Jochen. "Clarifying Frank Knight's discussion of the meaning of risk and uncertainty." Cambridge Journal of Economics 22.5 (1998): 539-546.</ref>
: '''Classical 'a priori' probability:''' As an idealized model, numerical probabilities are computed based on generalized principles of assigning equal likelihoods and mutually exhaustive possible outcomes (Runde, 1998) to all set members. Such probabilities are assigned to "...outcomes based on a judgment of indifference between those outcomes, that is, based on the absence of any evidence of real influences in play that may render any one outcome more or less probable than any other." (Runde, op. cit.) This builds upon Knights's concept of an 'absolutely homogeneous classification of instances that are completely identical except for [https://en.wikipedia.org/wiki/Indeterminate_(variable) indeterminate] factors. This judgment of probability or logical probability is on the same logical plane as the propositions of mathematics and ultimately [https://en.wikipedia.org/wiki/Inductivism inductions] from experience.'(Knight, 1956, pg.225)
: '''Bayesian 'a priori' probability:''' In contrast to interpreting probability as the "frequency" or "propensity" of some phenomenon, [https://en.wikipedia.org/wiki/Bayesian_probability Bayesian probability] is a quantity that we assign to represent a state of knowledge or a state of belief. In this view, probability is assigned to a hypothesis, often using the basis of past or prior experience. In contrast, under the frequentist view, a hypothesis is typically tested without being assigned a probability based on prior experience. The Bayesian interpretation of probability can be seen as an extension of propositional logic that enables reasoning with hypotheses, i.e., propositions whose truth or falsity is uncertain. Bayesian probability belongs to the category of evidential probabilities; to evaluate the probability of a hypothesis, the Bayesian probabilist specifies some prior probability, which is then updated in the light of new, relevant data (evidence). The Bayesian interpretation provides a standard set of procedures and formulae to perform this calculation. <ref>See also Larvor, B. "After Popper, Kuhn, and Feyerabend: Recent Issues in Theories of Scientific Method." Metascience (2002).</ref>
: '''Statistical or 'a posterior probability:''' Empirical evaluation of the frequency of association between predicates, not analyzable into varying combinations of equally probable or logical, 'a priori' alternatives. Knight argued that any "high degree of confidence" that the judgment that experience will remain valid for future predictions is "...still based on an 'a priori" judgment of indeterminateness." (Knight, Op. Cit.) Knight's argument to support this is what will be discussed further below that first, "...the impossibility of eliminating all factors not really indeterminate; and, second, the impossibility of enumerating the equally probable alternatives involved and determining their mode of combination so as to evaluate the probability by a priori calculation." (Knight, Op. Cit.) Knight noted that the main difference between this form and that of logical or inductive probability was the presence of empirical information, which allowed the analyst to identify propensity and direction in the observed phenomena. In this case, 'a priori' probability values may be derived from first principles and "statistical probabilities are determined a posteriori by the empirical method of counting instances." (Runde [1998] quoting Knight, op. cit.)
:'''Estimates:''' The distinction here is that there is no valid basis ('a priori' or 'a posteriori') for any classifying phenomena. For Knight, this form of probability presented the greatest logical difficulties of all ... but its distinction from the other types must be emphasized, and some of its complicated relations indicated..." (pp. 224-5, emphasis in the original)

Knight's concept of probability can be viewed as "..a continuum of probability situations, depending on the degree of homogeneity of the 'instances' in question" <ref>Runde, Jochen. "Clarifying Frank Knight's discussion of the meaning of risk and uncertainty." Cambridge Journal of Economics 22.5 (1998): 539-546.</ref>; i.e. going from a logically distinct but equally likely set of elements to a unique set with one member with statistical frequency in the middle. Knight's main motivation for distinguishing between a priori probability and statistical probability underscores his opinion that "(i) the 'mathematical or a priori type of probability is practically never met with in business, while the second is extremely common'; and (ii) 'the statistical treatment never gives closely accurate quantitative results' (Runde quoting Knight pp. 215-16). Runde argues that Knight couldn't conceive of (empirically tabulated) occurrences that are used in daily commerce classes of instances that we have to make do within the course of everyday economic life could be divided into subclasses of instances that are sufficiently homogeneous to permit the determination of what he calls 'real' probability (p. 217).
:'''In modeling degrees of uncertainty, any measure of belief is isomorphic but not necessarily equal to a probability or statistics measure'''.
[[#top|Top of current page]]

===Explanation, Prediction and Uncertainty===
It should be clear that the general notion of uncertainty synonymous with complete ignorance must be bounded as part of a scheme to produce a useful concept of uncertainty in professional practice such as civil engineering.
:The first principle that must be introduced is that such uncertainty must be bounded by reliable and valuable knowledge gained from past experience combined with analytical and computational capabilities to address an immediate and real problem of interest. This could be viewed as the economic interest argument. Only uncertainties associated with physical phenomena and economic scarcity will be addressed.
:The second principle is that the knowledge model is capable of producing statements or assertions in the form of hypotheses that themselves are testable. [https://en.wikipedia.org/wiki/Testability Testability], in this sense, is defined as the property applying to an empirical hypothesis and involves two components:
::The logical property that is variously described as contingency, defeasibility, or falsifiability, which means that counterexamples to the hypothesis are logically possible. Contrast this to a [https://en.wikipedia.org/wiki/Tautology_(logic) logical tautology], which is always true that is true in every possible interpretation. The practical feasibility of observing a reproducible series of such counterexamples if they do exist. In short, a hypothesis is testable if there is some real, non-zero expectation of deciding whether it is true or false of verifiable, reproducible experience. Upon this property of its constituent hypotheses rests the ability to decide whether a theory can be supported or falsified by actual experience data. (Source Wikipedia.)
'''Knowledge models must be capable of producing expressions that can explain phenomena (physical, economic, and social) that meet the testability criteria described above in 'reasoning under uncertainty' or 'in the face of uncertainty' with the 'potential for' or 'presence of' error and bias.'''
===Variability and Aleatory Uncertainty===
The discussion up to this point has focused on uncertainty associated with various forms of knowledge referred to as epistemic uncertainty. Acting in the face of epistemic uncertainty introduces choice uncertainty (discussed below) and results in the production of explanations and predictions. It is implied that there will be testable hypotheses in the form of outcomes of interest to the knowledge professions. Inherent in nature is a variation of results, which may appear to uncertain but isn't. Observations of phenomena will not be the same, and part of the experimental process is to narrow those results down to within an acceptable level of tolerance. Statistical measures seek to identify underlying and unobserved measures of central tendency. These parameters are not directly observed but are derived to a degree of confidence.
In some cases, variation around a mean or within a statistical range may be perfectly acceptable to the knowledge profession. Examples of this are in the physical sciences and medicine. In Engineering and, to a lesser extent, economics, the process or phenomenon may be required to be more controlled to a narrower range than what a natural or "unmanaged" amount of variation would allow. Several courses of action present themselves.
:The first would be to ignore the aleatory phenomenon and choice, which is rejected outright.
:The second would be to assume that, in effect, such variation is itself a form of minimally managed uncertainty and treat it the same as epistemic uncertainty. This is not a desirable outcome as reducing Aleatory error and bias requires
:A third approach would be to acknowledge that process variation is, in some forms, manageable. This means making choices and acting in a way that presumes that the natural occurrence of error can be reduced, or more importantly, bias can be reduced. There is ample precedent for the third approach in civil engineering design and project management. In this sense, the argument is made that the aleatory response to managed efforts results in an elastic variation range. Presumably, an effective management effort either "shifts" the central tendency of the process results or reduces the variation range of occurrence or some other population parameter. Choosing to act and accept that narrower range rather than the broader natural variation may result in an outcome that, while well within the bounds of the expected variation, is outside the arbitrary control limits established by the choice and action. While this phenomenon mimics the broader uncertainty and its proxy error, it is not an error. The information on the variation was known, and the ability to produce narrower results was an error, albeit a pseudo-error, when compared to the broader classes of uncertainty discussed above, such as total ignorance.
::Looking at uncertainty using this third approach means that the error in choosing a new target parameter for this process may contain epistemic errors (our knowledge of the phenomenon may be erroneous, or the model flawed), aleatory uncertainties as discussed, or, more importantly, choice error or bias in thinking that we can move the process results to meet the requirements.
:'''In civil engineering practice, this may mean applying professional judgment in developing partitioning schemes or allocating uncertainty between the three dimensions (Epistemic, Aleatory, and Behavioral) of uncertainty.'''
Lastly, raising the topic like this brings the questions of effectiveness and efficiency to the fore. Advancing knowledge models that reduce error and bias at first are largely choice models resulting in justifications and favorable experiences. At some point in the process, the knowledge profession advances explanations and predictions that require reliable mathematical or logical concepts that are reduced to models and parameters. The question of efficiency becomes important; the broader uncertainty may have been reduced, but the process is economically inefficient. The profession is urged to become more frugal or, for example, reduce the variability of the outcomes. Knowledge professions often operate under conditions that require them to acquire knowledge and reduce uncertainty effectively and efficiently. Doing so requires understanding both epistemic uncertainty, as discussed above, and statistical process variation or aleatory variation.
:'''Knowledge professions manage and reduce uncertainty in the form of error and bias in an economically effective and efficient manner. This effort requires understanding both epistemic and aleatory uncertainty.'''
[[#top|Top of current page]]

===Choice and Behavioral Uncertainty===
The discussion up to this point has focused on uncertainty associated with various forms of knowledge, referred to as epistemic uncertainty, as well as the inherent variations in results, or what was termed aleatory uncertainty. Acting in the face of that epistemic and aleatory uncertainty introduces yet another uncertainty into the process, namely choice uncertainty. This uncertainty reflects uncertainties associated with first-person and third-person choice. This is particularly relevant for engineering with project stakeholders.
===Summary of Semantics Framework for Uncertainty===
Professional disciplines have gradually re-framed their understanding of uncertainty and, thru experience and analysis, have arrived at the following meta-knowledge concepts of uncertainty:
* '''Uncertainty and its proxy, error, have three components: [https://en.wikipedia.org/wiki/Uncertainty_quantification#Aleatoric_and_epistemic epistemic uncertainty], [https://en.wikipedia.org/wiki/Uncertainty_quantification#Aleatoric_and_epistemic aleatory uncertainty], and behavioral uncertainty.'''
* '''Driven by practical objectives and benefiting from past experience, knowledge professions such as engineering start by reasoning from uncertainty using non-dogmatic beliefs, which recognize the existence of specific criteria and information that would make the believer change their beliefs using coherent approaches such as probability.'''
* '''Knowledge professions develop knowledge of how uncertainty and its proxy, error, propagate through an ordered and normative series of observations or choices that meet testability criteria in 'reasoning under uncertainty' or 'in the face of uncertainty' with the 'potential for' or 'presence of' error. An error can then be described, explained, and reduced in ways that uncertainty cannot. This allows the professions to prioritize error reduction to achieve an optimized reduction of uncertainty and produce a "legitimacy" from the fruitfulness of its use.'''
[[#top|Top of current page]]
===Uncertainty versus Risk/Hazard===
Up to this point, nothing has been said about risk or hazard. Now, risk can be defined. Simply put risk or hazard are finite, logically distinct subsets of the broader uncertainty. Risk and hazard are currently defined interchangeably. First and foremost, risk is a specific subset of general uncertainty. Any arbitrary subset of general uncertainty can be defined as a risk if it meets the following criteria:
* Uncertainty is associated with the potential for material error when acting or choosing in the face of such uncertainty in an environment of physical, economic, and social phenomena.
* Uncertainty and its proxy, error, can be partitioned into logically distinct subsets associated with multiple-step execution or choice frameworks in physical environments linked to a unique or limited range of sequences.
**Subcriteria 1:Resulting errors will have varying impacts or consequences depending on where the error occurs and the degree of causal linkage or influence in the chain.
**Subcriteria 2:Potential errors can be sequenced and prioritized to achieve an optimized reduction of error or bias and, by proxy, uncertainty over time.
* Uncertainty and its proxies, error bias, and environments are isomorphic to coherent approaches such as probability.
* Uncertainty and its proxies, error, and bias are isomorphic to coherent approaches such as knowledge models capable of producing expressions that can explain phenomena (physical, economic, and social) that meet the testability criteria in 'reasoning under uncertainty.'
This is a definition of general risk. There is no differentiation for engineering or economics, medicine or insurance. There is no difference between a 'good' risk consequence and a 'negative' one. Redefining general risk into simpler terms gives the following:
:'''General Risk is a subset of general uncertainty that is associated with the potential for material errors and biases when sequentially acting or choosing in the face of such uncertainty in an environment of physical, economic, and social phenomena; isomorphic to probability measures and methods and capable of testability.'''
[[#top|Top of current page]]

==Logical Framework for Specific Risk Taxonomies==
As noted above, at the most fundamental level, uncertainty is ".....the subjective perception of ignorance."
<ref name="Han">Han, Paul KJ, William MP Klein, and Neeraj K. Arora. "Varieties of Uncertainty in Health Care A Conceptual Taxonomy." Medical Decision Making 31.6 (2011): 828-838.</ref>
At this point in the discussion, the focus has moved from discussing uncertainty to its framed subset, risk.
:'''Further, the discussion moves from general risk to a professional or discipline-specific risk [https://en.wikipedia.org/wiki/Taxonomy taxonomy]. Beyond this point, risk will be used in place of uncertainty.'''
Han et al. note that, in general, "(t) taxonomies are valuable not only in their comprehensiveness but in their coherent reduction of uncertainty to conceptually discrete elements."
Uncertainty (and, by implication, risk or hazard) taxonomies offer an approach or tool to more precisely identify and define ontological uncertainty so that it can be quantified, analyzed, and communicated. Viewed this way, uncertainty is not a single, monolithic phenomenon but "...multi-dimensional with theoretically distinct domains and constructs that are potentially measurable and related to different outcomes, mechanisms of action, and management strategies." <ref name="Han"/> Taxonomic schemes for classifying the different kinds of scientific and, by extension, engineering uncertainty require identifying the various kinds of potential error associated with descriptive scientific or engineering information and knowledge. An example of this is the following quote from a legal authority:
:"I would especially stress the need for an agency to disclose the uncertainty that surrounds its determinations. ''' And by uncertainty, I mean the agency's ignorance as well as its quantitative estimates of error."''' (Emphasis added)
<ref>Walker citing Bazelon, Science, and Uncertainty: A Jurist's View, 5 HARV. ENVTLt L. REv. 209, 212 (1981).</ref>
''' Given the necessity of acting in the face of enormous uncertainties
<ref>Vern citing Ruckelshaus, Science. Risk, and Public Policy, 221 SCIENCE 1026, 1027 (1983)</ref>,
discipline taxonomies must offer a clearly coherent and probabilistic approach to uncertainty that is sufficiently general in nature, logically distinct and exhaustive in scope and "...provide decision-makers with a foundation for understanding the nature of discipline information..."''' <ref name="siren"/>

[[#top|Top of current page]]
=== Scientific Risk Taxonomies ===
The [https://en.wikipedia.org/wiki/Scientific_method scientific method] is a body of techniques for investigating phenomena in its environment, acquiring new knowledge, or correcting and integrating previous knowledge. Inherent in that process are uncertainties of many forms. Any one taxonomy of [https://en.wikipedia.org/wiki/Uncertainty scientific uncertainty] has largely been focused on statistical models used to assess and quantify sampling, errors, and parameters, although several different taxonomies are conceivable: note-24 [18]
====Environment-specific, Phenomena oriented, model-centric taxonomy of uncertainties====
** [https://en.wikipedia.org/wiki/Uncertainty_quantification#Sources_of_uncertainty '''Parameter uncertainty'''] the source of which is model parameters that are inputs to the computer model (mathematical model) but whose exact values are unknown and cannot be controlled, or whose values cannot be exactly inferred by statistical methods. Subsets of this type of uncertainty include but are not limited to:
***'''Experimental uncertainty''' is also known as observation error, which comes from the variability of experimental measurements. An example is repeating an experiment measurement several times using exactly the same settings for all inputs/variables and recording the variability. It is a subset of the larger uncertainty component, parameter uncertainty.
*** '''Parametric variability''' comes from the variability of the input variables of the phenomena model and is also a subset of the larger uncertainty component, parameter uncertainty.
** '''Structural uncertainty''', or model inadequacy, model [https://en.wikipedia.org/wiki/bias bias] or "[https://en.wikipedia.org/wiki/Systemic_bias systemic bias]", or model discrepancy, which comes from the lack of knowledge of the underlying true state of the phenomenon or its environment. It depends on how accurately a mathematical model describes the true state of the phenomenon or what is termed "model fitness". Due to the inherent nature of uncertainty in any knowledge body (scientific or engineering), models are only an approximation to reality. Therefore, any conclusions drawn from the model can be very misleading when the underlying basis is not plausible or lacks validity. '''note-25 [19]]'''
*** What is missing in this context is any concept of output variability due to the model itself. Part of this is due to the lack of recognition of "process" in scientific investigation. The concept of the scientific method started with a single investigator, such as Galileo or Michael Faraday, working in their laboratories. It has grown into planet and solar system scale experiments such as data gathered on planetary flybys such as Mars, Pluto, and Ceres to the hunt for the Higgs Boson. Ultimately, science has become more like engineering in the scale and complexity of its investigations and theory aggregates, such as the "Unified theory" of particle physics. Subsets of this type of uncertainty include but are not limited to:
*** '''Algorithmic uncertainty''', or numerical uncertainty, comes from numerical errors and numerical approximations per implementation of the computer model. Most models are too complicated to solve exactly. For example, the [https://en.wikipedia.org/wiki/Finite_element_method finite element method] or [https://en.wikipedia.org/wiki/Finite_difference_method finite difference method] [may be used to approximate a solution [https://en.wikipedia.org/wiki/Partial_differential_equation partial differential equation], which introduces numerical errors. Other examples are numerical integration and infinite sum truncation, which are necessary approximations in numerical implementation.
*** '''Interpolation uncertainty''' comes from a lack of available data collected from computer model simulations or experimental measurements. For other input settings that don't have simulation data or experimental measurements, one must interpolate or extrapolate to predict the corresponding responses.
[[#top|Top of current page]]

====Commentary====
A more comprehensive taxonomy of uncertainties that acknowledges knowledge, data, and linguistic uncertainties is:
*'''Epistemic uncertainty''' -[https://en.wikipedia.org/wiki/Uncertainty_quantification#Aleatoric_and_epistemic_uncertainty Epistemic uncertainty] or systematic uncertainty, in contrast, reflects limitations in the current “state of knowledge” underlying models themselves, originates from competing theories or models, is not readily quantifiable, and is manifest by subjective confusion or indecision. It includes uncertainty due to measurement limitations, insufficient data, extrapolations and interpolations, and variability over time and space. Epistemic uncertainty is uncertainty about "...some determinate fact ... because of a lack of complete information. '''cite_note-26 [20]]''' Epistemic uncertainty can be classified into six main types:'''cite_note-27 [21]]'''
*''' Measurement error''' - [https://web.archive.org/web/20170227055023/http://en.wikipedia.org/wiki/Observational_error Measurement error] is uncertainty that manifests itself as (apparently) random variation in the measurement of a quantity. Repeated measurements will vary and demonstrate classic statistical behavior.
* '''Systematic error''' - [https://en.wikipedia.org/wiki/Observational_error Systematic error] occurs due to bias in the measuring equipment, model, analysis, observation, or sampling procedure. It is formally defined as the difference between the true value of the quantity of interest and the value to which the mean of the results converges as sample or data sizes increase. Unlike measurement error, it is not (apparently) random, and therefore, results subject to systematic error alone do not vary about a true value. Systematic error can result from deliberate judgment to exclude (or include) data, parameters, or models that ought not to be excluded (or included).
** "The only way to deal with systematic error is to recognize a bias in the process, model, or procedure and remove it. Systematic error, however, is notoriously difficult to recognize except on theoretical grounds. Corrections may only be applied when the magnitude and direction of the bias are known. Such corrections underlie the application of double-sampling methods in environmental science." (Regan, et. al., op. cit.)
*'''Natural variation''' - [https://en.wikipedia.org/wiki/Natural_process_variation Natural variation] or underlying process variation occurs in systems that "...change (concerning time, space, or other variables) in ways that are difficult to predict...across the full range of temporal and spatial values (or other related variables)." '''note-28 [22]'''
** This form of uncertainty is reduceable utilizing tools such as [https://en.wikipedia.org/wiki/Statistical_process_control statistical process control] and replication of experiments or observations.
*'''Inherent randomness''' - [https://en.wikipedia.org/wiki/Randomness randomness] or [https://en.wikipedia.org/wiki/Uncertainty_quantification#Aleatoric_and_epistemic_uncertainty aleatory uncertainty] exists because the system is"...in principle, irreducible to a deterministic one (the most well-known case is described by [https://en.wikipedia.org/wiki/Uncertainty_principle Heisenberg’s uncertainty principle] in quantum mechanics)." '''note-29 [23], note-30 [Note 7]'''
** Even if the argument is accepted that it is unlikely that any given physical system at some level is inherently random, it is important for any taxonomy to distinguish between systems that appear random due to incomplete or inconsistent information and those that are intrinsically random. (Again, see Regan (2002)).
*'''Model uncertainty''' - [https://web.archive.org/web/20170227055023/http://en.wikipedia.org/wiki/Scientific_modelling Model uncertainty] occurs in the process of generating a model as a conceptual representation of a particular phenomenon to create a [https://web.archive.org/web/20170227055023/http://en.wikipedia.org/wiki/Scientific_modelling#Overview simplified reflection of reality]. This selectivity of factors and variables creates uncertainty in at least three ways. (Regan (2002))
** '''Variables and processes''' that are regarded as relevant often represent a trade-off between system knowledge and assumed states and model objectives;
** '''Models''' depict observed processes using logical or mathematical constructs based on underlying theories about system states or dynamics using continuous equations to describe discrete processes.
** '''Curve fitting''' (including interpolation and extrapolation) with mathematical expressions using model variables where inputs are discrete data points.
** Regan (2002) argues that '''model uncertainty''' is "...notoriously difficult to quantify and impossible to eliminate ...(and)...(t)he only reliable way of determining how appropriate a model is for prediction is to perform validation studies."
** Subjective judgment occurs due to the interpretation of scarce or error-prone data.
*** The only way to address this type of uncertainty is to "...assign a degree of belief about an event in the form of a subjective probability." (Regan (2002))
*Linguistic uncertainty - Linguistic uncertainty, or "vagueness", is a source of uncertainty and includes uncertainties due to context dependence, ambiguity, and under-specificity. '''note-31 [24]], note-32 [25]]'''
** '''Context dependence''' is uncertainty concerning the context in which a statement is to be understood;
** '''Ambiguity''' occurs when words have multiple meanings, and further reduction to a single meaning is not logically possible in a given context.
** '''Underspecificity''' occurs in the presence of "unwanted generality" or multiple interpretations, and reduction to a smaller set or even a single interpretation is not logically possible.
*Stochastic or statistical uncertainty - Stochastic or statistical uncertainty, which is sometimes known as [https://en.wikipedia.org/wiki/Uncertainty_quantification#Aleatoric_and_epistemic_uncertainty Aleatoric uncertainty] as well as the subject of [https://en.wikipedia.org/wiki/Stochastic_control stochastic control] pertains to the parameters of a risk model, originates from sampling or measurement error, and can be quantified and mathematically expressed (e.g., using confidence intervals).
[[#top|Top of current page]]

== Uncertainty Taxonomies in a Legal Environment ==
From a legal perspective, a definition of taxonomy is dictionary-based, such as "the systematic distinguishing, ordering, and naming of type groups within a subject field." given by Walker (op. cit.). Such legal concepts of scientific or engineering taxonomies are not required to be epistemically complete. Still, they must cover "the most significant aspects of ...(current, good discipline practices) ... and of the descriptive information commonly encountered by decision-makers" in a logically distinct manner. (Walker, 1991, p. 571) These taxonomies must be sufficient to catalog the types of uncertainty associated with descriptive assertion, including the critical subset of cause and effect assertions. This legal/decision-maker framework has presented descriptive uncertainty as having six components (Walker, 1991). Although not part of the Walker taxonomy, underlying the scheme is linguistic uncertainty, or "vagueness," as a source of uncertainty, including uncertainties due to context dependence, ambiguity, and under-specificity. '''note-33 [26]]''' Arguably, these uncertainties underlie the most basic element in the taxonomy.
* '''Linguistic '''- or "vagueness", is a source of uncertainty and includes uncertainties due to context dependence, ambiguity, and under-specificity. (Regan, 2002)
* '''Conceptual'''- the definition by choice and design of descriptive concepts or variables to be used as [https://en.wikipedia.org/wiki/Predicate_(grammar) predicates] where the subject of an assertion identifies what is being discussed and the predicate provides information about the topic or characterizations such as what the subject is, what the subject is doing, or what the subject is like (Wikipedia).
* "Conceptual uncertainty, or the potential for conceptual error, arises whenever predication occurs. Whenever a concept is used to describe something, using certain concepts instead of others begins to structure how we understand the object, event, or instance under discussion. Predication or conceptualization generates useful information about things, but it also can inhibit our ability to think about those things with concepts other than those selected. The concepts used may not be the most fruitful or the best designed- either for scientific purposes or for making wise, fair, effective, and efficient decisions." (Edited for reading, Walker, 1991)
* Similarly, choice and design of descriptive variables enhance and restrict data set membership, creating potentially incomplete, incompatible, or inconsistent data sets, "...the classification categories employed, and the relationships among those categories (nominal, ordinal or scalar)." '''note-34 [27]]'''
* Concept uncertainty '''note-35 [28]''' like systematic error discussed above is notoriously difficult to recognize, except on theoretical grounds, and the magnitude and direction of the bias are known.
Both terms could be analogized to that of [https://en.wikipedia.org/wiki/Accuracy_and_precision#Terminology_of_ISO_5725 accuracy] in [https://www.bipm.org/en/publications/guides/ ISO 5725] which looks at the ability of the concept or system's ability to produce results that are proximate to the "true" value or state of the phenomenon. Conceptual uncertainty and systemic bias are related to another measure of uncertainty: validity. Walker has defined validity as the ability of a concept to quantitatively describe and explain what the phenomenon objective "truly" is. Walker also ties the concepts together when he states, "Validity concerns the "accuracy" of the measurement data, not its precision." (Walker, 1998) <br>
Additionally, conceptual uncertainty and associated validity issues could be propagated throughout this taxonomy. Every component of action and decision in the face of uncertainty raises validity issues. Walker recognized this when the author defined epistemic choice for concepts used throughout the other uncertainty components or layers.
* '''Measurement''' uncertainty or Misclassification error- the application of the underlying concepts or variables to specific, individual cases and the uncertainty of the reliability (Walker, 1998) of the resultant data. (It is important to remember that assessment observation and measurement are used interchangeably in this analysis.) Thus, an assessment method or procedure is considered "reliable" or "precise" in the scientific terms of ISO 5715 if it repeatedly produces consistent results.
* Measurement uncertainty is logically distinct from conceptual uncertainty, which can only occur after any conceptual uncertainty has been established. Still, misclassification can occur even when the conceptual uncertainty has been minimized. Conversely, underlying errors or errors made in measurement or classification propagate thru the reasoning chain and reduce the quality or value of the final result.
* While uncertainties associated with quantitative measurements or assessments can be statistically evaluated and described, uncertainties related to qualitative assessments are more problematic.
**Working through the taxonomic chain from base concept to causal explanation requires amassing and integrating qualitative information and quantitative data into input parameters for mathematical models. Developing procedures for producing consistent, repeatable sets of information from assessments that minimize conceptual error or systemic bias requires professional efforts to "validate" such methods, models, and judgments at all layers in the process. Validation as a process is something that civil engineering as a practice needs to embrace more frequently.
* '''[https://en.wikipedia.org/wiki/Sampling Sampling]'''- in the classical statistics sense, is the selection of a limited subset of a larger population to use as a basis for making estimates about the population in the form of attributes, proprieties, or parameters. The resulting information would be determinative in making forecasts about future population sampling or possessing a desired amount of predictive power. The uncertainty about the ability of this information to correctly predict future samples is termed sampling error.
* '''Modeling'''- Modeling uncertainty arises whenever a claim is made that out of a class of candidate relationships and variable pairings, one variable pairing inclusive of constants is chosen that possesses a particular or persistent mathematical relationship to another variable X. Modeling errors arise in selecting the wrong variable pair and constants or by incorrectly specifying its constants. (Walker, 1991, pg. 599)
** '''Causal'''- In causal modeling and analysis, the relationship between causal variables is not strictly a mathematical function. Still, it makes testable predictions and explains "...how a system of variables works, why a system works the way it does, or why it makes sense to think of certain variables as a system" at all." (Walker, 1991, pg. 609)
** '''Epistemic'''- the choice of interpretations for fundamental, logical concepts used throughout the other components or layers.
The components of this uncertainty taxonomy can combine in different ways to "...produce different aggregate uncertainties." '''note-36 [29]'''
:''' Only the scientific and engineering professions possess the capacity to develop and validate procedures and models that combine the different kinds of qualitative '''note-37 [30]''' and quantitative information and their associated potential for error into an aggregate measure or "scalar variables" of uncertainty.'''note-38 [31]]
Scalar variables are quantitative variables whose categories are related by some measure of the relevant property's incremental frequency, degree, or amount. (Walker, 1991) Examples are Modulus of Elasticity, Compression stress in elastic materials, etc.

[[#top|Top of current page]]

=== Economics Uncertainty Taxonomies ===
Like scientific concepts of uncertainty, economics is environment-specific (in this case, read sector of economy or markets), phenomenon-oriented (in this case, read human activity and manufactured phenomena such as firms and markets guided by human judgment and decision), and model-centric.
:''' Economics is not interested in all forms of uncertainty, only specific, meaningful subsets possessing casual connections with material impacts, often labeled as 'risks'.'''
One of its earlier writers ([https://en.wikipedia.org/wiki/Frank_Knight#Life_and_career Knight], 1921, 1948, 1957) attempted to define "uncertainty" as the presence of "defects of managerial knowledge" (or [https://en.wikipedia.org/wiki/Knightian_uncertainty knightian uncertainty] and thus risk centric) as risk that is immeasurable, not possible to calculate.(Wikipedia) Risk in this sense was defined as "the ordinary risks of business activity which can ... be reduced... by applying the insurance principle." Knight does acknowledge that risk is a specific and unambiguous subset of uncertainty. (Risk, Uncertainty and Profit, 1957, pg. 19) For Knight, measuring uncertainty meant measuring the probability of its occurrence and the severity of its consequences or economic impact, e.g., measurable risk of loss versus unmeasurable uncertainty consequences, which Knight referred to as "the imperfection of knowledge". (Risk, Uncertainty and Profit, 1957, pg. 197) One of Knight's many contributions to this analysis was recognizing information and knowledge's role in economic activity.
:"''(W)e are concerned only to emphasize the fact that '''knowledge is in a sense variable in degree and that the practical problem may relate to the degree of knowledge rather than to its presence or absence in toto.''' We live only by knowing something about the future, while the problems of life, or conduct at least, arise from knowing so little. This is as true of business as of other spheres of activity. The situation's essence is action according to opinion, of greater or less foundation and value, neither entire ignorance nor complete and perfect information, but partial knowledge. If we are to understand the workings of the economic system, we must examine the meaning and significance of uncertainty; and to this end, some inquiry into the nature and function of knowledge itself is necessary.''" (Knight, pg. 199) Emphasis added
Knight also reinforced the difficulties in classifying uncertainties when he analyzed life insurance. In this case, accidental death was an uncertain phenomenon compared to sickness and accident, where an "...objective description and classification of cases was impossible..." (Knight, pg. 248) Another factor that made uncertainties ineligible as risks and, therefore, uninsurable because they were unclassifiable was the exercise of judgment in making decisions by the businessman. (Knight, pg. 251)
This is a simple classification of economic uncertainty and, as an idealization, is philosophically controversial. '''note-39 [32]'''
* Uncertainty and information about the economic environment are distinct from uncertainty about others’ behavior or choices.
* Risk as a specific subset of uncertainty implies that "...all possible acts are known, all possible outcomes arising from each act are known, and it is possible to assign probabilities to each act." '''note-40 [33]'''
Like the economic [https://en.wikipedia.org/wiki/Theory_of_the_firm theory of the firm], an economic theory of uncertainty seeks to explain and predict the nature of a specific subset of uncertainty (in this case, risk relating to physical phenomena and human activity), including its behavior, structure, and relationship to the universal uncertainty of physical phenomena. In this sense, uncertainty, like firms and markets, can establish price equilibriums under the right circumstances different from those that might have occurred in either of the other two. Such a theory of uncertainty offers a partitioning scheme that decomposes uncertainty into distinct and meaningful subsets, of which risk is a significant one. It also explains how the presence and variability of knowledge cause or " drive" economic consequences. Unlike physical phenomena, economic activity creates artificial objects such as products, firms, mediums of exchange, markets, economies, and knowledge about those activities. The economics of uncertainty exists as an alternative to "certainty" models that assume away imperfect knowledge and unknown choice/judgment preferences when it is more efficient for economic decision-making. This also allows the introduction of the logical concept of "hazard" versus "risk". Frank used hazard extensively in Risk, Uncertainty, and Profit, but not to the extent that one could say it was interchangeable. An example of this is in the term "[https://en.wikipedia.org/wiki/Moral_hazard Moral hazard]," where a firm could engage in "riskier" and potentially "uninsurable" behavior if the information were transparent, and, therefore, insurance coverage of losses is limited. note-41 [34]], note-42 [35]]

[[#top|Top of current page]]

=== Uncertainty and Risk in Policy and Regulatory Environment ===
:''"Hume's 'just reasoner', when faced with a difficult public policy decision in current times, would probably commission a risk analysis. But how could they incorporate 'a degree of doubt, caution, and modesty?"'' '''note-43 [36]'''
The problem of "decision-making in the face of uncertainty" is how to regulate based on incomplete information that has the potential to be materially inaccurate. A contextual assumption is that we need to evaluate decision rules for dealing with uncertainty. As a social enterprise, risk regulation, whatever its substantive objectives, should be as '''effective, efficient, and equitable''' as practically possible. These "three E's" form a set of "process objectives" or "meta-goals." From the uncertainty standpoint, causal information can be usefully divided into two major categories: information about groups and information about individuals.

Each category, group, and individual has its distinctive types of inherent uncertainty. These are logically distinct, generally independent, and cumulative, contributing to '''(?????)'''

[[#top|Top of current page]]
=== Engineering Uncertainty Taxonomies ===
Like scientific and economic concepts of uncertainty, engineering is environment-specific, phenomena-oriented, model-centric, external choice, and driven by decision-making in the face of uncertainty. Like economics and unlike science, engineering is not interested in all forms of uncertainty, only those with determinable and material consequences. Like economics, engineering conceives risk as a specific and unambiguous subset of uncertainty determined by measuring the probability of its occurrence and the severity of its consequences or economic impact, e.g., measurable risk of loss versus unmeasurable uncertainty consequences. Also, engineering recognizes the role information and, by extension, knowledge plays in constructing the built environment.
'''note-44 [37]]''' Like economics, engineering differs from economics and scientific uncertainty in its interest in behavioral uncertainty.
*"Behavioral or interaction uncertainty is how individuals or organizations act or interact. Behavioral uncertainty arises from four sources: design uncertainty, requirement uncertainty, volitional uncertainty, and human errors." '''note-45 [38]]'''
** A design uncertainty is a choice among alternatives over which an individual or group of individuals exercises direct control but has not yet decided upon.
** Requirement uncertainty includes parameters of interest to and determined by the stakeholder, independent of the engineer or designer.
** Volitional uncertainty is uncertainty about what the subject him/herself will decide. Other people’s future actions and conduct are not entirely predictable, particularly when dealing with other organizations.
** Human errors occur during the development of a system or project due to blunders or mistakes by an individual or individuals.

[[#top|Top of current page]]

==Practice Frameworks for Uncertainty and Risk in Civil Engineering Practice==
===PMIBoK===
PMI does not define uncertainty, but the PMI Body of Knowledge uses the term in 45 places (uncertainty) and as describing properties in 8 places (uncertainties). [See Note 8] PMI does define "risk" and uses the term over 1,300 times in the same document. In its glossary, PMI also defines terms such as "threat" and "opportunity" but not events.[391 The BoK contextually defines uncertainty when it states that project risk has its origins in the uncertainty present in all projects. (Op. Cit., pg 309) <br>
'''Uncertainty''' is contextually defined and taken as having the property of affecting project execution and the ability to meet stakeholder expectations. Uncertainty is more than the sum of all individual risks (known and unknown). The nature of this uncertainty is not defined, only its capacity to affect something else or its properties.<br>
'''Risk''' is defined as " ... an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives." (Ibid.) Beyond this formal definition, PMI adds context when, in its risk management section (Sec. 11 ), the BoK states that risk is a caused event or condition with multiple causes and impacts. The BoK even offers specific techniques for mapping cause-and-effect relationships and influence diagrams. (Sec. 11.2.2.5) Not as evident but equally important is the recognition that not only is risk caused but the impact is "triggered". The risk trigger is an event or situation that signals that it is about to occur (Glossary, pg. 566). Risk conditions are factors that affect or otherwise contribute to risk, such as project stakeholders. Risk implicitly retains some residual element of probability in it, or a value of less than 1.0 with risk that approaches a level of near certainty is termed "issues" or "realized risk" .(Op. Cit., pg 309). PMI also links risk to underlying variations in project outcomes. (Ibid.) Risk is based upon data and information which can be assessed as to its quality (Sec. 11.3.2.3). This analysis looks to determine the value of the information and examines the degree to which the risk information is understood as well as its " ... accuracy, quality, reliability and integrity ... " (Ibid.) Part of that is understanding the relationship between occurrence and impact as outlined in PMl's Figure 11-10 Risk Impact Matrix and developing a model for prioritizing risk products and setting the threshold for action.
====Commentary:====
For defining and identifying risk, PMI notes in Sec. 11.2.2.4 that " ... Every project and its plan is conceived and developed based on a set of hypotheses, scenarios, or assumptions." Part of the risk analysis process is identifying risks to the project, such as inaccuracy, instability, inconsistency, or incompleteness of assumptions. Similarly, the quality of management plans, as well as their consistency with others and the project objectives and assumptions are 11 •• .indicators of risk in the project." (Sec. 11.2.2.1) <br>
Similarly, the role of engineering economics in risk is embedded or implied in the PMI definition of risk when the BoK discusses risk identification as a process of assessing which risks out of the total risk exposure for the project "may affect" the project and distilling their characteristics. Embedded in this statement is the concept that not all risks can cause economic impacts (positive and negative) to the project. Also embedded is the requirement to understand risk characteristics to identify project risk (Cost and schedule). Lastly, risk identification is an iterative process of incrementing project risk documentation, much like project scope, cost, and schedule documentation. <br>
Lastly, PMI acknowledges the complex constitution of risk aggregates or the "sum" of all risks in its material, but is it a sum? Risk information has descriptive and explanatory content. These are knowledge and meta-knowledge components. Understanding project assumptions is project-specific knowledge, but identifying risks from assumption inaccuracy, instability, inconsistency, or incompleteness requires professional or program meta-knowledge. <br>
'''Uncertainty exists in all projects, but risk, a subset of uncertainty with material economic impacts, is a key meta-knowledge element for civil engineering practice.'''
===Software Development Process- Risk Focused===
The Unified Process requires the project team to focus on addressing the most critical risks early in the project life
cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected to ensure that the greatest risks are addressed first. <ref> Booch, Grady, Ivar Jacobson, and James Rumbaugh. "The unified software development process."
Reading: Addison Wesley (1999).</ref>
===American Society of Civil Engineers (ASCE)===
ASCE does not define uncertainty, but the ASCE CE Body of Knowledge (CEBoK) uses the term in 22 places (uncertainty) and describes properties in 13 places (uncertainties). <br>
The CEBoK does not use the phrase "uncertainty and risk" as PMI and AACE do in their publication. ASCE reverses the two (Risk and uncertainty) in twelve places regarding technical outcomes (Outcome 12). A fundamental difference between PMI and ISO is that risk is considered a subset of uncertainty. ASCE does not define "risk" but uses the term 25 times in the same document. Almost all are in the context of variation of design parameters and not in the classical context of cost, schedule uncertainty, and risk.
====Commentary:====
...
=== American Association of Cost Engineers (AACE) ===
AACE defined uncertainty, risk, and other related terms in its Risk Management Dictionary. <ref>Risk Management Committee uRisk Management Dictionary, Cost Engineering Vol. 37/No. 10, OCTOBER 1995. </ref>
AACE's overall strategy was to define risk and other terms that stem from base uncertainty. AACE first defined uncertainty as .... "(t)he total range of events that may happen and produce risks (including both threats and opportunities) affecting a project (see opportunities, events, conditions, risk, and threats" where the following sub-definitions apply:
** Biases--A lack of objectivity based on the individual's position or perspective. Systematic and predictable relationships between a person's opinion or statement and his/her underlying knowledge or circumstances. Note: there may be "system biases" as well as "individual biases."
** Condition (Uncertain Condition)-Any specific identifiable circumstance (such as the rate of inflation or the quality of labor available) that might affect the outcome of the project
** Event (Uncertain Condition)-is a specific identifiable action (such as a large government project being started in the same labor area as your project) or an act of nature that might happen and that (if it does happen) could affect the outcome of the project.
** Opportunities are Uncertain events that could improve the results or improve the probability that the desired outcome will happen
** Threats are Uncertain events that are potentially negative or reduce the probability that the desired outcome will happen.
*** AACE defines Risk as an "ambiguous term" (sic) that is synonymous with uncertainty or a negative subset such as "threats", or an overall negative impact of all possible uncertainties.
====Commentary:====
...

==Limitations of the definition==
...
==Working definition==
...
==Beneficial outcomes==
...
==See also==
Wiki articles on the project.

[[#top|Top of current page]]
==Notes==
<references group="note" />
<li> Implicit in this definition of uncertainty as a "state of' is ... </li>
: " ... a conceptualization of uncertainty as a subjective, cognitive experience of people--a state of mind rather than a feature of the objective world. Furthermore, the defining feature of this state appears to be a lack of knowledge about some aspect of reality. Importantly, however, the concept of uncertainty also implies a subjective consciousness or awareness of one's lack of knowledge, without which one could not feel uncertain; '''uncertainty is a form of "meta-cognition" ... ( or alternatively, its main component, meta-knowledge) ... -a knowing about knowing.'''" (Han, 2011, op. cit., Emphasis added)
</ol>
<ol start="5">
<li> Cox wanted his system to satisfy the following conditions:</li>
: Divisibility and comparability- The plausibility of a statement is a real number and depends on the information we have related to the statement.
: Common sense - Plausibilities should vary sensibly with the assessment of plausibilities in the model.
: Consistency - If the plausibility of a statement can be derived in many ways, all the results must be equal.
Cox's theorem has come to be used as one of the justifications for the use of Bayesian probability theory. (For example, in Jaynes Jayne, Probability Theory: The Logic of Science, Cambridge University Press (2003). -preprint version (1996) at http://omega.albany.edu:8008/JaynesBook.html; Chapters 1 to 3 of published version at http://bayes.wustl.edu/etj/prob/book.pdf
</ol>
<ol start="6">
<li> The utility of existing taxonomies of uncertainty in civil engineering and, by extension, "risk" has been unsatisfactory for this very reason. This is particularly true in cases where the source of the uncertainty is conflicting versus incomplete information. See Regan, et. al.,"A taxonomy and treatment of uncertainty for ecology and conservation biology" (2002)
for a survey of scientific taxonomies for uncertainty.</li>
<li> Regan et al. argue that " ... genuine examples of this kind of uncertainty are hard to find. Even classic cases of random experiments like coin tosses and the throwing of dice are deterministic; it is just that we do not have enough information about the dynamic processes and initial conditions to make any sensible estimates about the outcomes. Such processes are, for all intents and purposes, inherently random, but they are not genuinely inherently random. For similar reasons, complex systems such as ecosystems and weather patterns are unlikely to be inherently random. Similarly, chaotic systems are entirely deterministic. They are unpredictable because the deterministic processes generating them and the relevant initial conditions are hard
to fully specify (see Stewart 1989, Sugihara et al. 1990)." (Regan (2002) </li>
<li> The CEBoK uses the phrase "uncertainty and risk" twice in reference to scheduling (Section 6.5,2) and cost estimating (Section 7.2,2) as well as reversing the two (Risk and Uncertainty) also in two places in discussing project life cycle (both in Section 2.4.1) </li>
</ol>

==References==
<references />

Project stakeholder

2026-01-20T17:17:05Z

Pooyan: Project stakeholder-GPT-1-20-2026

'''<big>This page is under construction ...</big>'''

; See also
: ''See also [[Project_Execution|Project Execution]], [[Project_Development|Project Development]], [[Project_Definition|Project Definition]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]], [[Project_Delivery_Methods|Project Delivery Methods]].''
: ''See also [[Program_Management_in_Civil_Engineering|Program Management in Civil Engineering]], [[Civil_Engineering_Projects|Civil Engineering Projects]], [[Project_management|Project Management]] ...''

== Basic considerations (Under construction) ==
Stakeholder theory is centric to the interests of the organization that is seeking to balance competing claims on scarce resources such as cost, time, personnel, right of way, market capacity, etc.

The advantage is that, in understanding their stakeholder environments, project managers and project management offices can more effectively manage within their network of stakeholder relationships to improve their ability to produce positive outcomes for the federally assisted project.

Stakeholders are entities that bear some form of risk as a result of having invested some form of resources (i.e. “project capital” – social, physical, human or financial), i.e. something of value to the project, or this capital is placed at risk as a result of a project’s activities.

[[#top|Top of current page]]

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

Stakeholder management requires consistent terminology and a disciplined way to represent what is known (and not known) about the people and organizations that can influence, or be influenced by, a project. In civil engineering projects, the term ''stakeholder'' is often used interchangeably with terms such as ''actor'', ''participant'', ''party'', ''customer'', ''user'', ''public'', or ''regulator''. This can create ambiguity about who has standing in decisions, who is accountable, and how risk is distributed or managed.

This section provides a staged framework for stakeholder analysis:

* '''semantic distinctions''' (what is meant by stakeholder, and how it differs from related terms);
* '''epistemic issues''' (uncertainty about interests, influence, constraints, and future actions);
* '''logical taxonomies''' (structured ways to partition and map stakeholders so the project team can act).

=== Semantic framework ===
The first semantic problem is the definition and boundary of ''stakeholder'' in the specific project context.

Key distinctions that are commonly needed in civil engineering practice include:

* '''Stakeholder''' vs. '''actor''' – A stakeholder is defined by ''interest/exposure'' to the project’s decisions and outcomes; an actor is defined by ''participation in work'' (a role that performs activities, produces deliverables, or makes approvals). Actors are often a subset of stakeholders, but not always.
* '''Stakeholder''' vs. '''participant''' – A participant is a person or entity engaged in a particular meeting, decision, or phase (sometimes representing a larger stakeholder constituency). Participants can change from phase to phase.
* '''Stakeholder''' vs. '''party''' – A party is typically a contractual or legal entity with formal rights and obligations (e.g., owner, designer, contractor). Many stakeholders are not parties (e.g., adjacent property owners, advocacy groups), but may still create binding constraints through permitting, political influence, or litigation.
* '''Individual''' vs. '''group''' stakeholders – Some stakeholders are best represented as individuals (e.g., a permit signatory), while others are best represented as stakeholder groups with internal variation (e.g., “local residents” or “road users”).
* '''Internal''' vs. '''external''' stakeholders – Internal stakeholders are within the delivery organization(s); external stakeholders are outside but can influence or be influenced by the project.

Making these distinctions explicit supports clearer assignment of responsibilities (e.g., who must be consulted vs. who must approve), and reduces category errors such as treating a stakeholder group as if it were a single decision-maker.

=== Epistemic framework ===
The epistemic dimension of stakeholder work is dominated by uncertainty about stakeholder attributes and future behavior. Common epistemic uncertainties include:

* '''Interests and values''' – What outcomes the stakeholder truly cares about, and which interests are negotiable versus non-negotiable.
* '''Influence and power''' – The stakeholder’s ability to affect scope, schedule, cost, permits, or public acceptance, including informal influence that may not appear in organizational charts.
* '''Legitimacy and standing''' – Whether and why the stakeholder’s claims will be treated as valid by decision-makers (e.g., statutory authority, property rights, community representation).
* '''Urgency and time sensitivity''' – Whether the stakeholder’s concerns can trigger near-term action (e.g., seasonal constraints, election cycles, funding windows).
* '''Position and engagement''' – Current posture (supportive, neutral, opposed) versus the desired posture, and the effort required to shift engagement.
* '''Information asymmetry and bias''' – Gaps between what the project team believes stakeholders want and what they actually want; optimistic assumptions; selective attention; and institutional or political bias.

Epistemic uncertainty is reduced through structured engagement (interviews, workshops, public meetings), documentation ([[Stakeholder_Register|stakeholder registers]], issue logs), and iterative validation (updating assumptions as new information arrives).

=== Logical framework ===
Logical frameworks translate stakeholder uncertainty into practical representations that support communication, prioritization, and action.

Common taxonomies and representations used in projects include:

* '''Power–interest grids''' (sometimes called power–influence or influence–interest matrices) to prioritize engagement strategies (e.g., “manage closely” vs. “monitor”).
* '''Influence–impact matrices''' to distinguish stakeholders who can shape decisions from those primarily affected by outcomes.
* '''Stakeholder salience''' taxonomies (e.g., power, legitimacy, urgency) to explain why certain stakeholders become dominant at particular times.
* '''Engagement assessment matrices''' (current vs. desired engagement) and communication plans aligned to project phases.
* '''Role/accountability frameworks''' (e.g., [[Glossary#Responsibility_assignment_matrix|responsibility assignment matrices]]) to connect stakeholder roles to decisions, deliverables, and approvals.

These taxonomies are not expected to be exhaustive or permanent. Stakeholder sets and stakeholder attributes evolve over the project life cycle, so the logical framework must be revisited when scope changes, new constraints emerge, or governance changes.

== Practice frameworks in stakeholder management ==
Traditional design engineering is still pursued, but it is less and less isolated by trade-offs and optimization within a discipline-limited set of purely physical variables. This is nowhere more evident than in the linkages of design variables to economic considerations. Representations of interactions of product and process variables on costs have become central to product realization in many domains.

Multi-attribute, multi-stakeholder design contexts, laced with uncertainties and rich in information, are the norm. The framing of critical design decisions across contributing disciplines is central to success in such contexts."<ref name="Decision">"2. Decision Making in Engineering Design." in ''Theoretical Foundations for Decision Making in Engineering Design''. Washington, DC: The National Academies Press, 2001, ISBN 0-309-54224-3. [http://www.nap.edu/catalog/10502.html]</ref>

== PMIBoK ==
"A stakeholder is an individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project. Stakeholders may be actively involved in the project or have interests that may be positively or negatively affected by the performance or completion of the project. Different stakeholders may have competing expectations that might create conflicts within the project.

Stakeholders may also exert influence over the project, its deliverables, and the project team in order to achieve a set of outcomes that satisfy strategic business objectives or other needs."<ref name="PMI">PMI, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th ed., Sec. 2.2.1.</ref>

PMI further emphasizes:

* "Stakeholder identification is a continuous process throughout the entire project life cycle. Identifying stakeholders, understanding their relative degree of influence on a project, and balancing their demands, needs, and expectations are critical to the success of the project. Failure to do so can lead to delays, cost increases, unexpected issues, and other negative consequences including project cancellation."<ref name="PMI" />
* "Project stakeholders and stakeholder engagement are further defined in Section 13 on Project Stakeholder Management."<ref name="PMI" />

== ISO ==

=== American Society of Civil Engineers (ASCE) ===
(Under construction.)

== Programmatic frameworks for Civil Engineering Processes ==

=== Office of Management and Budget (OMB) ===
(Under construction.)

=== Department of Defense (DOD) ===
(Under construction.)

=== Department of Energy (DOE) ===
(Under construction.)

=== Department of Transportation ===

==== Federal Aviation Administration (FAA) ====
(Under construction.)

==== Federal Transit Administration (FTA) ====
....

==== Federal Highway Administration (FHWA) ====
(Under construction.)

== Regulatory framework for Civil Engineering Processes ==
[[#top|Top of current page]]

== Legislative framework for Civil Engineering Processes ==
[[#top|Top of current page]]

== Working definition of the term ==
....

== Limitations of the definition ==
Within the ''project stakeholder'' term definition are more subcomponents such as (under construction).

== Working definition of the term (2) ==
(Under construction.)

== See also ==
Wiki article on [[wikipedia:Project_stakeholder|Project stakeholder]].

== Notes ==
(Under construction.)

== References ==
<references/>

[[Category:Definition]]

Project stakeholder

2026-01-20T15:56:44Z

Pooyan: Project stakeholde-GPT-01-20-2026

'''<big>This page is under construction ...</big>'''

; See also
: ''See also [[Project_Execution|Project Execution]], [[Project_Development|Project Development]], [[Project_Definition|Project Definition]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]], [[Project_Delivery_Methods|Project Delivery Methods]].''
: ''See also [[Program_Management_in_Civil_Engineering|Program Management in Civil Engineering]], [[Civil_Engineering_Projects|Civil Engineering Projects]], [[Project_management|Project Management]] ...''

== Basic considerations (Under construction) ==
Stakeholder theory is centric to the interests of the organization that is seeking to balance competing claims on scarce resources such as cost, time, personnel, right of way, market capacity, etc.

The advantage is that, in understanding their stakeholder environments, project managers and project management offices can more effectively manage within their network of stakeholder relationships to improve their ability to produce positive outcomes for the federally assisted project.

Stakeholders are entities that bear some form of risk as a result of having invested some form of resources (i.e. “project capital” – social, physical, human or financial), i.e. something of value to the project, or this capital is placed at risk as a result of a project’s activities.

[[#top|Top of current page]]

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

Stakeholder management requires consistent terminology and a disciplined way to represent what is known (and not known) about the people and organizations that can influence, or be influenced by, a project. In civil engineering projects, the term ''stakeholder'' is often used interchangeably with terms such as ''actor'', ''participant'', ''party'', ''customer'', ''user'', ''public'', or ''regulator''. This can create ambiguity about who has standing in decisions, who is accountable, and how risk is distributed or managed.

This section provides a staged framework for stakeholder analysis:

* '''semantic distinctions''' (what is meant by stakeholder, and how it differs from related terms);
* '''epistemic issues''' (uncertainty about interests, influence, constraints, and future actions);
* '''logical taxonomies''' (structured ways to partition and map stakeholders so the project team can act).

=== Semantic framework ===
The first semantic problem is the definition and boundary of ''stakeholder'' in the specific project context.

Key distinctions that are commonly needed in civil engineering practice include:

* '''Stakeholder''' vs. '''actor''' – A stakeholder is defined by ''interest/exposure'' to the project’s decisions and outcomes; an actor is defined by ''participation in work'' (a role that performs activities, produces deliverables, or makes approvals). Actors are often a subset of stakeholders, but not always.
* '''Stakeholder''' vs. '''participant''' – A participant is a person or entity engaged in a particular meeting, decision, or phase (sometimes representing a larger stakeholder constituency). Participants can change from phase to phase.
* '''Stakeholder''' vs. '''party''' – A party is typically a contractual or legal entity with formal rights and obligations (e.g., owner, designer, contractor). Many stakeholders are not parties (e.g., adjacent property owners, advocacy groups), but may still create binding constraints through permitting, political influence, or litigation.
* '''Individual''' vs. '''group''' stakeholders – Some stakeholders are best represented as individuals (e.g., a permit signatory), while others are best represented as stakeholder groups with internal variation (e.g., “local residents” or “road users”).
* '''Internal''' vs. '''external''' stakeholders – Internal stakeholders are within the delivery organization(s); external stakeholders are outside but can influence or be influenced by the project.

Making these distinctions explicit supports clearer assignment of responsibilities (e.g., who must be consulted vs. who must approve), and reduces category errors such as treating a stakeholder group as if it were a single decision-maker.

=== Epistemic framework ===
The epistemic dimension of stakeholder work is dominated by uncertainty about stakeholder attributes and future behavior. Common epistemic uncertainties include:

* '''Interests and values''' – What outcomes the stakeholder truly cares about, and which interests are negotiable versus non-negotiable.
* '''Influence and power''' – The stakeholder’s ability to affect scope, schedule, cost, permits, or public acceptance, including informal influence that may not appear in organizational charts.
* '''Legitimacy and standing''' – Whether and why the stakeholder’s claims will be treated as valid by decision-makers (e.g., statutory authority, property rights, community representation).
* '''Urgency and time sensitivity''' – Whether the stakeholder’s concerns can trigger near-term action (e.g., seasonal constraints, election cycles, funding windows).
* '''Position and engagement''' – Current posture (supportive, neutral, opposed) versus the desired posture, and the effort required to shift engagement.
* '''Information asymmetry and bias''' – Gaps between what the project team believes stakeholders want and what they actually want; optimistic assumptions; selective attention; and institutional or political bias.

Epistemic uncertainty is reduced through structured engagement (interviews, workshops, public meetings), documentation (stakeholder registers, issue logs), and iterative validation (updating assumptions as new information arrives).

=== Logical framework ===
Logical frameworks translate stakeholder uncertainty into practical representations that support communication, prioritization, and action.

Common taxonomies and representations used in projects include:

* '''Power–interest grids''' (sometimes called power–influence or influence–interest matrices) to prioritize engagement strategies (e.g., “manage closely” vs. “monitor”).
* '''Influence–impact matrices''' to distinguish stakeholders who can shape decisions from those primarily affected by outcomes.
* '''Stakeholder salience''' taxonomies (e.g., power, legitimacy, urgency) to explain why certain stakeholders become dominant at particular times.
* '''Engagement assessment matrices''' (current vs. desired engagement) and communication plans aligned to project phases.
* '''Role/accountability frameworks''' (e.g., responsibility assignment matrices) to connect stakeholder roles to decisions, deliverables, and approvals.

These taxonomies are not expected to be exhaustive or permanent. Stakeholder sets and stakeholder attributes evolve over the project life cycle, so the logical framework must be revisited when scope changes, new constraints emerge, or governance changes.

== Practice frameworks in stakeholder management ==
Traditional design engineering is still pursued, but it is less and less isolated by trade-offs and optimization within a discipline-limited set of purely physical variables. This is nowhere more evident than in the linkages of design variables to economic considerations. Representations of interactions of product and process variables on costs have become central to product realization in many domains.

Multi-attribute, multi-stakeholder design contexts, laced with uncertainties and rich in information, are the norm. The framing of critical design decisions across contributing disciplines is central to success in such contexts."<ref name="Decision">"2. Decision Making in Engineering Design." in ''Theoretical Foundations for Decision Making in Engineering Design''. Washington, DC: The National Academies Press, 2001, ISBN 0-309-54224-3. [http://www.nap.edu/catalog/10502.html]</ref>

== PMIBoK ==
"A stakeholder is an individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project. Stakeholders may be actively involved in the project or have interests that may be positively or negatively affected by the performance or completion of the project. Different stakeholders may have competing expectations that might create conflicts within the project.

Stakeholders may also exert influence over the project, its deliverables, and the project team in order to achieve a set of outcomes that satisfy strategic business objectives or other needs."<ref name="PMI">PMI, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th ed., Sec. 2.2.1.</ref>

PMI further emphasizes:

* "Stakeholder identification is a continuous process throughout the entire project life cycle. Identifying stakeholders, understanding their relative degree of influence on a project, and balancing their demands, needs, and expectations are critical to the success of the project. Failure to do so can lead to delays, cost increases, unexpected issues, and other negative consequences including project cancellation."<ref name="PMI" />
* "Project stakeholders and stakeholder engagement are further defined in Section 13 on Project Stakeholder Management."<ref name="PMI" />

== ISO ==

=== American Society of Civil Engineers (ASCE) ===
(Under construction.)

== Programmatic frameworks for Civil Engineering Processes ==

=== Office of Management and Budget (OMB) ===
(Under construction.)

=== Department of Defense (DOD) ===
(Under construction.)

=== Department of Energy (DOE) ===
(Under construction.)

=== Department of Transportation ===

==== Federal Aviation Administration (FAA) ====
(Under construction.)

==== Federal Transit Administration (FTA) ====
....

==== Federal Highway Administration (FHWA) ====
(Under construction.)

== Regulatory framework for Civil Engineering Processes ==
[[#top|Top of current page]]

== Legislative framework for Civil Engineering Processes ==
[[#top|Top of current page]]

== Working definition of the term ==
....

== Limitations of the definition ==
Within the ''project stakeholder'' term definition are more subcomponents such as (under construction).

== Working definition of the term (2) ==
(Under construction.)

== See also ==
Wiki article on [[wikipedia:Project_stakeholder|Project stakeholder]].

== Notes ==
(Under construction.)

== References ==
<references/>

[[Category:Definition]]

Agency Guidance Practices for Civil Engineering

2026-01-20T15:13:35Z

Pooyan: /* Practice implications */

= Agency Guidance Practices for Civil Engineering =
Many civil engineering projects are delivered in regulated environments where agencies issue ''guidance documents'' that shape design, approvals, and compliance. Understanding what guidance is (and is not) is essential for risk management.

== What is an agency guidance document? ==
Agency guidance documents can include interpretive memoranda, policy statements, guidances, manuals, circulars, memoranda, bulletins, advisories, and similar materials.

Guidance often addresses design, production/manufacturing, control, remediation, testing, analysis/assessment, and the review/approval of submissions or applications, as well as compliance guides. Guidance documents do not consist solely of scientific research summaries.

== Guidance vs. Regulation ==
* Regulations are legally binding requirements adopted through formal processes.
* Guidance documents typically clarify expectations, recommended methods, or interpretations, but may still have strong practical force in project approvals and reviews.

== Practice Implications ==
* Identify applicable guidance early in project definition.
* Track versions and updates; guidance can change during multi-year projects.
* Treat guidance interpretation as a stakeholder interface risk; document assumptions and decision rationales.

== See also ==
* [[Requirements]]
* [[Project Definition]]
* [[Uncertainty and Risk in Civil Engineering Practice]]

[[Category:Governance]]
[[Category:Civil Engineering]]

Agency Guidance Practices for Civil Engineering

2026-01-20T15:13:22Z

Pooyan: /* Guidance vs. regulation */

= Agency Guidance Practices for Civil Engineering =
Many civil engineering projects are delivered in regulated environments where agencies issue ''guidance documents'' that shape design, approvals, and compliance. Understanding what guidance is (and is not) is essential for risk management.

== What is an agency guidance document? ==
Agency guidance documents can include interpretive memoranda, policy statements, guidances, manuals, circulars, memoranda, bulletins, advisories, and similar materials.

Guidance often addresses design, production/manufacturing, control, remediation, testing, analysis/assessment, and the review/approval of submissions or applications, as well as compliance guides. Guidance documents do not consist solely of scientific research summaries.

== Guidance vs. Regulation ==
* Regulations are legally binding requirements adopted through formal processes.
* Guidance documents typically clarify expectations, recommended methods, or interpretations, but may still have strong practical force in project approvals and reviews.

== Practice implications ==
* Identify applicable guidance early in project definition.
* Track versions and updates; guidance can change during multi-year projects.
* Treat guidance interpretation as a stakeholder interface risk; document assumptions and decision rationales.

== See also ==
* [[Requirements]]
* [[Project Definition]]
* [[Uncertainty and Risk in Civil Engineering Practice]]

[[Category:Governance]]
[[Category:Civil Engineering]]

Agency Guidance Practices for Civil Engineering

2026-01-20T15:05:49Z

Pooyan: Agency Guidance Practices for Civil Engineering-GPT-01-20-2026

= Agency Guidance Practices for Civil Engineering =
Many civil engineering projects are delivered in regulated environments where agencies issue ''guidance documents'' that shape design, approvals, and compliance. Understanding what guidance is (and is not) is essential for risk management.

== What is an agency guidance document? ==
Agency guidance documents can include interpretive memoranda, policy statements, guidances, manuals, circulars, memoranda, bulletins, advisories, and similar materials.

Guidance often addresses design, production/manufacturing, control, remediation, testing, analysis/assessment, and the review/approval of submissions or applications, as well as compliance guides. Guidance documents do not consist solely of scientific research summaries.

== Guidance vs. regulation ==
* Regulations are legally binding requirements adopted through formal processes.
* Guidance documents typically clarify expectations, recommended methods, or interpretations, but may still have strong practical force in project approvals and reviews.

== Practice implications ==
* Identify applicable guidance early in project definition.
* Track versions and updates; guidance can change during multi-year projects.
* Treat guidance interpretation as a stakeholder interface risk; document assumptions and decision rationales.

== See also ==
* [[Requirements]]
* [[Project Definition]]
* [[Uncertainty and Risk in Civil Engineering Practice]]

[[Category:Governance]]
[[Category:Civil Engineering]]

Management Control

2026-01-20T15:03:54Z

Pooyan: Management Control-GPT-01-20-2026

= Management Control =
Management control is the set of feedback processes used to steer a project or organization toward its objectives. Control does not eliminate uncertainty; it detects variance early and enables corrective action.

== Cybernetic control model ==
A classic model treats control as a ''negative feedback loop'':
# set goals/standards,
# measure performance,
# compare performance to goals,
# identify variances and causes,
# take corrective action and adjust plans.

== Management control in civil engineering ==
Typical control domains:
* cost control (budgets, earned value, forecasting),
* schedule control (critical path, look-ahead planning, productivity),
* quality control (inspection/testing, nonconformance management),
* risk control (risk registers, triggers, response tracking),
* safety control (leading indicators, incident learning).

== Designing controls ==
Effective controls are:
* timely (information arrives early enough to act),
* reliable (data quality is understood),
* decision-linked (connected to authority and action),
* proportional (control effort matches consequence).

== See also ==
* [[Management Plans and Sub-Plans]]
* [[Civil Engineering Processes]]
* [[Civil Engineering Projects]]

[[Category:Project Management]]

Management Plans and Sub-Plans

2026-01-20T15:02:57Z

Pooyan: Management Plans and Sub-Plans-GPT-01-20-2026

= Management Plans and Sub-Plans =
A management plan is a coordinated set of processes, procedures, roles, and controls used to manage a project or program. Sub-plans are specialized plans that address specific management domains (e.g., quality, risk, safety).

== Process orientation ==
Because projects are executed through processes, management planning often begins by identifying critical process ''state variables'' (what must be true/known/controlled at each stage) and how those variables will be identified, documented, and communicated at appropriate times.

== Typical sub-plans ==
Common sub-plans include:
* scope management plan,
* schedule management plan,
* cost management plan,
* risk management plan,
* quality management plan,
* safety and health plan,
* environmental management plan,
* communications plan,
* procurement and contracting plan,
* stakeholder engagement plan,
* configuration/change management plan.

== Integration ==
Sub-plans must be consistent (e.g., risk responses must be reflected in schedule and cost baselines). The overall project/program management plan is the integrating document.

== See also ==
* [[Management Control]]
* [[Civil Engineering Processes]]
* [[Project Life Cycle and Phase Models]]

[[Category:Project Management]]

Program Management in Civil Engineering

2026-01-20T15:02:07Z

Pooyan: Program Management in Civil Engineering-GPT-01-20-2026

= Program Management in Civil Engineering =
Program management coordinates multiple related projects and other work to achieve benefits and strategic objectives that cannot be realized by managing projects independently.

== Program vs. project ==
* Project management focuses on delivering a specific scope within time/cost/performance constraints.
* Program management focuses on benefits, integration, governance, and strategic alignment across multiple projects.

Program management becomes increasingly relevant as projects become more complex and interdependent and as owners pursue program-level outcomes (e.g., corridor delivery, capital renewal, system modernization).

== Core functions ==
* benefits management and value realization,
* governance and decision rights,
* interface and dependency management,
* standards, templates, and controls across projects,
* resource and prioritization management,
* stakeholder and communications integration.

== Program life cycle ==
Programs typically proceed through:
# program formulation (business case, objectives, governance),
# program planning (roadmap, sequencing, funding),
# program delivery (coordinating projects and dependencies),
# transition and sustainment (handover, operations integration, benefits tracking).

== See also ==
* [[Civil Engineering Projects]]
* [[Management Control]]
* [[Management Plans and Sub-Plans]]

[[Category:Program Management]]
[[Category:Project Management]]

Requirements

2026-01-20T15:00:43Z

Pooyan: Requirements-GPT-1-20-2026

= Requirements =
Requirements define what a civil engineering project must achieve and the constraints within which it must be delivered. They translate stakeholder needs, regulatory obligations, and technical performance targets into testable statements.

== Working definition ==
;Requirement
: a statement of need, capability, or constraint that a project, system, or component must satisfy.

== Requirements in civil engineering ==
Common requirement classes include:
* Functional requirements (what the facility/system must do)
* Performance requirements (capacity, reliability, serviceability, durability)
* Interface requirements (connections to adjacent systems and utilities)
* Constraints (codes, standards, permits, right-of-way, budget)
* Verification and acceptance requirements (tests, inspections, documentation)

== Requirements development and management ==
A practical pattern is iterative and incremental: requirements are elicited and refined as knowledge improves, while maintaining traceability and change control.

Key practices:
* elicit and document requirements early,
* decompose into subsystem/component requirements,
* maintain a requirements baseline and change process,
* verify and validate through tests, inspections, and reviews.

== Requirements and risk ==
Requirement ambiguity, conflict, or late change is a major source of project risk. Requirements management reduces uncertainty by making assumptions explicit and by bounding decision space.

== See also ==
* [[Project Definition]]
* [[Uncertainty and Risk in Civil Engineering Practice]]
* [[Management Plans and Sub-Plans]]

[[Category:Project Management]]

Civil Engineering Projects

2026-01-20T14:57:37Z

Pooyan: Civil Engineering Projects-GPT-1-20-2026

= Civil Engineering Projects =
A civil engineering project is a time-bounded endeavor undertaken to create or modify a built asset (facility, structure, network, or system) and to deliver outcomes (capacity, service, safety) for an owner and stakeholders.

== Definition of a project ==
A widely used definition is:

;Project
: a temporary endeavor undertaken to create a unique product, service, or result.

Civil engineering projects are typically constrained by scope, time, resources, and performance requirements, and are managed through planning, execution, and control.

== Projects, programs, and operations ==
* Projects are temporary and produce a unique outcome.
* Programs coordinate multiple related projects to achieve strategic benefits.
* Operations are ongoing activities that sustain an organization or asset.

== Typical project structure ==
* front-end development (definition and feasibility),
* design (concept to final),
* procurement and contracting,
* construction and commissioning,
* handover and closeout,
* operations interface (performance, maintenance, renewal).

== See also ==
* [[Program Management in Civil Engineering]]
* [[Project Life Cycle and Phase Models]]
* [[Requirements]]
* [[Uncertainty and Risk in Civil Engineering Practice]]

[[Category:Civil Engineering]]
[[Category:Project Management]]

Civil Engineering Processes

2026-01-20T14:56:30Z

Pooyan: Civil Engineering Processes-GPT Update 1-20-2026

= Civil Engineering Processes =
A civil engineering ''process'' is an ordered pattern of work and decisions that transforms inputs (information, materials, resources) into outputs (designs, built assets, approvals, operational performance).

== Process concept model vs process approach model ==
Two complementary views are useful:

;Process concept model
: a model of a process ''without respect to execution'', used to describe and communicate civil engineering knowledge.

;Process approach model
: a model of a process ''with respect to execution'', used to describe work, controls, and communication needs.

== Why process models matter ==
Process models support:
* coordination among stakeholders and disciplines,
* repeatability and learning,
* identification of where uncertainty enters and where control is most effective,
* clearer definition of responsibilities and interfaces.

== Families of processes ==
Common families include:
* Technical processes: investigation, analysis, design, verification, construction methods, commissioning.
* Management processes: planning, scheduling, budgeting, risk management, quality management, procurement, communications.
* Governance processes: permitting, regulatory review, public engagement, dispute resolution.

== See also ==
* [[Management Plans and Sub-Plans]]
* [[Management Control]]
* [[Project Life Cycle and Phase Models]]

[[Category:Civil Engineering]]
[[Category:Project Management]]

Civil engineering

2026-01-20T14:55:16Z

Pooyan: Created page with "= Civil Engineering = Civil engineering is the engineering discipline concerned with the planning, design, construction, operation, and stewardship of the built environment and the natural systems it interacts with. In modern practice, civil engineering is tightly coupled to public policy: infrastructure choices embed long-lived trade-offs among safety, cost, equity, resilience, and environmental performance. == Scope == Civil engineering work spans: * buildings and st..."

= Civil Engineering =
Civil engineering is the engineering discipline concerned with the planning, design, construction, operation, and stewardship of the built environment and the natural systems it interacts with.

In modern practice, civil engineering is tightly coupled to public policy: infrastructure choices embed long-lived trade-offs among safety, cost, equity, resilience, and environmental performance.

== Scope ==
Civil engineering work spans:
* buildings and structures,
* transportation systems,
* water resources and environmental systems,
* geotechnical and earthworks,
* construction methods and management,
* operations, maintenance, and renewal.

== Professional orientation ==
Civil engineering decisions often occur in public or quasi-public contexts and therefore require not only technical competence, but also leadership, ethical responsibility, and clear communication with stakeholders.

== Risk engineering perspective ==
Because civil engineering decisions are made under uncertainty, risk engineering provides frameworks for:
* identifying hazards and structuring risks,
* bounding uncertainty for decision-making,
* designing controls and feedback systems for cost, schedule, performance, and safety.

== See also ==
* [[Civil Engineering Processes]]
* [[Civil Engineering Projects]]
* [[Project Life Cycle and Phase Models]]
* [[Uncertainty and Risk in Civil Engineering Practice]]

[[Category:Civil Engineering]]

Project management

2026-01-19T23:06:11Z

Pooyan:

{{DISPLAYTITLE:Project Management}}
'''<big>This page is under construction ...</big>'''

''See also [[Project Execution]], [[Project Development]], [[Project Definition]], [[Project Delivery Methods]], [[Project Life Cycle and Phase Models]].''
''See also [[Program Management in Civil Engineering]], [[Civil Engineering Projects]], [[Management control]], [[Management plans and sub-plans]].''

{{ProjectDeliverySpine}}

== Basic considerations ==
Project management is the disciplined application of knowledge, methods, tools, and controls to project activities in order to produce defined deliverables and outcomes under constraint.

For RiskWiki, project management in civil engineering is inseparable from:
* managing uncertainty and risk,
* maintaining integrity of design and requirements through delivery,
* and operating within contractual, regulatory, and stakeholder environments.

[[#top|Top of current page]]

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

=== Semantic framework ===
Common confusions that cause failures in practice:
* “project management” vs “project controls” vs “governance”
* requirements vs scope vs specifications
* planning vs development vs execution
* commercial scope splits vs legal responsibility (e.g., engineer-of-record obligations)

=== Epistemic framework ===
Project management exists because uncertainty cannot be eliminated before commitment.
A core task is to identify which uncertainties must be reduced (retired) and which will be carried as managed risks.

=== Logical framework ===
A practical framing:
1. Define objectives, requirements, and constraints (definition).
2. Develop feasible designs, interfaces, packages, and baselines (development).
3. Execute work under integrated control systems (execution).
4. Verify and achieve acceptance/turnover (startup/commissioning).

[[#top|Top of current page]]

== Practice frameworks ==
(Under construction.)

This page should summarize and link to:
* PMI / ISO / ASCE practice concepts (definitions, process groups, knowledge areas)
* civil-engineering project controls (scope, schedule, cost, risk, quality, configuration)
* agency programmatic requirements (FTA, FRA, DOE, USACE, etc.)

[[#top|Top of current page]]

== Interfaces to risk management ==
Project management provides the control architecture that makes risk management real:
* governance and decision rights (“who defines acceptable?”)
* change control (scope/spec/design changes)
* risk identification, response planning, and risk funding (contingency / reserves)
* stakeholder and interface management

[[#top|Top of current page]]

== Working definition of the term ==
Project management
:Project management is the integrated set of leadership and control activities used to plan, coordinate, and govern project definition, development, and execution so that required outcomes are achieved within constraints.

[[#top|Top of current page]]

== See also ==
* [[Project Definition]]
* [[Project Development]]
* [[Project Execution]]
* [[Project Delivery Methods]]
* [[Project Life Cycle and Phase Models]]
* [[Civil Engineering Projects]]
* [[Program Management in Civil Engineering]]
* [[Management control]]
* [[Management plans and sub-plans]]
* [[Project stakeholder]]

== Recommended reading path ==
# [[Uncertainty and Risk in Civil Engineering Practice]]
# [[Project Life Cycle and Phase Models]]
# [[Project Definition]]
# [[Project Development]]
# [[Project Execution]]
# [[Project Delivery Methods]]

== Common failure modes in civil engineering projects ==
* Requirements vs specifications confusion
* Interface ambiguity (packages, EOR obligations, scope splits)
* Feasibility not maintained across handoffs (conceptual → detailed → field)
* Poor communication / ambiguity in roles and codes

== Notes ==
(Under construction.)

== References ==
(Under construction.)

[[Category:Definition]]

Template:ProjectDeliverySpine

2026-01-19T22:43:08Z

Pooyan:

<includeonly>
<div style="border:1px solid #a2a9b1; background:#f8f9fa; padding:0.6em 0.8em; margin:1em 0;">
<div style="font-weight:bold; margin-bottom:0.25em;">Project delivery spine</div>
<div>[[Project Definition]] • [[Project Development]] • [[Project Execution]] • [[Project Delivery Methods]]</div>
<div style="margin-top:0.35em;">[[Project Life Cycle and Phase Models]] • [[Uncertainty and Risk in Civil Engineering Practice]] • [[Project stakeholder]] • [[Project management]]</div>
</div>
</includeonly>

<noinclude>
=== Usage ===
Add this on any page where you want the navigation box:

<nowiki>{{ProjectDeliverySpine}}</nowiki>

[[Category:Templates]]
</noinclude>

Template:ProjectDeliverySpine

2026-01-19T22:23:21Z

Pooyan: Created page with "<includeonly> <div style="border:1px solid #a2a9b1; background:#f8f9fa; padding:0.6em 0.8em; margin:1em 0;"> <div style="font-weight:bold; margin-bottom:0.25em;">Project delivery spine</div> <div> Project Definition  •  Project Development  •  Project Execution  •  Project Delivery Methods </div> <div style="margin-top:0.35em;"> Project Life Cycle and Phase Models  •  ..."

<includeonly>
<div style="border:1px solid #a2a9b1; background:#f8f9fa; padding:0.6em 0.8em; margin:1em 0;">
<div style="font-weight:bold; margin-bottom:0.25em;">Project delivery spine</div>

<div>
[[Project Definition]]  • 
[[Project Development]]  • 
[[Project Execution]]  • 
[[Project Delivery Methods]]
</div>

<div style="margin-top:0.35em;">
[[Project Life Cycle and Phase Models]]  • 
[[Uncertainty and Risk in Civil Engineering Practice]]  • 
[[Project stakeholder]]  • 
[[Project management]]
</div>
</div>
</includeonly>

<noinclude>
=== Usage ===
Add this on any page where you want the navigation box:

<nowiki>{{ProjectDeliverySpine}}</nowiki>

[[Category:Templates]]
</noinclude>

Project management

2026-01-19T22:09:02Z

Pooyan: roject management

{{DISPLAYTITLE:Project Management}}
'''<big>This page is under construction ...</big>'''

''See also [[Project Execution]], [[Project Development]], [[Project Definition]], [[Project Delivery Methods]], [[Project Life Cycle and Phase Models]].''
''See also [[Program Management in Civil Engineering]], [[Civil Engineering Projects]], [[Management control]], [[Management plans and sub-plans]].''

{{ProjectDeliverySpine}}

== Basic considerations ==
Project management is the disciplined application of knowledge, methods, tools, and controls to project activities in order to produce defined deliverables and outcomes under constraint.

For RiskWiki, project management in civil engineering is inseparable from:
* managing uncertainty and risk,
* maintaining integrity of design and requirements through delivery,
* and operating within contractual, regulatory, and stakeholder environments.

[[#top|Top of current page]]

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

=== Semantic framework ===
Common confusions that cause failures in practice:
* “project management” vs “project controls” vs “governance”
* requirements vs scope vs specifications
* planning vs development vs execution
* commercial scope splits vs legal responsibility (e.g., engineer-of-record obligations)

=== Epistemic framework ===
Project management exists because uncertainty cannot be eliminated before commitment.
A core task is to identify which uncertainties must be reduced (retired) and which will be carried as managed risks.

=== Logical framework ===
A practical framing:
1. Define objectives, requirements, and constraints (definition).
2. Develop feasible designs, interfaces, packages, and baselines (development).
3. Execute work under integrated control systems (execution).
4. Verify and achieve acceptance/turnover (startup/commissioning).

[[#top|Top of current page]]

== Practice frameworks ==
(Under construction.)

This page should summarize and link to:
* PMI / ISO / ASCE practice concepts (definitions, process groups, knowledge areas)
* civil-engineering project controls (scope, schedule, cost, risk, quality, configuration)
* agency programmatic requirements (FTA, FRA, DOE, USACE, etc.)

[[#top|Top of current page]]

== Interfaces to risk management ==
Project management provides the control architecture that makes risk management real:
* governance and decision rights (“who defines acceptable?”)
* change control (scope/spec/design changes)
* risk identification, response planning, and risk funding (contingency / reserves)
* stakeholder and interface management

[[#top|Top of current page]]

== Working definition of the term ==
Project management
:Project management is the integrated set of leadership and control activities used to plan, coordinate, and govern project definition, development, and execution so that required outcomes are achieved within constraints.

[[#top|Top of current page]]

== See also ==
* [[Project Definition]]
* [[Project Development]]
* [[Project Execution]]
* [[Project Delivery Methods]]
* [[Project Life Cycle and Phase Models]]
* [[Civil Engineering Projects]]
* [[Program Management in Civil Engineering]]
* [[Management control]]
* [[Management plans and sub-plans]]
* [[Project stakeholder]]

== Notes ==
(Under construction.)

== References ==
(Under construction.)

[[Category:Definition]]

Project management

2026-01-19T22:07:36Z

Pooyan: Created page with "{{DISPLAYTITLE:Project Management}} '''<big>This page is under construction ...</big>''' ''See also Project Execution, Project Development, Project Definition, Project Delivery Methods, Project Life Cycle and Phase Models.'' ''See also Program Management in Civil Engineering, Civil Engineering Projects, Management control, Management plans and sub-plans.'' {{ProjectDeliverySpine}} == Basic considerations == Project management is the..."

{{DISPLAYTITLE:Project Management}}
'''<big>This page is under construction ...</big>'''

''See also [[Project Execution]], [[Project Development]], [[Project Definition]], [[Project Delivery Methods]], [[Project Life Cycle and Phase Models]].''
''See also [[Program Management in Civil Engineering]], [[Civil Engineering Projects]], [[Management control]], [[Management plans and sub-plans]].''

{{ProjectDeliverySpine}}

== Basic considerations ==
Project management is the disciplined application of knowledge, methods, tools, and controls to project activities in order to produce defined deliverables and outcomes under constraint.

For RiskWiki, project management in civil engineering is inseparable from:
* managing uncertainty and risk,
* maintaining integrity of design and requirements through delivery,
* and operating within contractual, regulatory, and stakeholder environments.

[[#top|Top of current page]]

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

=== Semantic framework ===
Common confusions that cause failures in practice:
* “project management” vs “project controls” vs “governance”
* requirements vs scope vs specifications
* planning vs development vs execution
* commercial scope splits vs legal responsibility (e.g., engineer-of-record obligations)

=== Epistemic framework ===
Project management exists because uncertainty cannot be eliminated before commitment.
A core task is to identify which uncertainties must be reduced (retired) and which will be carried as managed risks.

=== Logical framework ===
A practical framing:
1. Define objectives, requirements, and constraints (definition).
2. Develop feasible designs, interfaces, packages, and baselines (development).
3. Execute work under integrated control systems (execution).
4. Verify and achieve acceptance/turnover (startup/commissioning).

[[#top|Top of current page]]

== Practice frameworks ==
(Under construction.)

This page should summarize and link to:
* PMI / ISO / ASCE practice concepts (definitions, process groups, knowledge areas)
* civil-engineering project controls (scope, schedule, cost, risk, quality, configuration)
* agency programmatic requirements (FTA, FRA, DOE, USACE, etc.)

[[#top|Top of current page]]

== Interfaces to risk management ==
Project management provides the control architecture that makes risk management real:
* governance and decision rights (“who defines acceptable?”)
* change control (scope/spec/design changes)
* risk identification, response planning, and risk funding (contingency / reserves)
* stakeholder and interface management

[[#top|Top of current page]]

== Working definition of the term ==
Project management
:Project management is the integrated set of leadership and control activities used to plan, coordinate, and govern project definition, development, and execution so that required outcomes are achieved within constraints.

[[#top|Top of current page]]

== See also ==
* [[Project Definition]]
* [[Project Development]]
* [[Project Execution]]
* [[Project Delivery Methods]]
* [[Project Life Cycle and Phase Models]]
* [[Civil Engineering Projects]]
* [[Program Management in Civil Engineering]]
* [[Management control]]
* [[Management plans and sub-plans]]
* [[Project stakeholder]]

== Notes ==
(Under construction.)

== References ==
(Under construction.)

[[Category:Definition]]

Project Delivery Methods

2026-01-19T15:32:45Z

Pooyan: Project Delivery Methods

'''<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 Definition

2026-01-19T15:32:21Z

Pooyan: Project Definition

'''<big>This page is under construction ...</big>'''
''See also [[Project_Development|Project Development]], [[Project_Execution|Project Execution]], [[Project_Delivery_Methods|Project Delivery Methods]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]].''
''See also [[Program_Management_in_Civil_Engineering|Program Management in Civil Engineering]], [[Civil_Engineering_Projects|Civil Engineering Projects]], [[Project_management|Project Management]] ...''

== Basic considerations ==
In civil-engineering practice, the purpose of ''project definition'' is to transform a sponsor’s need or intent into a defensible and communicable basis for decisions. Those decisions include:
* whether to proceed (or stop),
* what outcomes are required,
* what constraints govern the work,
* what level of funding and authority is being committed, and
* what the project team is accountable for delivering.

Project definition is therefore a decision-support activity. It does not require full knowledge; it requires ''sufficient clarity'' to authorize the next phase of work while explicitly documenting what remains uncertain.

[[File:2016_10_30_Project_Development_definition_execution_model.png|thumb|400px|Project definition / development / execution model (conceptual).]]

[[#top|Top of current page]]

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

=== Semantic framework ===
Common semantic problems include:
* confusing ''project definition'' with ''project development'' and ''project execution'',
* using ''requirements'', ''scope'', and ''specification'' as interchangeable terms,
* treating “baseline” as if it were purely cost/schedule, rather than a structured commitment across scope, performance, and constraints.

Working distinctions used in RiskWiki:
* '''Project definition''' answers: ''What are we trying to achieve, for whom, under what constraints, and why is it justified?''
* '''Project development''' answers: ''How will we engineer and package a feasible solution, and what artifacts will govern delivery?''
* '''Project execution''' answers: ''How do we implement, control, integrate, verify, and deliver acceptance?''

Requirements vs specifications (working distinction):
* '''Requirements''' state ''what must be achieved'' (performance, function, constraints, acceptance).
* '''Specifications''' state ''how compliance will be demonstrated or implemented'' (materials, methods, standards, testing, tolerances, submittals).

=== Epistemic framework ===
Project definition operates under high uncertainty (often dominated by epistemic uncertainty). The objective is not to eliminate uncertainty, but to:
* identify the most decision-relevant uncertainties,
* document assumptions and their rationale,
* establish learning/validation steps (“risk burn-down” actions),
* decide which uncertainties must be retired before authorization to proceed.

Project definition should explicitly document:
* key unknowns,
* the plan for reducing unknowns,
* who owns which uncertainties (stakeholders / contracts),
* which uncertainties are being accepted (and why).

=== Logical framework ===
The logical structure of project definition is centered on decision gates (“off-ramps”):
* definition produces artifacts,
* artifacts support governance reviews,
* reviews authorize (or terminate) transition into development.

A definition is “good enough” when it supports:
* a coherent statement of purpose and outcomes,
* traceable requirements,
* a plausible concept of solution,
* a defensible cost/schedule range (not a false point estimate),
* an explicit initial risk posture and allocation.

[[#top|Top of current page]]

== Practice frameworks for Project Definition ==
(Under construction.)

Typical civil-engineering practice elements include:
* business case / sponsor justification
* alternatives analysis (including “do-nothing”)
* concept of operations / operational needs
* requirements definition (functional + performance)
* constraints definition (regulatory, right-of-way, stakeholder, constructability)
* initial delivery strategy (how the project will be delivered and by whom)

[[#top|Top of current page]]

== Core artifacts and decision outputs ==
A working “minimum set” of definition artifacts (varies by program and agency):
* Sponsor intent / mission need statement
* Stakeholder map and decision rights (who decides what)
* Functional and performance requirements
* Initial scope boundaries (what is in / out)
* Conceptual design / concept sketches or models (solution hypothesis)
* Assumptions register (including critical assumptions)
* Constraints register (regulatory, physical, environmental, institutional)
* Initial cost range and schedule range (with basis and uncertainty)
* Initial risk register (risk statements tied to requirements and constraints)
* Initial procurement / delivery-method recommendation

[[#top|Top of current page]]

== Interfaces to uncertainty and risk management ==
Project definition is where “risk to whom?” becomes operational.
Key outputs should make explicit:
* which requirements are fixed vs negotiable,
* who defines acceptability (authority having jurisdiction, owner, users),
* what “feasible” means at this stage (technical + regulatory + deliverability),
* which uncertainties are being carried forward into development,
* which uncertainties must be retired before procurement and construction.

[[#top|Top of current page]]

== Working definition of the term ==
Project definition
:Project definition is the disciplined process of establishing and documenting the project’s purpose, required outcomes, requirements, constraints, and initial solution concept at a level sufficient to support governance decisions, authorization of funding, and transition into project development.

[[#top|Top of current page]]

== Limitations of the definition ==
(Under construction.)
* The degree of definition required varies by delivery method and by regulatory environment.
* Some programs label “definition” as programming, feasibility, initiation, or conceptual planning.
* A definition can be overconfident: false precision can be more harmful than explicitly stated uncertainty.

== Beneficial Outcomes ==
(Under construction.)
A well-structured project definition improves:
* alignment among stakeholders,
* quality of downstream design decisions,
* defensibility of cost/schedule commitments,
* risk identification and allocation,
* the ability to terminate weak projects early.

== See also ==
* [[Project_Development|Project Development]]
* [[Project_Execution|Project Execution]]
* [[Project_Delivery_Methods|Project Delivery Methods]]
* [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]]
* [[Uncertainty_and_Risk_in_Civil_Engineering_Practice|Uncertainty and Risk in Civil Engineering Practice]]
* [[Project_stakeholder|Project stakeholder]]

== Learning Outcomes ==
(Under construction.)
After mastering this article, the reader should be able to:
* distinguish requirements from specifications,
* describe what artifacts enable definition-stage decisions,
* explain how project definition sets the initial risk posture.

== Notes ==
(Under construction.)

== References ==
(Under construction.)

[[Category:Definition]]

Project Execution

2026-01-19T15:32:00Z

Pooyan: Project Execution

'''<big>This page is under construction ...</big>'''
''See also [[Project_Definition|Project Definition]], [[Project_Development|Project Development]], [[Project_Delivery_Methods|Project Delivery Methods]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]].''
''See also [[Management_control|Management control]], [[Management_plans_and_sub-plans|Management plans and sub-plans]], [[Project_stakeholder|Project stakeholder]] ...''

== Basic considerations ==
In civil engineering, ''project execution'' is the realized performance of the project work and controls needed to deliver accepted outcomes. Execution includes:
* procurement and construction activities,
* engineering support during construction,
* integration (physical + systems),
* verification, testing, commissioning, and acceptance,
* management control (scope, schedule, cost, risk, quality, safety),
* contract administration and change control.

A key idea in RiskWiki is that execution is not merely “doing the work”; it is ''doing the work under a control architecture'' that meets sponsor and stakeholder requirements.

[[File:2016_10_30_Project_Development_definition_execution_model.png|thumb|400px|Project definition / development / execution model (conceptual).]]

[[#top|Top of current page]]

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

=== Semantic framework ===
Common semantic confusion:
* equating “execution” with “construction” only (execution includes integration, verification, and acceptance),
* treating “project management” as separate from execution (management and control are embedded in execution),
* confusing execution with operations/maintenance (execution ends at acceptance/transition).

Working distinctions:
* '''Execution''' produces the facility and verified performance for acceptance.
* '''Operations''' uses the delivered facility to produce ongoing services.

=== Epistemic framework ===
Execution is performed under residual uncertainty (not all uncertainty can be retired in development). Execution therefore requires:
* active risk monitoring and response,
* configuration control of design artifacts,
* disciplined handling of unknown conditions and interface disputes,
* verification that outputs meet acceptance criteria.

Execution is also where language ambiguity and organizational interfaces become physical outcomes (or failures).

=== Logical framework ===
Execution can be viewed as controlled traversal through:
* contract packages → work packages → work units,
* each with inputs, outputs, acceptance criteria, and interfaces.

Control systems (design control, quality, safety, schedule, cost, risk) exist to keep this traversal feasible and aligned with project objectives.

[[#top|Top of current page]]

== Practice frameworks for Project Execution ==
(Under construction.)

Typical execution components in civil engineering:
* mobilization and site logistics
* procurement and supply chain management
* construction means and methods
* inspection and quality control / assurance
* design support, RFIs, submittals, nonconformance management
* testing and commissioning
* turnover documentation and acceptance

[[#top|Top of current page]]

== Typical execution artifacts ==
Execution artifacts vary by delivery method and contract structure, but commonly include:
* approved submittals and shop drawings
* RFIs and design clarifications
* field change requests and change orders
* daily reports, inspection records, test reports
* updated schedules (updates, recovery schedules)
* cost reports and earned value / progress measures (where applicable)
* risk register updates and response actions
* as-built records and turnover packages
* commissioning and acceptance documentation

[[#top|Top of current page]]

== Interfaces to uncertainty and risk management ==
Execution is where:
* risks become events (or are successfully prevented),
* contingency and management reserve are consumed (or preserved),
* contractual allocations are tested (claims/disputes),
* feasibility is demonstrated in the field.

A practical control principle:
* Any deviation that affects acceptance criteria must trigger design/configuration control review before the deviation is embedded in the physical work.

[[#top|Top of current page]]

== Working definition of the term ==
Project execution
:Project execution is the coordinated performance of project work and embedded control processes to produce project deliverables and verified outcomes that achieve acceptance, within authorized constraints on scope, schedule, cost, quality, safety, and risk.

[[#top|Top of current page]]

== Limitations of the definition ==
(Under construction.)
* Execution may include late-stage design (especially in design-build); boundaries depend on delivery method.
* Some organizations use “execution” to mean only the construction period; RiskWiki uses a broader meaning including integration and acceptance.

== Beneficial Outcomes ==
(Under construction.)
Effective execution improves:
* predictability of delivery,
* safety and quality outcomes,
* stakeholder trust and governance transparency,
* reduced rework and claims.

== See also ==
* [[Project_Definition|Project Definition]]
* [[Project_Development|Project Development]]
* [[Project_Delivery_Methods|Project Delivery Methods]]
* [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]]
* [[Management_control|Management control]]
* [[Management_plans_and_sub-plans|Management plans and sub-plans]]

== Learning Outcomes ==
(Under construction.)
The reader should be able to:
* distinguish execution from construction-only thinking,
* identify key execution artifacts and why they matter,
* explain how control systems operationalize risk management.

== Notes ==
(Under construction.)

== References ==
(Under construction.)

[[Category:Definition]]

Project Development

2026-01-19T15:30:55Z

Pooyan: Project Development

'''<big>This page is under construction ...</big>'''
''See also [[Project_Definition|Project Definition]], [[Project_Execution|Project Execution]], [[Project_Delivery_Methods|Project Delivery Methods]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]].''
''See also [[Management_plans_and_sub-plans|Management plans and sub-plans]], [[Management_control|Management control]], [[Civil_Engineering_Projects|Civil Engineering Projects]] ...''

== Basic considerations ==
In civil engineering, ''project development'' is the progressive elaboration of the project definition into an implementable and governable solution. It produces the engineering and management artifacts that make procurement and construction possible.

Project development is not only “design”. It includes:
* decomposition into contract and work packages,
* interface definition,
* creation of specifications and acceptance criteria,
* establishment of baselines (scope, cost, schedule, performance),
* development of management plans that control execution.

[[File:2016_10_30_Project_Development_definition_execution_model.png|thumb|400px|Project definition / development / execution model (conceptual).]]

[[#top|Top of current page]]

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

=== Semantic framework ===
Common semantic failures:
* treating project development as a single “design phase” (it is a family of phases),
* treating “deliverables” as paperwork rather than governance artifacts,
* confusing “conceptual design” with “detailed design” (especially under design-build).

Working distinctions:
* '''Conceptual design''' expresses a solution hypothesis and supports feasibility.
* '''Detailed design''' expresses constructible details and supports procurement, fabrication, construction, and verification.

=== Epistemic framework ===
Project development is the primary phase in which epistemic uncertainty is reduced (“retired”) through:
* surveys and investigations,
* modeling and analysis,
* stakeholder and regulatory coordination,
* constructability and interface validation,
* progressive refinement of requirements and acceptance criteria.

A core development objective is to reduce uncertainty at a rate that is consistent with governance decisions and delivery method.

=== Logical framework ===
Project development partitions the “universal set” of possible project actions into a controlled structure:
* artifacts (models, drawings, specs, plans)
* interfaces (technical + contractual)
* packages (contract packages and work packages)
* controls (baselines, change control, verification)

The quality of project development is measured by the feasibility and integrity of this structure under execution.

[[#top|Top of current page]]

== Practice frameworks for Project Development ==
(Under construction.)

Typical civil-engineering development phases (names vary):
* programming / feasibility
* conceptual engineering
* preliminary engineering
* final design
* procurement preparation (bid packages, performance specs, contract artifacts)

Under design-build, development often splits across parties:
* owner (or owner’s agent) develops requirements and conceptual design,
* contractor team develops detailed design and constructs it,
* feasibility must be preserved through each handoff.

[[#top|Top of current page]]

== Typical development artifacts ==
A working list (varies by program and agency):

Engineering artifacts:
* basis of design / design criteria
* investigations (survey, geotechnical, utilities, existing conditions)
* discipline models (geotechnical, structural, MEP, systems, etc.)
* drawings and specifications (progressive sets)
* interface control documents / interface matrix
* verification and validation approach (testing requirements, commissioning basis)

Management / governance artifacts:
* WBS and contract packaging strategy
* risk management plan and risk register updates
* schedule baseline and schedule risk logic
* cost estimate updates with basis and uncertainty
* quality management plan / design control approach
* configuration management approach (control of design artifacts)
* stakeholder and permitting coordination plan
* procurement plan and contracting strategy

[[#top|Top of current page]]

== Interfaces to uncertainty and risk management ==
Project development is where many “definition” risks are converted into:
* reduced uncertainty (retired through investigation/design), or
* explicit risk allocation (contracts), or
* explicit funding (contingency / management reserve), or
* redesigned scope/requirements (governance decision).

A practical demarcation test used in civil engineering:
* If an uncertainty threatens feasibility of the solution, it must be addressed in development before execution commits irreversible cost/schedule.

[[#top|Top of current page]]

== Working definition of the term ==
Project development
:Project development is the structured sequence of engineering and management activities that progressively elaborates project definition into feasible designs, specifications, contract packages, interfaces, and control baselines sufficient to enable procurement and controlled project execution.

[[#top|Top of current page]]

== Limitations of the definition ==
(Under construction.)
* Development is not strictly sequential; phases may overlap and iterate.
* The boundary between development and execution depends on delivery method, governance rules, and contract structure.
* “Development” may be distributed across multiple organizations, increasing interface risk.

== Beneficial Outcomes ==
(Under construction.)
High-quality project development improves:
* feasibility and constructability,
* clarity of responsibilities and interfaces,
* stability of cost/schedule outcomes,
* verifiability of compliance and acceptance.

== See also ==
* [[Project_Definition|Project Definition]]
* [[Project_Execution|Project Execution]]
* [[Project_Delivery_Methods|Project Delivery Methods]]
* [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]]
* [[Management_plans_and_sub-plans|Management plans and sub-plans]]
* [[Management_control|Management control]]

== Learning Outcomes ==
(Under construction.)
The reader should be able to:
* explain conceptual vs detailed design as a feasibility/constructability boundary,
* list core artifacts that make procurement and execution possible,
* describe how development reduces uncertainty and reallocates risk.

== Notes ==
(Under construction.)

== References ==
(Under construction.)

[[Category:Definition]]

User:Pooyan

2026-01-19T15:29:49Z

Pooyan: Project Definition

Predictive analytics

2025-11-29T23:23:54Z

Pooyan:

'''Predictive analytics''' refers to a family of statistical and data-driven methods that use historical data to estimate the likelihood of future events or states. In practical terms, predictive models take past observations (inputs) and produce a quantitative forecast – often a probability or a score – that can be used to guide decisions about projects, assets, stakeholders, or systems.

While the techniques come from statistics, machine learning, and data mining, the distinctive feature of predictive analytics is that it is used to support **forward-looking decisions** at the level of individual units (e.g. a specific project, contract package, asset, or stakeholder), rather than only aggregate forecasts.

== Basic concepts ==

* '''Historical data''' – observations of past events: project schedules, costs, risk registers, incident logs, asset failures, traffic counts, etc.
* '''Features (explanatory variables)''' – measurable characteristics used by the model (e.g. project type, contract form, phase, complexity indicators, geotechnical conditions, contractor history).
* '''Target variable''' – the outcome we want to predict (e.g. probability of cost overrun, schedule delay, failure, dispute, or claims).
* '''Model''' – a mathematical or algorithmic mapping from features to target (e.g. regression, decision tree, ensemble, time-series model).
* '''Score''' – the model’s prediction for a specific case, often expressed as a probability or risk index.

Predictive analytics is usually embedded into **decision workflows**, not used as a stand-alone report. The point is not to “predict the future” in a mystical sense, but to rank alternatives, identify higher-risk cases, and focus scarce management attention.

== Types of models ==

For Risk Engineering purposes we can think in three broad families:

* '''Predictive models''' – estimate the probability or severity of a future outcome for a specific unit.
** Example: probability that a civil-works contract will exceed its budget by more than 15%; probability that a retaining structure design will trigger change-orders due to constructability issues.

* '''Descriptive models''' – group or segment projects, assets, or stakeholders with similar behavior or risk profiles.
** Example: clustering projects into “stable brownfield transit upgrades” vs. “complex greenfield mega-projects” to understand typical risk patterns for each cluster.

* '''Decision models''' – combine predictive scores with objectives and constraints to recommend an action.
** Example: using predicted delay and cost-overrun risk to decide which interfaces require early mitigation, which contracts need tighter oversight, or where contingency should be concentrated.

== Applications in civil engineering and project risk ==

Some typical uses in a civil-engineering / infrastructure context:

* '''Project risk screening'''
** Using historical project data to estimate which new projects are likely to suffer major cost or schedule overruns, and flagging them for deeper qualitative risk review.

* '''Contract and delivery-method choice'''
** Combining project attributes (scope, interfaces, geotechnical complexity, stakeholder environment) with outcomes of past projects to estimate whether design–bid–build, design–build, CM/GC, or PPP is likely to produce lower risk of disputes or claims.

* '''Asset performance and reliability'''
** Predicting the probability of failure or performance degradation for assets (bridges, tunnels, pumps, track, structures) based on age, condition, environment, loading, and maintenance history, to support condition-based maintenance and renewal planning.

* '''Safety and incident analysis'''
** Identifying patterns in incidents, near misses, or non-conformances to estimate which work packages, contractors, or site conditions carry higher risk and where preventive actions are most effective.

* '''Construction phasing and logistics'''
** Forecasting likely delay hotspots from past schedule behavior (e.g. interface hand-offs, utility relocations, third-party approvals) to prioritize coordination effort.

In most of these applications, predictive analytics does **not** replace engineering judgement. It provides an additional evidence layer: “projects with this combination of features have historically gone bad in this way”, which can be used alongside expert review.

== Relationship to risk management ==

Predictive analytics is one element of a broader [[Project_risk_management|project risk management]] and [[Program_Management_in_Civil_Engineering|program management]] framework:

* It supports **risk identification** by surfacing patterns that are not obvious from a few anecdotal cases.
* It supports **risk assessment** by turning qualitative impressions (“this looks risky”) into quantitative estimates (“this pattern has historically doubled our delay risk”).
* It can inform **risk response planning** by evaluating which mitigations historically led to better outcomes for similar projects.
* It can be integrated into **ongoing monitoring**, where models are periodically re-trained as new project data becomes available.

A key governance issue is that predictive models themselves must not become opaque sources of domination in decision processes: their limitations, assumptions, and error rates should be transparent, and they should be used to inform, not dictate, engineering or policy choices.

== Limitations and cautions ==

Predictive analytics is powerful but constrained by:

* '''Data quality and bias''' – if historical data omits important failures, or reflects biased practices, models will learn and amplify those biases.
* '''Concept drift''' – when regulations, technologies, or procurement practices change, past patterns may no longer be reliable.
* '''Over-fitting''' – overly complex models that perform well on past data but poorly on new projects.
* '''Interpretability''' – some model types are difficult to explain to stakeholders; in high-stakes public projects, simpler but more transparent models are often preferable.

For critical decisions in infrastructure and public programs, predictive analytics should be combined with:

* scenario analysis,
* structured expert judgement,
* and clear documentation of how model outputs are used in actual decisions.

== See also ==

* [[Decision_Making_In_Engineering]]
* [[Civil_Engineering_Projects]]
* [[Program_Management_in_Civil_Engineering]]
* [[Project_risk_management]]
* [[Project_stakeholder]]
* [https://en.wikipedia.org/wiki/Predictive_analytics Predictive analytics on Wikipedia] (general background, techniques, and tools)

Predictive analytics

2025-11-29T23:17:33Z

Pooyan: Created page with "== Basic considerations == == Logical Framework == == Legislative Framework == == Procurement/Contractual Framework == == The Contracting objective is to ensure that the client (public or private) receives conforming products and services while keeping the overall costs of client contract surveillance reasonable. This objective is based on the premise that the Contractor is responsible for the management and quality control of the contract products and services an..."

== Basic considerations ==

== Logical Framework ==

== Legislative Framework ==

== Procurement/Contractual Framework == ==

The Contracting objective is to ensure that the client (public or private) receives conforming products and services while keeping the overall costs of client contract surveillance reasonable. This objective is based on the premise that the Contractor is responsible for the management and quality control of the contract products and services and the client is responsible for performance assessment.

The client interfaces to the contractor on a number of levels; the contract level, the periodic work plan level, the work package level and often for critical deliverables or products and services.[1]

== Practice Framework ==

=== Information Technology ===

Microsoft Press defines Acceptance Criteria as “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” Google defines them as “Pre-established standards or requirements a product or project must meet.”

* Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of project integration. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.[2]

== Further Guidance ==

=== Contracting Definitions ===

* “Acceptance” is defined as the act of an authorized representative of the Government such as a Task Order Manager or COTR by which the Government, for itself or as agent of another, approves specific deliverables, products, or services (“deliverables”) rendered as partial or complete performance of the contract, task order or PG quality requirements (“contract quality requirements”) (Also reference FAR 52.256-5 Inspection of Services – Cost Reimbursement).

* “Authorized Company Certifying Official” is defined as a certification attested to by an authorized representative of the Contractor.

* “Acceptable Quality Level” is the maximum allowable quantity of non-conforming products or services defined as either an absolute number or as a percent defective (or defects per hundred units) for which lots will be accepted; most of the time by the sampling procedures being used.

* “Certification” is defined as the act of determining, verifying, and attesting in writing to the status of deliverables, personnel, processes, procedures, or items in accordance with specified requirements.

* “Certification System” is defined as the administrative procedures for completing, reviewing, and approving the certificate of conformance; signed by an authorized party responsible for overall quality of the product or service.

* “Certificate of Conformance” is defined as a document signed or otherwise authenticated by an authorized individual certifying the degree to which items or services meet specified requirements.

* “Contract quality requirements” are the technical requirements in the contract relating to the quality of the product or service and those contract clauses prescribing inspection, and other quality controls incumbent on the PMO contractor, to assure that the deliverable conforms to the contractual requirements. (Task Order and Contract are used interchangeably in this definition.)

* “Conditional acceptance” is defined as the acceptance of deliverables that do not conform to contract quality requirements, or are otherwise incomplete, that the contractor is required to correct or otherwise complete by a specified date.

* “Critical nonconformance” means a nonconformance (inclusive of being incomplete or delayed as applicable) that is likely to prevent performance (at the programmatic level) of a vital oversight function or substantially reduce the usability, functionality or reliability of the products or services for their intended end purpose.

* “Critical Requirements”: Critical requirements are ones that are vital to the programmatic oversight function.
** Examples of vital programmatic oversight functions are contractor products that are major inputs into critical decisions that are transmitted to senior executives, legislative staff, or other agencies.

* “Government contract quality assurance” means the various functions, including inspection, performed to determine whether a contractor has fulfilled the contract obligations pertaining to quality and quantity.

* “Inspection” is defined as the examination and testing supplies or services to determine whether they conform to contract requirements.

* “Latent Defect” is defined as a defect that exists at the time of acceptance but cannot be discovered by a reasonable inspection.

* “Major nonconformance” means a nonconformance, other than critical, that is likely to materially reduce the usability, functionality or reliability of the products or services for their intended end purpose.

* “Minor nonconformance” means a nonconformance that is not likely to materially reduce the usability, functionality or reliability of the products or services for their intended end purpose, or is a departure from established standards having little bearing on the effective use of the products or services, or reliance on the contractor’s assessments, evaluations or data.

* “Patent Defect” is defined as any defect that exists at the time of acceptance and is not a latent defect.

* “Quality Assurance” (QA) is defined as those actions taken by the government to check PMO contractor performed services to determine whether they meet the requirements and specifications of the work statement. QA activities include all those actions that provide confidence that the required level of quality for contractor products and services is achieved.

* “Quality Assurance Surveillance” is defined as the monitoring of PMO contractor performance to assure that services received are timely and consistent with contract quality requirements.

* “Quality Assurance Surveillance Plan” (QASP) is defined as the document used for contract quality assurance planning.

* “Quality Control” (QC) is defined as those actions taken by the PMO contractor to control the output of services so that they meet the requirements and specifications of the*

Acceptance

2025-11-29T23:12:50Z

Pooyan: Created page with "= Acceptance = ''From Risk Engineering / Civil Engineering'' __TOC__ == Basic considerations == == Logical Framework == == Legislative Framework == == Procurement/Contractual Framework == The contracting objective is to ensure that the client (public or private) receives conforming products and services while keeping the overall costs of client contract surveillance reasonable. This objective is based on the premise that the Contractor is responsible for the manag..."

= Acceptance =

''From Risk Engineering / Civil Engineering''

__TOC__

== Basic considerations ==

== Logical Framework ==

== Legislative Framework ==

== Procurement/Contractual Framework ==

The contracting objective is to ensure that the client (public or private) receives conforming products and services while keeping the overall costs of client contract surveillance reasonable. This objective is based on the premise that the Contractor is responsible for the management and quality control of the contract products and services and the client is responsible for performance assessment.

The client interfaces with the contractor on a number of levels: the contract level, the periodic work plan level, the work package level and, often, for critical deliverables or products and services.<ref name="FAR">{{cite web |title=FAR 52.246-5 – Inspection of Services (Cost-Reimbursement) |url=https://www.ecfr.gov/current/title-48 |publisher=Federal Acquisition Regulation |access-date=DATE}}</ref>

== Practice Framework ==

=== Information Technology ===

Microsoft Press defines '''acceptance criteria''' as “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.”
Google defines them as “Pre-established standards or requirements a product or project must meet.”

* Acceptance criteria are a set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of project integration. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.<ref name="agile">''(Adapted from agile software development usage of “acceptance criteria” and “conditions of satisfaction”.)''</ref>

== Further Guidance ==

=== Contracting Definitions ===

* '''Acceptance''' – The act of an authorized representative of the client (e.g. Task Order Manager, COR/COTR) by which the client, for itself or as agent of another, approves specific deliverables, products, or services rendered as partial or complete performance of the contract, task order or project-governance (PG) quality requirements (“contract quality requirements”). (See also FAR 52.246-5, ''Inspection of Services – Cost Reimbursement''.)

* '''Authorized Company Certifying Official''' – An authorized representative of the Contractor who attests to certifications on behalf of the company.

* '''Acceptable Quality Level (AQL)''' – The maximum allowable quantity of non-conforming products or services, defined as either an absolute number or as a percent defective (or defects per hundred units), for which lots will be accepted, typically in conjunction with an established sampling procedure.

* '''Certification''' – The act of determining, verifying, and attesting in writing to the status of deliverables, personnel, processes, procedures, or items in accordance with specified requirements.

* '''Certification System''' – The administrative procedures for completing, reviewing, and approving the certificate of conformance; signed by an authorized party responsible for overall quality of the product or service.

* '''Certificate of Conformance''' – A document signed or otherwise authenticated by an authorized individual certifying the degree to which items or services meet specified requirements.

* '''Contract quality requirements''' – The technical requirements in the contract relating to the quality of the product or service and those contract clauses prescribing inspection and other quality controls incumbent on the contractor to assure that the deliverable conforms to the contractual requirements. (Task Order and Contract are used interchangeably in this definition.)

* '''Conditional acceptance''' – Acceptance of deliverables that do not conform to contract quality requirements, or are otherwise incomplete, that the contractor is required to correct or otherwise complete by a specified date.

* '''Critical nonconformance''' – A nonconformance (including incompleteness or delay, as applicable) that is likely to prevent performance (at the programmatic level) of a vital oversight function or substantially reduce the usability, functionality or reliability of the products or services for their intended purpose.

* '''Critical requirements''' – Requirements that are vital to the programmatic oversight function.
Examples: contractor products that are major inputs into critical decisions transmitted to senior executives, legislative staff, or other agencies.

* '''Government contract quality assurance''' – The various functions, including inspection, performed to determine whether a contractor has fulfilled the contract obligations pertaining to quality and quantity.

* '''Inspection''' – Examination and testing of supplies or services to determine whether they conform to contract requirements.

* '''Latent defect''' – A defect that exists at the time of acceptance but cannot be discovered by reasonable inspection.

* '''Major nonconformance''' – A nonconformance, other than critical, that is likely to materially reduce the usability, functionality or reliability of the products or services for their intended purpose.

* '''Minor nonconformance''' – A nonconformance that is not likely to materially reduce the usability, functionality or reliability of the products or services for their intended purpose, or is a departure from established standards having little bearing on the effective use of the products or services, or on reliance on the contractor’s assessments, evaluations or data.

* '''Patent defect''' – Any defect that exists at the time of acceptance and is not a latent defect.

* '''Quality Assurance (QA)''' – Actions taken by the client to check contractor-performed services to determine whether they meet the requirements and specifications of the work statement. QA activities provide confidence that the required level of quality is achieved.

* '''Quality Assurance Surveillance''' – The monitoring of contractor performance to assure that services received are timely and consistent with contract quality requirements.

* '''Quality Assurance Surveillance Plan (QASP)''' – The document used for contract quality-assurance planning and surveillance.

* '''Quality Control (QC)''' – Actions taken by the contractor to control the output of services so that they meet the requirements and specifications of the work statement.

* '''QC activities''' – Actions that involve the use of appropriate contractor policies and procedures in performance of the scope of work.

* '''Random sampling''' – A sampling method whereby each service output in a lot has an equal chance of being selected in order to estimate overall quality of the lot against an established standard.

* '''Routine requirements''' – Requirements that account for the majority of the contract effort. The client still demands quality work from the contractor but wants to minimize administrative expenses and maximize cost-effectiveness by not expending scarce contract-administration resources on intensive inspections when the contractor is delivering work that meets or exceeds expectations.

* '''Sample''' – One or more product or service outputs drawn from a lot.

* '''Sampling guide''' – A written procedure that describes what will be checked, the standard of performance, the performance indicators, and how checking will be accomplished (e.g. random or planned sampling), formulated to make use of the contractor’s quality plan.

* '''Significant requirements''' – Requirements other than critical, that if not met would materially reduce the usability, functionality or reliability of the products or services for their intended purpose.
Significant requirements may require client intervention to demand a higher standard of quality control on the part of the contractor.

* '''Surveillance activity checklist''' – Any acceptable format used by the client’s technical representative to evaluate the performance of the contractor. It can be used with random sampling or with other planned or scheduled surveillance activities.

== Beneficial Outcomes ==

''(Under construction)''

== Working definition of the term ==

''(Under construction)''

== Limitations of the definition ==

''(Under construction)''

== See also ==

* [[Program Management in Civil Engineering]]
* [[Civil Engineering Projects]]
* [[Management control]]

== References ==

<references/>

Management control

2025-11-29T23:04:55Z

Pooyan: Restored from 2017 RiskWiki archive (Wayback).

'''This page is under construction…'''

''See also: [[Performance_Management_Systems_(PMSs)]], [[Project_Execution]], [[Management_plans_and_sub-plans]].''

== Basic considerations ==

There is increasing recognition that '''management control''' and '''management control systems (MCS)''' need more coherent theoretical foundations if we want a systemic, non-piecemeal understanding of how control actually works in real organizations.<ref name="FerreiraOtley2009" />

Ferreira and Otley argue that our understanding of management control and MCSs will remain fragmented as long as we ignore the inter-dependencies between different control mechanisms operating simultaneously in the same organization. Their answer is a more holistic view in the form of a '''performance management and control (PMC) framework''', which integrates measurement, control, and learning rather than treating “controls” as just accounting artefacts.<ref name="FerreiraOtley2009" />

In a civil-engineering / project context, that distinction really matters: if you only see “control” as budget variances, you miss design controls, configuration controls, quality controls, procurement controls, and all the other technical control systems that actually govern whether a project can be delivered within constraints.

== Logical Framework ==

From an engineering perspective, you can think of management control as:

* A subset of the project organization’s overall '''Performance Management System (PMS)''' – the big umbrella of measurement, feedback, incentives, and learning; and
* A collection of more specific '''control systems''' (design, cost, schedule, quality, configuration, procurement, etc.) which together shape behaviour and outcomes.

A minimal logical framing:

# The organization (or project) has '''objectives''' – usually multiple, sometimes conflicting.
# There are '''activities and processes''' intended to achieve those objectives.
# There is some mechanism for '''measurement''' (of outputs, outcomes, and sometimes inputs).
# There are '''feedback and decision mechanisms''' that compare measured performance with objectives.
# There are '''interventions''' (changes in behaviour, resources, or structure) intended to reduce the gap.

In theory, that sounds clean. In practice, each step is politicized, fragmented, and distributed across different professional silos — and that’s exactly why the naive “thermostat” metaphor for control often fails.

== Research frameworks in Academic media ==

Measurement of '''performance''' has long been a concern across several disciplines. For risk engineering and civil engineering, two strands are particularly relevant:

* '''Management accounting / management control research'''
* '''Project management / project governance research'''

Most of the heavy theoretical lifting on “management control systems” comes from the first.

=== Management accounting research ===

Traditional management accounting research focused on '''financial performance''', typically using micro-economic or agency-theoretic models.<ref name="Otley1999" />

This did two problematic things:

* It gave relatively little guidance to '''designers''' of control systems (engineers, project managers, systems designers), and
* It implicitly equated “management control” with “management accounting”, at the very moment when classic cost accounting was being widely criticized as obsolete.

The result: a lot of sophisticated work on accounting techniques, but much less on the '''overall control architecture''' of organizations.

More recent work shifts from:

* “How do we '''measure''' performance?”
**to**
* “How do we '''manage''' performance?” – acknowledging performance is multi-dimensional, ambiguous, and context-dependent.

==== Cybernetic Model for Management Controls ====

A huge amount of control theory in management is built on a cybernetic model: negative feedback loops.

Hofstede characterises a standard cybernetic control process as consisting of five steps:<ref name="Hofstede1978" />

# Set goals or standards.
# Measure actual accomplishment (output or work performed).
# Compare measured performance to goals.
# Identify and analyse '''variances'''.
# Feed variance information back into the process and intervene to correct the deviations.

The thermostat metaphor: a simple, closed control loop.

Hofstede points out that this model rests on a set of strong assumptions:

* There is a '''defined and documented process''' with identifiable boundaries that corresponds to effective and efficient accomplishment of objectives.
* Actual accomplishment can be '''measured''' and compared to those objectives.
* Variances can be detected and analysed in a meaningful way.
* Variance information can be communicated in a timely, intelligible way across specialist boundaries.
* Actors are sufficiently '''trained and motivated''' to act on that information to change the process.

He questions whether these assumptions hold in real organizations, as opposed to electrical circuits — which is exactly why engineers need to be careful when importing cybernetic metaphors.

From an engineering governance perspective, Hofstede makes two important observations (adapted into a project context):

* Control processes are usually tied to '''functional specialisation''':
** Senior management (or sponsors) set high-level objectives and standards.
** Technical and support staff measure and compare performance.
** Different levels of management intervene – minor interventions at lower levels; major changes in core project variables (scope, time, cost) at higher levels.
* This separation means that the cybernetic loop is not a single device, but a chain of different professions, tools, and routines – all of which can fail in different ways.

He also notes:

* Cybernetic control works best in '''structured environments''' where processes and outputs are adequately determined.
* Completely determined processes make control trivial (and sometimes redundant), while completely undetermined environments make formal control “infeasible”.<ref name="Sutherland1975" />

==== Homeostatic Model for Management Controls ====

Hofstede contrasts the thermostat (cybernetic) with a '''homeostatic''' model: the living cell.

* In the homeostatic view, measurement, analysis, communication, and intervention are carried out within the '''same professional group''' (where feasible).
* Standards may still be set “outside”, but the self-regulating capacity resides in the unit.

He writes that a homeostatic system:

> “is equipped with internal processes capable of maintaining an equilibrium (self-regulating) in a changing environment, provided that the environmental conditions stay within certain norms.”<ref name="Hofstede1978" />

The downside: homeostatic systems are more vulnerable than simple cybernetic devices – they have to grow, adapt, and can deteriorate; they can’t just be “swapped out like a thermostat”.

For civil engineering, the analogy is intuitive:

* Some control systems are engineered gadgets (e.g. numerical acceptance criteria in a design code).
* Others are living practices – a design review culture, a safety culture, a project-controls team.

=== Control Frameworks ===

Control '''frameworks''' help:

* Structure theory-building,
* Integrate disparate findings,
* Provide a language for practitioners to describe their systems.

Otley (1999) proposes a now-classic performance-management framework built around five questions:<ref name="Otley1999" />

# What are the key organizational objectives?
# What strategies and plans are adopted to achieve them?
# How is performance measured and evaluated?
# What rewards and incentives are attached to performance?
# What information flows provide feedback and enable learning?

Ferreira & Otley (2009) extend this into a broader '''Performance Management and Control (PMC) framework''' – explicitly designed as a research and diagnostic tool for describing MCS design and use.<ref name="FerreiraOtley2009" />

=== Control System Environments ===

Hofstede, citing Sutherland (1975), points out that many organizational environments are too stochastic or politically fluid to support a textbook cybernetic control system.<ref name="Sutherland1975" />

Three common modes of failure:

# **Objectives** are missing, unclear, or change in an uncontrolled way.
# **Work/accomplishment** is not measurable in a meaningful sense (or only via weak surrogates).
# **Feedback and intervention** fail – information is late, unintelligible, politically toxic, or actors are unwilling/unable to act.

Ferreira & Otley’s case study on the Portuguese Post Office (PPO) illustrates this in practice: targets are partly negotiated, partly imposed; lower-level managers have little influence on target-setting; and what is “controlled” is often as much a product of internal coalitions as of rational design.<ref name="FerreiraOtley2009" />

=== Types of Control Systems ===

Simons’ distinction (as used by Ferreira & Otley) between two system types is useful:<ref name="FerreiraOtley2009" />

* '''Diagnostic control systems (DCS)''' – used to monitor and correct performance against pre-set targets.
* '''Interactive control systems (ICS)''' – used by senior managers to focus organizational attention on strategic uncertainties, to foster learning, and to generate new strategies.

In practice, real performance-management architectures mix both:

* Budgets, KPIs, and variance reports used diagnostically;
* Strategic reviews, benchmarking exercises, and repeated dialogue used interactively.

=== Positive and Negative aspects of Management Controls ===

Controls are double-edged:

* Positively, they:
** Provide clarity about objectives,
** Reduce opportunism,
** Enable coordination across complex projects.
* Negatively, they:
** Can distort behaviour (gaming metrics, “hitting the target but missing the point”),
** Can suppress learning and dissent,
** Can hard-code bad assumptions if objectives are wrong.

A civil-engineering MCS has to be designed with both sides in mind.

== Regulatory Framework ==

The management-control literature intersects with regulatory frameworks where:

* Law or regulation impose minimum control architectures (e.g. internal control over financial reporting, safety management systems).
* Public-sector project sponsors (DOE, FTA, USACE, etc.) require documented management-control and performance-management systems as part of project governance.

RiskWiki’s purpose here is not to provide a current snapshot of any one agency’s policy, but to map “good practice” concepts that engineers can use as a reference point. Readers must always verify the latest versions of laws, regulations, and manuals directly from the issuing agencies.

== Practice Framework (Under construction) ==

''Work in progress – to be aligned with the PMIBoK materials on “project controls” and with agency guidance (DOE, FTA, FRA, USACE, etc.).''

The PMBOK® Guide uses “management control” language in many places (contingency reserve, control accounts, management reserve, performance-measurement baseline), but does not define “performance” or “management control” as such. In civil-engineering practice, project controls usually blend:

* Engineering control systems (design, quality, configuration),
* Project-controls systems (cost, schedule, risk),
* Governance and internal-control structures.

A genuine MCS has to integrate these, not treat them as siloed.

== Further Guidance ==

In an engineering context, the primary benefit of designing an explicit MCS is:

* To increase the likelihood that the project actually delivers the required outcomes,
* And to make explicit which mix of controls (technical, financial, organizational, cultural) is being relied upon.

Engineering controls are not just accounting controls; they share some DNA but operate on different objects (design artefacts, physical work, safety margins, risk registers).

== Beneficial Outcomes ==

A well-designed management-control system for civil-engineering projects should enable:

* Better alignment between sponsor objectives and project-team behaviour.
* Earlier detection of deviations in core variables (scope, time, cost, quality, risk).
* More disciplined learning and adaptation over the project’s life cycle.
* Greater transparency for regulators, sponsors, and the public.

Ferreira & Otley’s PMC framework is one way of structuring these issues; the aim is to move beyond ad-hoc collections of tools towards coherent control architecture.

== Working definition of the term ==

; Management control
: ''Management control'' is a subset of the project organization’s [[Performance_Management_Systems_(PMSs)|performance management system]]. It consists of the evolving formal and informal processes for:
:* conveying material objectives and goals,
:* assisting strategic, operational, and ongoing management through analysis, planning, measurement, and control,
:* and supporting and facilitating organizational learning and change.<ref name="FerreiraOtley2009" /><ref name="Otley1999" />

; Management Control Systems (MCS)
: A ''Management Control System (MCS)'' is the collection or package of management controls and control systems in use. Individual systems may be:
:* Engineering-specific (e.g. [[Design controls]], configuration management, quality control, procurement control),
:* Accounting-based (budgets, financial measures),
:* Administrative (organization structure, governance),
:* Social/cultural (values, norms, informal practices).

: Project organizations usually have many such controls. They are used, to varying degrees, to align the activities of individuals and teams with project goals, objectives, and constraints.<ref name="MalmiBrown2008" />

== Limitations of the definition ==

This working definition:

* Emphasizes design and integration, rather than just accounting techniques.
* Is still high-level; specific project-type and regulatory context will require tailoring.
* Assumes objectives can be articulated and measured with at least some clarity — which is often contested in public works and politically sensitive projects.

== See also ==

* [[Performance_Management_Systems_(PMSs)]]
* [[Management_plans_and_sub-plans]]
* [[Project_Execution]]
* [[Program_Management_in_Civil_Engineering]]
* Wikipedia: [https://en.wikipedia.org/wiki/Control_(management) Control (management)], [https://en.wikipedia.org/wiki/Management_control_system Management control system]
* Wikipedia: [https://en.wikipedia.org/wiki/Template:Systems_engineering Systems engineering elements] (template)

== Notes ==

''(This section can be used later if you wish to separate “Notes” from “References” using the <code><nowiki><references group="Note"/></nowiki></code> mechanism.)''

== References ==

* Ferreira, A., and D. Otley. “The design and use of performance management systems: An extended framework for analysis.” ''Management Accounting Research'' 20(4), 2009, pp. 263–282.
* Otley, D. “Performance management: a framework for management control systems research.” ''Management Accounting Research'' 10, 1999, pp. 363–382.
* Hofstede, G. “The poverty of management control philosophy.” ''Academy of Management Review'' 3(3), 1978, pp. 450–461.
* Sutherland, J. W. “System theoretic limits on the cybernetic paradigm.” ''Behavioral Science'' 20, 1975, pp. 191–200.
* Malmi, T., and D. A. Brown. “Management control systems as a package—opportunities, challenges and research directions.” ''Management Accounting Research'' 19, 2008, pp. 287–300.

<references />

Civil Engineering Projects

2025-11-29T22:57:19Z

Pooyan:

'''<big>This page is under construction ...</big>'''

''See also [[Project_Execution|Project Execution]], [[Project_Development|Project Development]], [[Project_Definition|Project Definition]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]], [[Project_Delivery_Methods|Project Delivery Methods]].''

''See also [[Program_Management_in_Civil_Engineering|Program Management in Civil Engineering]], [[Project_management|Project Management]] ...''

== Basic considerations ==

[[#top|Top of current page]]

== Semantic, Epistemic and Logical frameworks ==

The semantic, epistemic and logical frameworks for the concept of civil-engineering projects have multiple issues arising largely from interchangeable usage and lack of definition.

=== Semantic framework ===

* The semantic problems largely revolve around distinguishing between [[Program_Management_in_Civil_Engineering|civil engineering programs]], projects, and portfolios of projects.<ref name="Note1">Internal note in original RiskWiki draft.</ref>

=== Epistemic framework ===

There are frameworks for distinguishing different types of civil-engineering knowledge as well as that of related disciplines and sciences, and for describing [[Discipline_specific_knowledge_domains_and_models_for_Civil_Engineering#Dimensions_of_Civil_Engineering_Knowledge|knowledge components and knowledge architecture]].

Key aspects:

* The **hierarchical structure** of civil-engineering knowledge.
* The **process / sequential nature** in which knowledge is developed and, most importantly, how it is applied.
* Models are grounded in underlying knowledge domains.

Knowledge models can be developed as **ontologies** or **taxonomies**, with important differences:

* '''Taxonomy''': practice and science of classification; does not necessarily require hierarchy; not very useful for problem solving outside formal education.
* '''Ontology''': the study of basic nature, essential properties, and relationships; disciplines like civil engineering construct ontologies to limit complexity, organize information, and increase the value of knowledge for solving problems.

:'''Civil engineers are skilled at constructing engineering ontologies that control complexity, organize data, produce information and knowledge. These ontologies are useful for solving engineering problems, sequencing critical decisions, and sharing and reusing knowledge – thereby allowing the civil engineer to demonstrate mastery of the professional's role in project execution and delivery.'''

Given this development, an [[Professional_Concepts_Portal#Ontological_models_of_Civil_Engineering_Knowledge_and_Meta-knowledge|onto-logic knowledge model]] for civil-engineering (CE) projects requires:

* [[Professional_Concepts_Portal#Discipline_Specific_Foundational_Outcomes|Discipline-specific foundational outcomes]]
* [[Professional_Concepts_Portal#Discipline_Specific_Technical_Outcomes|Discipline-specific technical outcomes]]
* [[Professional_Concepts_Portal#Project_Foundational_Outcomes|Project foundational outcomes]]
* [[Professional_Concepts_Portal#Project_Specific_Technical_Outcomes|Project-specific technical outcomes]]
* [[Professional_Concepts_Portal#Project_Execution_Outcomes|Project-execution outcomes]]

=== Logical framework ===

The logical framework for civil-engineering projects has several key concepts:

* Projects are sets of coordinated activities and processes directed towards a common purpose, objective or goal.
* Civil-engineering projects are embedded in broader programmatic, regulatory and institutional contexts.
* Project-level models, processes and controls must align with discipline-level and program-level ontologies.

[[#top|Top of current page]]

== Practice frameworks for Civil Engineering Projects ==

=== PMIBoK ===

PMI defines a project as:

: “…a temporary endeavor undertaken to create a unique product, service, or result.”<ref>Project Management Institute, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th ed., 2013, Glossary, p. 552.</ref>

PMI notes that:

* “Temporary” does not mean short in duration.
* Projects may provide tangible or intangible outcomes.
* Projects may contain repetitive artifacts and processes, but this does not change “the fundamental, unique characteristics of the project work.”

'''Commentary:'''

* The term is defined in a loose, generic context and is not fully reflective of civil-engineering practice.
* Civil-engineering projects are sets of activities and processes organized and directed towards a common purpose or goal, resulting in a **tangible physical facility**.
* They are undertaken by a project sponsor and assigned to a **project office** held responsible for project execution.<ref name="Note2">This definition was developed from that for programs contained in U.S. OMB Circular A-109 (Major Systems Acquisition). See also Kerzner, Harold R. ''Project Management: A Systems Approach to Planning, Scheduling, and Controlling''. John Wiley & Sons, 2013, p. 56.</ref>

This is a much stronger but narrower definition than that envisaged by PMI.

=== International Organization for Standardization (ISO) ===

In its quality-management system standard, ISO defines a project as:

: “…a unique process (3.4.1), consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements (3.1.2), including the constraints of time, cost and resources.”<ref>International Organization for Standardization (ISO), ISO/FDIS 9000:2005, Sec. 3.4, “Terms relating to process and product”, p. 11.</ref>

'''Commentary:'''

* None – this definition is compatible with the civil-engineering perspective, though still abstract.

[[#top|Top of current page]]

=== American Society of Civil Engineers (ASCE) ===

Although ASCE does not formally define “project”, the concept is deeply embedded in ASCE's vision of civil engineering. In **Vision 2025**:

* “Project” is mentioned many times.
* Civil engineers are said to provide the “essential underpinnings of design and project oversight.”<ref>ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 3.</ref>
* Civil engineering will continue to focus on “the definition, selection, and implementation of projects.”<ref>ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 59.</ref>

'''Commentary:'''

As noted above in the PMI discussion:

* Civil engineering executes projects in a more structured and prescribed manner than many of the generic “projects” envisaged in generic PM frameworks.
* However, there is nothing in PMI or ISO definitions that is inherently incompatible with ASCE’s vision.
* Rather, PMI/ISO definitions are more abstract; civil engineering operates within a deeper but narrower range of practices.

This reflects unique aspects of civil-engineering practice such as:

* **Physicality**
* **Labor specialization**
* **The unique role of engineering design**

; Physicality

Civil engineers execute **physical projects**:

* They may start as planning concepts or research but result in modifying the built or natural environment.
* Software starts as a thought product and remains so; civil-engineering projects result in physical objects and processes.

In physical domains, there is no “virtual” integration; systems must be physically integrated under constraints such as the urban environment.

:'''Civil engineers transform thought into physical objects that exist in many places in the global economy and then integrate them into the executed project.'''

; Labor Specialization

Civil-engineering project execution involves:

* multidisciplinary and multi-skilled teams,
* strong craft/trade components,
* complex logistics and regulatory constraints.

This fragmentation along divisions of labor and specialization:

* increases complexity,
* interacts with regulations on manufacturing, transport and use of labor,
* makes phasing more intricate.

:'''Civil engineers practice in heterogeneous project-team environments that are multidisciplinary and with multiple levels of specialization – and a tendency toward blurred professional responsibilities.'''

; Engineering Design

Project execution in the built environment has a heavy emphasis on **public safety and welfare**, which is not always present in generic software or business projects.

A closer parallel exists in:

* [[wikipedia:Medical_device|medical devices]] using [[wikipedia:Medical_software|software controls]] – heavily regulated for reliability.

With physicality and specialization:

* Civil engineers play a key and regulated role in developing designs to be implemented by other teams.
* These must be physically integrated on site and systemically integrated into the facility for acceptance.
* This imposes a functional structure to project execution unlike most software-development scenarios.

:'''Project execution must be accomplished in functional, cascading phasing: the project is conceptualized, then designed, procured, mobilized, physically integrated, systemically integrated into the facility, and finally accepted by the customer.'''

Returning to the PMI framework:

* Early in project execution, civil-engineering life cycles are predominantly **predictive** or plan-driven.
* As the life cycle is decomposed level by level into contract packages, phasing below that level becomes a **mix** of predictive and adaptive development.

While there is flexibility in:

* overlapping phases,
* decomposing phases into sub-phases,
* decomposing into contract packages and then into work packages and work units,

the **fundamental process** remains the same.

Every individual work element at any level must be:

* scoped,
* designed,
* procured,
* mobilized,
* physically and systemically integrated, and
* accepted by the customer.

Any one functional item might be performed by:

* one individual, or
* a team of civil engineers across multiple organizations,

but the design must be integrated to the point it can serve as a basis for procurement and construction contracts.

:'''With this core role of engineering design in project execution, civil engineers must learn to maintain the integrity and adequacy of the design throughout various project-phasing modes and at any depth of sub-phasing – from contract packaging down to individual work packages.'''

:'''Civil engineering adds value above and beyond its reserved core roles in design by predictably and reliably integrating procurement, construction and commissioning considerations into the executed project.'''

[[#top|Top of current page]]

== Programmatic frameworks for Civil Engineering Projects ==

=== Office of Management and Budget (OMB) ===

(Under construction.)

=== Department of Defense (DOD) ===

(Under construction.)

=== Department of Energy (DOE) ===

DOE’s program guidance notes that all DOE projects share:

: “…a single, vital commonality: the preparation, documentation, approval, implementation, and verification of '''project requirements'''.”<ref>Project Management Practices, ''Engineering Support and Requirements Generation, Analysis, and Use'', Sec. 2.0 Requirements Generation (Rev. E, June 2003).</ref>

These requirements define the framework for going forward with detailed descriptions and design necessary to meet the performance (products, deliverables) established in the Mission Need Statement (MNS).

:Requirements define and describe the extent to which a function(s) must be executed, and are generally measured in terms of quantity, quality, coverage, timelines, safety, environmental, products, deliverables, etc. (DOE, ibid.)

=== Department of Transportation ===

==== Federal Aviation Administration (FAA) ====

(Under construction.)

==== Federal Transit Administration (FTA) ====

FTA’s Project and Construction Management (PCM) guidance contains multiple references to requirements and phases, while PMI also has many references and ASCE’s BOK uses different terminology. In particular, ASCE does not use terms like “project phase” or “project delivery” in its BOK, which can be problematic for stakeholders and sponsors trying to align the frameworks.

==== Federal Highway Administration (FHWA) ====

(Under construction.)

== Regulatory framework for Civil Engineering Projects ==

(Under construction.)

[[#top|Top of current page]]

== Legislative framework for Civil Engineering Projects ==

(Under construction.)

[[#top|Top of current page]]

== Limitations of the definition ==

(Under construction.)

== Working definition of the term ==

A generic definition consistent with ISO and PMI:

: “A '''project''' is a unique process consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve a defined set of objectives, conforming to specific requirements, including the constraints of time, cost and resources.”

Given the discussion above, a narrower definition for **civil engineering** is:

: “A civil-engineering '''project''' is a unique set of activities and processes that is organized and directed towards a common purpose, objective or goal. It is undertaken by a project sponsor and assigned to a project office held responsible and accountable for project execution under constraint.”<ref name="Note3">Definition derived from OMB Circular A-109 and Kerzner (2013), as noted above.</ref>

[[#top|Top of current page]]

== Beneficial Outcomes ==

(Under construction.)

[[#top|Top of current page]]

== See also ==

* [[wikipedia:Project|Project]] (Wikipedia)

== Learning Outcomes ==

Learning outcomes concern the skills, knowledge and abilities that can be demonstrated when the content of this article has been mastered by the reader.

== Notes ==

<ol class="references">
<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text"></span></li>
<li id="cite_note-3"><span class="mw-cite-backlink"><a href="#cite_ref-3">↑</a></span> <span class="reference-text">This definition was developed from that for programs contained in U.S. OMB Circular A-109 (Major Systems Acquisition). See also Kerzner, Harold R. ''Project Management: A Systems Approach to Planning, Scheduling, and Controlling''. John Wiley & Sons, 2013, p. 56.</span></li>
<li id="cite_note-8"><span class="mw-cite-backlink"><a href="#cite_ref-8">↑</a></span> <span class="reference-text">Internal test note in original RiskWiki draft.</span></li>
</ol>

== References ==

<ol class="references">
<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a></span> <span class="reference-text">Project Management Institute, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th ed., 2013, Glossary, p. 552.</span></li>
<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a></span> <span class="reference-text">International Organization for Standardization (ISO), ISO/FDIS 9000:2005, Sec. 3.4 “Terms relating to process and product”, p. 11.</span></li>
<li id="cite_note-5"><span class="mw-cite-backlink"><a href="#cite_ref-5">↑</a></span> <span class="reference-text">ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 3.</span></li>
<li id="cite_note-6"><span class="mw-cite-backlink"><a href="#cite_ref-6">↑</a></span> <span class="reference-text">ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 59.</span></li>
<li id="cite_note-7"><span class="mw-cite-backlink"><a href="#cite_ref-7">↑</a></span> <span class="reference-text">Project Management Practices, ''Engineering Support and Requirements Generation, Analysis, and Use'', Sec. 2.0 Requirements Generation (Rev. E, June 2003).</span></li>
</ol>

[[Category:Definition]]

Management plans and sub-plans

2025-11-29T22:54:47Z

Pooyan: Restored “Management plans and sub-plans” from archived RiskEngineering.org (Wayback, 2017).

'''<big>This page is under construction ...</big>'''

''See also [[Project_Execution|Project Execution]], [[Project_Development|Project Development]], [[Project_Definition|Project Definition]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]], [[Project_Delivery_Methods|Project Delivery Methods]].''

''See also [[Program_Management_in_Civil_Engineering|Program Management in Civil Engineering]], [[Civil_Engineering_Projects|Civil Engineering Projects]], [[Project_management|Project Management]] ...''

== Article Overview ==

It is important to note that the purpose of this article is **not** to render a current and fully accurate characterization of the regulatory framework for any particular Federal agency. The purpose of this article is to serve as a source of information on good practices and as a resource to engineering professionals.

Readers should be aware that agency practices evolve over time; the information presented here represents a “snapshot in time” for a particular agency and possibly a specific program.

Again, please note our [[Risk_wiki:About#Website_Terms_of_Use|site terms of use]]. Even though this site may characterize and analyze government-agency policy and practices in conformance with our guidelines, users are reminded that RiskWiki is **not** an official government site.

* If you are in need of engineering advice, seek individual engineer advice and DO NOT rely on RiskWiki. '''RiskWiki IS NOT YOUR ENGINEER.'''
* Similarly, if you are in need of legal advice, seek individual attorney advice and DO NOT rely on RiskWiki. '''RiskWiki IS NOT YOUR LAWYER.'''

== Basic considerations ==

Process, as documented in management plans, plays a pivotal role in both ASCE’s and PMI’s Bodies of Knowledge, and in civil-engineering practice.

== Semantic, Epistemic and Logical frameworks ==

''(Under Construction)''

The semantic, epistemic and logical frameworks for the concept of **process** in civil-engineering projects have several dimensions. Problems often arise from interchangeable usages or lack of definition. Examples include:

* lack of clear distinction between “artifact” and “model”,
* interchangeable use of function / process / workflow / procedure / routine,
* lack of definition around process diagrams, maps and models, layers / levels.

=== Semantic framework ===

The most important semantic issue is the definition of **process** itself – particularly:

* process vs system vs model, and
* process vs procedure.

; Process

Process is often defined as having **inputs, outputs**, and the **energy** required to transform or “work” those inputs into outputs. The concept of work implies a passage of time, so a process takes real time to perform its associated action. The process also requires space for input/output objects and transforming objects to exist; therefore it requires real space.

Other authors describe a process as a set of structured tasks that result in specific services or products to meet certain goals for a particular set of actors.

The traditional view is the IPO (input–process–output) approach. Process-modelling languages are often grouped into categories such as:

* transformational
* conversational
* role-oriented
* constraint-based
* system-dynamics–oriented

Civil-engineering processes are typically executed in an organizational context. A critical factor in discussing process is the **state** of the process:

* the current state (a descriptive or “as-is” model), and
* a prescriptive or predictive future state.

; Process vs System

A **system** differs from a process in that systems provide the **context** in which every process can be described and analysed.

From this follow several important properties for processes in civil-engineering projects:

==== Process set membership ====

Process set membership refers to the ability to control participation in process activities and, ultimately, changes of state for individual variables. There must be at least one potential process element that is effectively excluded by process documentation throughout the process-execution life cycle.

* As project complexity increases, the process’s ability to control its set membership is “loaded and deforms” (in a structural-analogy sense).
* Inability to control set membership for **control processes** can lead to failure under such loading.

:'''This has serious implications for any project-control strategy and solution.'''

==== Projects as unique process sets ====

Both PMI and ISO identify projects in terms of processes. In a civil-engineering context this can be interpreted as a second network (parallel to the schedule time network with critical paths).

* In the simplest case, a project may be represented by a single process.
* As complexity increases, additional processes are added.

This raises questions such as:

* How do process elements achieve “end-to-end” hookups?
* Can we implicitly assume that all process outputs always match all required successor inputs?
* What about periods where one activity has a break before execution of the successor (schedule “float”)?

In the simplest case, there is a one-to-one mapping between any arbitrary project activity and its associated process. As complexity increases, the relationship tends towards a many-to-many architecture.

:'''This likewise has serious implications for any project-control strategy and solution.'''

==== Process interfaces ====

Process interfaces require **input and output acceptance criteria**. Matching up output states (“as-executed”) to input requirements (“as-is”) requires verification – itself a process.

==== Process constants and variables ====

* **Process constants** are process elements, properties or characteristics that do not vary over process execution.
* Any process element that does vary over execution is a **process variable**.

Any process variance or non-variance associated with a project material state should be identified, documented and communicated at appropriate times.

==== Process state ====

State plays a critical role in the concept of civil-engineering process:

* ordinary usage treats the concept of process as if it had a single “state”,
* but the concept may cover many variables, each with its own state.

The process may change all variables within a framework of variables and constants. In civil-engineering processes, models (formalized concepts) use several project variables (scope, cost, etc.).

; Outputs, outcomes, products, deliverables

Output states are fundamental end-points of any arbitrary process. In transitioning from “as-is” to “as-executed”:

* project variables change state (time, cost, resources, etc.),
* complete knowledge of all variable state changes is impossible and inherently uncertain.

We can distinguish:

* **Outcomes** – a subset of all output states that can be identified, documented and verified using civil-engineering knowledge.
* **Products** – a subset of outcomes that, regardless of execution context, can be formally described and communicated using civil-engineering knowledge.
* **Deliverables** – a subset of products produced in a specialized execution context and formally described and communicated using contracting techniques and civil-engineering knowledge. Deliverables often function as contractual or chartered milestones representing specific types and amounts of work to be “delivered”.

Deliverables are also important communications with clients. They create spaces in which teams and clients can negotiate, adjust, and mediate their diverse perspectives and understandings, and are often “the space in which consulting actually takes place”.

:'''Deliverables play a key role in the learning and collaborating processes at the heart of project work itself.'''

==== Process equilibrium, stability and instability ====

A process can be said to be in **equilibrium** when a condition of balance exists between opposing work efforts. For a generalized notion of process, any concept of equilibrium is meaningful only within a framework of constraints and over time.

* A fully “equilibrious” process (completely recoverable state, no residual effects) is a theoretical ideal and does not exist in real projects.
* In practice, process constituents may be disturbed and then either able or unable to recover their predecessor state.

**Stability** refers to a process’s ability to recover, at least partially, to a predecessor state after disturbance.

* Stable processes resemble structural elements undergoing elastic bending: when loading is removed, the system recovers sufficiently to be considered serviceable.
* Instability corresponds to exceeding elastic limits – plastic deformation of processes that propagates or cascades through other processes.

:'''Process stability (and the avoidance of cascading failures) is a key element of civil-engineering knowledge and has serious implications for any project-control strategy and solution.'''

==== Process control ====

Stable processes are a subset of all processes. Civil-engineering practice requires:

* understanding process stability, and
* increasing reliability in handling disturbances, detecting material variations, intervening later in execution, and recovering more of the predecessor state with fewer resources.

This leads to a further partitioning into **control processes** – those that can be documented and deliver reliably and predictably.

* A core skill is the ability to identify material variable states and plan process-variable state changes that occur reliably and predictably.
* In this sense, “process variables” are congruent with “core” project variables (scope, cost, schedule, risk).

The ideal civil-engineering process:

* tightly controls its set membership,
* executes repeatedly with core-variable state changes that are detectable and within predicted ranges,
* localizes changes to selected variables with minimal cascading into dependent processes.

This is the conceptual basis for **process** as a fundamental element of **management controls**.

==== Process models ====

A **process model** is a semantically closed abstraction of a process – a model of how the process behaves, under what assumptions, and with what inputs/outputs.

Key properties:

* Multiple, semantically equivalent views (different disciplinary perspectives) that remain consistent and compatible.
* Decomposition into successive sub-model layers that remain logically and functionally equivalent in aggregate.
* Documentation of state changes, resource consumption, assumptions and dependencies.
* Restricted application domain – good engineering models tightly constrain their interpretation to avoid ambiguous or non-functional outcomes.

==== Process architecture, artifacts, patterns, and documentation ====

* **Process architecture** – a set of critical decisions about the structure, components, relationships and properties of the process model. These decisions constrain how processes aggregate into larger systems and decompose into sub-processes.
* **Artifacts** – any information created, produced, changed or used as part of project execution; the most important artifact is often the process model itself.
* **Patterns** – reusable generic components or configurations in process architectures, capturing previous solutions to common problems.
* **Process documentation** – explicit and implicit documentation (formal and informal) providing organizational memory and reference baselines.

**Process formality** ranges from fully formal (“white-box”) to fully informal (“black-box”), with many “grey-box” states in between.

==== Process meta-knowledge and layers ====

**Process meta-knowledge** – knowledge about processes (rather than within a process) – allows statements about:

* how processes aggregate and decompose,
* how they form chains and networks, and
* how components align and function.

Civil engineers rely on professionally validated meta-knowledge to assume that processes can be decomposed and aggregated in ways that remain meaningful and controllable.

**Layers** are patterns where components are grouped at similar levels of generality and stability. In civil engineering, the analogue of layer is often **level**.

Examples:

* Upper layers: discipline knowledge (ASCE BOK), practice documentation, artifact libraries.
* Intermediate layers: project-level processes, geographic / functional layers, contract layers.
* Lower layers: work-package level processes, down to the smallest units of execution.

:'''Layers are not the same thing as increments or iterations.'''

**Workflow** in software engineering is often treated as the “executed” instance of a documented process. PMI barely uses the term; ASCE BOK almost not at all. For RiskWiki, workflow can be thought of as a realized execution path through a defined process.

[[#top|Top of current page]]

=== Epistemic framework ===

No epistemic issues are analysed in detail in this article; rather, the focus is on definitions and logical structure.

=== Logical framework ===

The logical framework for civil-engineering processes has several key concepts:

* Projects are sets of processes. ISO and PMI each define process families.
* Project management is the application of knowledge to project activities using processes adapted for creating deliverables.
* Organisations must identify the external and internal factors (positive and negative) that are relevant to their context and that can affect their ability to achieve the intended outcomes of their management systems.

:'''The overall objective of the civil-engineering approach to project processes is to develop solutions that support delivering projects reliably and predictably.'''

[[#top|Top of current page]]

== Practice frameworks in Processes ==

=== Policy Framework ===

A number of U.S. Federal agencies require a **Project Management Plan (PMP)** for their major capital projects, including:

* Federal Transit Administration (FTA)
* Federal Railroad Administration (FRA)
* U.S. Army Corps of Engineers (USACE)
* U.S. Department of Energy (DOE), etc.

This section discusses selected agencies and their approach to project management using PMPs. Again, agency practices evolve over time and information here represents a snapshot in time.

Examples:

* [[Project_Management_Plan_Policy_Framework_for_FTA_projects|Federal Transit Administration – New Starts Program]]
* FRA’s Intercity Passenger Rail Service authorizations under Public Law 110–432 (see FRA / PRIIA references)

=== Further Guidance ===

(Under construction.)

=== Beneficial Outcomes ===

(Under construction.)

=== Working definition of the term ===

(Under construction.)

=== Limitations of the definition ===

(Under construction.)

=== See also ===

Related Wikipedia articles:

* [[wikipedia:Project_plan|Project plan]]
* [[wikipedia:Risk_management_plan|Risk management plan]]
* [[wikipedia:Test_and_evaluation_master_plan|Test and evaluation master plan]]

=== Notes ===

(Under construction.)

=== References ===

* Introduction to Business Process Management, Alan McSweeney, 2010. Based on the Association of Business Process Management Professionals (ABPMP) BPM Common Body of Knowledge.
* Krogstie, John. "Perspectives to process modeling." in ''Business Process Management'', Springer, 2013.
* Carlsen, Steinar. "Action port model: A mixed paradigm conceptual workflow modeling language." Cooperative Information Systems, 3rd IFCIS Int’l Conference, 1998.
* De, Robert. ''Linguistic Theory: The Discourse of Fundamental Works''. Routledge, 2014. (Discussion of systems and context.)
* Rogers, Priscilla, Lisa Pawlik, and Barbara Shwom. "The Role of Deliverables in Project Work." Ross School of Business Paper 1267 (2015).
* OED Online, entries for “equilibrium”, “work”, “stability”, Oxford University Press, 2016.
* Tarski, Alfred – work on semantic closure.
* Medić, S., Karlović, B., & Cindrić, Z. "New Standard ISO 9001:2015 and its effect on organisations." ''Interdisciplinary Description of Complex Systems'', 14(2), 2016.
* Public Law 110–432 (PRIIA), 16 Oct 2008, 122 Stat. 4935.

[[Category:Definition]]

Project Life Cycle and Phase Models

2025-11-29T21:12:31Z

Pooyan: Restored “Project Life Cycle and Phase Models” from archived RiskEngineering.org (Wayback, 2017).

'''<big>This page is under construction ...</big>'''

''See also [[Project_Execution|Project Execution]], [[Project_Development|Project Development]], [[Project_Definition|Project Definition]], [[Project_Delivery_Methods|Project Delivery Methods]].''

''See also [[Program_Management_in_Civil_Engineering|Program Management in Civil Engineering]], [[Civil_Engineering_Projects|Civil Engineering Projects]], [[Project_management|Project Management]] ...''

== Basic considerations ==

"Life cycles as a general construct are not new to organizational literature." They are often employed to analyze strategic decision priorities and organizational structures (Chandler, 1962). Of particular interest in this article is the applicability of the life-cycle concept to project management (Adams & Bamdt, 1983; King & Cleland, 1983).

Classic models have described three to five distinct stages in project implementation, typically:

* project planning or initiation
* project execution or development
* project termination

The purpose of this article is to establish a framework and practices for delivering civil-engineering projects in a time-phased sequence in accordance with project-stakeholder requirements and expectations.

== Semantic, Epistemic and Logical frameworks ==

''(Under Construction)''

[[File:2016_10_30_Project_Development_definition_execution_model.png|thumb|400px|The Project triangle]]

The semantic, epistemic and logical frameworks for the concept of project definition in civil-engineering projects have several dimensions.

* The semantic problems are twofold.
* …

The logical framework for the concept of project life cycle and phase models in civil-engineering projects has several dimensions:

* The first is the interchangeable usage of “project life cycle” and “project phasing”.
* Project delivery is accomplished within a framework implemented through a series of milestone events (“kill points” or “off-ramps”) where the project sponsor, in an exercise of decision authority, determines whether the project has demonstrated its readiness to go forward. This decision is often made in the context of authorizing the project to transition to the next life-cycle phase and is supported by a number of reviews.
* Project implementation is executed within a governance and internal-controls structure that meets project-sponsor requirements and objectives.

''(Under Construction)''

The semantic, epistemic and logical frameworks for the concept of project development in civil-engineering projects have several dimensions. The problems are interchangeable usages or lack of definition.

=== Semantic framework ===

* '''Artifact''' – in software and systems engineering, an [[wikipedia:Artifact_(software_development)|artifact]] is a general term for any kind of information created, produced, changed or used by workers in developing the project or system. There are two kinds: engineering artifacts and management artifacts. One important artifact is the model.
* '''Workflow''' – (definition under construction).

=== Epistemic framework ===

There are frameworks for distinguishing different types of civil-engineering knowledge as well as knowledge in related disciplines and sciences, and for describing [[Discipline_specific_knowledge_domains_and_models_for_Civil_Engineering#Dimensions_of_Civil_Engineering_Knowledge|knowledge components and knowledge architecture]]. The key aspect of civil-engineering knowledge is its hierarchical structure and the process / sequential nature in which knowledge is developed and, most importantly, how it is applied. Its models are grounded in underlying knowledge domains.

Knowledge models can be developed as ontologies or taxonomies:

* '''Taxonomy''' is the practice and science of classification without necessarily requiring a hierarchical structure. Taxonomies are not very useful for problem solving outside of formal education.
* '''Ontology''' concerns the basic nature, essential properties, and relationships. Disciplines like civil engineering construct ontologies to limit complexity and organize information and thereby increase the value of knowledge for solving problems.

:'''Civil engineers are skilled at constructing engineering ontologies that control complexity, organize data, produce information and knowledge. These ontologies are useful for solving engineering problems, sequencing critical decisions, and sharing and reusing knowledge – thereby allowing the civil engineer to demonstrate mastery of the professional’s role in project execution and delivery.'''

Given this development, an [[Professional_Concepts_Portal#Ontological_models_of_Civil_Engineering_Knowledge_and_Meta-knowledge|onto-logic knowledge model]] for project execution requires:

* [[Professional_Concepts_Portal#Discipline_Specific_Foundational_Outcomes|Discipline-specific foundational outcomes]]
* [[Professional_Concepts_Portal#Discipline_Specific_Technical_Outcomes|Discipline-specific technical outcomes]]
* [[Professional_Concepts_Portal#Project_Foundational_Outcomes|Project foundational outcomes]]
* [[Professional_Concepts_Portal#Project_Specific_Technical_Outcomes|Project-specific technical outcomes]]
* [[Professional_Concepts_Portal#Project_Execution_Outcomes|Project-execution outcomes]]

=== Logical framework ===

The logical framework for project development has several key concepts:

* Project development, as a kind of [[wikipedia:Universal_set|universal set]], includes managed and unmanaged operations, resulting in both effective and ineffective project activity.
* Project development is multi-dimensional, with axes consisting of sub-frameworks that are themselves layered.
* The major sub-frameworks include variables (scope, cost, schedule – the “core variables”), performance frameworks, and control frameworks.
* These frameworks effectively partition the universal set into smaller and smaller subsets, with each framework representing a “project layer”; the control layer being the topmost layer.
* By definition, project tasks are a subset of project activities, which in turn are a subset of the universal set: project execution.

:'''The overall objective of the civil-engineering approach to project development is to partition the universal set of project execution into a series of more and more detailed subsets and sub-subsets which, when combined with carefully designed “layers”, deliver projects reliably and predictably.'''

[[#top|Top of current page]]

== Practice frameworks for Project Life Cycle and Phase Models ==

It is helpful to lay a foundation for this discussion with PMI’s concept of life cycle, in order to differentiate the civil-engineering framework for project delivery from that used in software development. This is important because research in a number of fields – beyond engineering – has confirmed the role of project life cycle as a key predictor of project success.

It is also important for civil engineering to understand the differences between project life cycle and [[Program_lifecycle|program life cycle]].

=== Project Management Institute BoK ===

PMI defines a **project life cycle** as a series of phases that the project passes through from its initiation to its closure, and notes that it provides the basic framework for managing the project. A project may be divided into a number of phases in order to satisfy project objectives or stakeholder governance.

PMI defines a **project phase** as a set of logically related project activities that results in the completion of one or more [[wikipedia:Deliverable|deliverables]]. Project phases also represent natural points to reassess progress and, if necessary, to terminate the project (“kill points”).

As an object, PMI’s vision is that a project life cycle can be decomposed into a set of more detailed objects – the project-phase objects. This is important for civil engineering because delivering projects entails decomposing project life cycles into phases with unique but common elements and complex characteristics. This decomposition process is very important in civil engineering.

In PMI's vision, phasing is typically sequential but can overlap. The simplest life cycle is a single-phase project. Projects with more than one phase may remain simple when the phases are sequential and each follow-on phase can only commence when the previous one is complete. Complex projects are multi-phased and the phases may overlap or possess varying degrees of dependency, or be parallel.

Such phasing can:

* require additional resources to allow work to be done in parallel,
* increase risk, and
* result in rework if a subsequent phase progresses before accurate information is available from the previous phase.

Project life cycles can range from completely [[wikipedia:Agile_management|adaptive]] to completely predictive or plan-driven:

* **Predictive or fully plan-driven** life cycles identify the core project variables as early as practically possible.
* **Adaptive / change-driven / agile** life cycles manage high levels of change and intensive stakeholder interaction.

=== International Organization for Standardization (ISO) ===

The [[wikipedia:International_Organization_for_Standardization|International Organization for Standardization (ISO)]] in its [[wikipedia:ISO_21500|ISO 21500]] document provides overarching guidance on project management. It is not intended for certification/registration purposes; instead, it offers a high-level description of concepts and processes that are considered to form sound practice in project management.

ISO defines a project life cycle as a “defined set of phases from the start to the end of the project”.

ISO elaborates that:

* Project phasing is determined by governance and [[Management_control|management control]] requirements in a logical sequence.
* Each phase has a defined start and end, and uses inputs to produce [[wikipedia:Deliverable|deliverables]].
* All work within a phase is accomplished by processes.

ISO’s view of phasing as a management tool is very similar to PMI’s.

=== Software Development Process ===

The Unified Software Development Process or [[wikipedia:Unified_Process|Unified Process (UP)]] is an iterative and incremental software [[wikipedia:Iterative_and_incremental_development|development]] process framework. As a process, it provides the guidance and necessary steps to implement a software project; i.e., “a complete set of activities needed to transform users’ requirements into a product; a process is a template for creating projects”.

The Unified Process is component-based – made up of [[wikipedia:Component-based_software_engineering#Software_component|software components]] defined as “a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces”.

Unlike some other approaches, the Unified Process uses “models” (semantically-closed abstractions of a system) to provide a visualization of work products (“artifacts”).

The Unified Process repeats over a series of software product releases or “cycles”. Each cycle consists of four phases:

* inception
* elaboration
* construction
* transition

Each cycle is decomposed into phases, which are decomposed into planned sequences of one or more “increments”, each composed of one or more iterations.

:'''Incrementing the project means growth in the product; iterations are steps in the workflow.'''

UP is iteration-centric: main planning factors are at the iteration level, and the increment is a function of its underlying iterations.

To be effective, this must be performed in a controlled and planned manner.

Some key ideas:

* Use cases (grouped to extend product functionality) are chosen to define increments.
* Each iteration addresses the most important risk at that stage in development.
* Not all increments are additive – some are exploratory and may be reworked.
* Each increment requires refinement and progressive elaboration of the requirements documentation.

==== Project Execution (in UP terms) ====

To achieve the greatest economy, the UP-style project executes only those iterations required to reach the increment goal or success criteria (“exit criteria”), and tries to sequence iterations logically.

Early development may include increments and iterations that are not additive, but over time increments and iterations become increasingly additive. Project success depends on executing in this manner. If an iteration fails to meet the success criteria, the project tries another approach and “re-increments” or reworks the work package.

Each additional iteration or re-increment affects core project variables – cost, schedule, quality, risk. Minimizing unnecessary rework is a core activity of risk management.

=== Civil Engineering practice frameworks ===

The civil-engineering development process is work-package-based, with defined properties, relationships, and interfaces. It involves parallel increments with overlapping iterations – but here we are progressing a physical facility rather than a purely software product.

PMI’s life-cycle / phasing framework is conceptually simple: one can deliver a project in a single phase, or in multiple sequential phases. This offers a sound foundation to illustrate how civil engineering operates in a more robust and dense environment, where:

* Project life cycles possess a diffused mix of phasing,
* There are extensive levels of decomposition through sub-phasing into contract packages and down to work-package / team level, and
* Phasing is driven by governance and management-control requirements in regulated environments.

This complexity also reflects distinctive aspects of civil-engineering practice:

* **Physicality**
* **Labor specialization**
* **The unique role of engineering design**

; Physicality

Civil engineers deliver physical projects. They may start as planning concepts or fundamental research, but they result in the application of resources (tangible and intangible) to modify the built or natural environment. Software, by contrast, remains a thought product implemented in code.

Civil engineering, like mechanical and electrical engineering, is about delivering physical projects that may contain advanced technology but are ultimately physical objects. Engineering is transformative: in physical domains there is no “co-location in the cloud”; systems must be physically integrated under constraints such as the urban environment.

:'''Civil engineers transform thought into physical objects that exist in many places in the global economy and then integrate them into the delivered project.'''

; Labor Specialization

Project delivery involves multidisciplinary and multi-skilled teams that are logistically and physically integrated, often with significant craft labor. This fragments phasing along lines of division of work and specialization, and interacts with regulatory environments, manufacturing of physical goods, logistics into constrained sites, and labor regulations.

:'''Civil engineers practice in heterogeneous project-team environments that are multidisciplinary, with multiple levels of specialization and often blurred professional responsibilities.'''

; Engineering Design

Project delivery in the built environment has a strong emphasis on public safety and welfare. A closer parallel in software is [[wikipedia:Medical_device|medical devices]] using [[wikipedia:Medical_software|software controls]], which are subject to strict reliability regulations.

With physicality and specialization, civil engineers play a key and regulated role in developing designs to be implemented by other teams and physically integrated on site, and then systemically integrated into the facility for acceptance. This imposes a functional structure to project delivery that is unlike most software development.

:'''Project delivery must be accomplished in functional, cascading phasing: the project is conceptualized, then designed, procured, mobilized, physically integrated, systemically integrated into the facility, and finally accepted by the customer.'''

Returning to the PMI framework:

* Early in project delivery, civil-engineering life cycles are predominantly predictive or plan-driven.
* As the life cycle is decomposed down to contract packaging, below that level phasing becomes a mix of predictive and adaptive development.

While there is flexibility in overlapping phases and decomposing into sub-phases, contract packages, work packages, and work units, the fundamental process remains the same:

* Each work element must be scoped, designed, procured, mobilized, physically and systemically integrated, and accepted.

Any such element may be carried out by one person or by teams from multiple organizations, but in the end the design must be integrated to the point it can serve as a basis for procurement and construction.

:'''With this core role of engineering design in project delivery, civil engineers must be skilled at maintaining the integrity and adequacy of the design across various phasing modes and at any depth of sub-phasing – from contract packaging down to individual work packages.'''

:'''Civil engineering adds value above and beyond its reserved core roles in design by predictably and reliably integrating procurement, construction and commissioning considerations into delivered work.'''

== Programmatic frameworks for Project Life Cycle and Phase Models ==

In some guidance documents (e.g. FTA’s Project and Construction Management guidelines), “project phase” appears frequently, while in ASCE’s Body of Knowledge the term may not be used explicitly. For stakeholders and sponsors, this mismatch between project-management language and civil-engineering education / professional frameworks can be problematic, reinforcing the need for clear life-cycle and phase-model concepts.

== Regulatory framework for Project Life Cycle and Phase Models ==

''(Under Construction)''

== Further Guidance ==

(Under construction.)

== Beneficial Outcomes ==

* Civil engineers are knowledgeable and skilled at analyzing stakeholder expectations and project objectives.
* Civil engineers can design project life cycles that are multiphase – with overlapped, discontinuous or independent phases – and that use a professionally balanced mix of adaptive, hybrid and predictive approaches with an acceptable likelihood of meeting project objectives.

(See the main [[Civil_Engineering#ASCE_Definition_of_Civil_Engineering|Civil Engineering]] article.)

== Working definition of the term ==

(Under construction.)

== Limitations of the definition ==

(Under construction.)

== See also ==

* [[wikipedia:Project_management|Project management]]
* [[wikipedia:Systems_development_life_cycle#Life_cycle|Software life cycle]]

Google searches on “project delivery” – for example:

* [https://www.google.com/search?tbm=isch&q=project%20lifecycle%20phases Hand-drawn class notes]

== Notes ==

* In U.S. DOE usage, “critical decisions” mark key points in a project life cycle. NASA refers to analogous points as “key decisions”.
* Additional notes and clarifications to be added.

== References ==

* Pinto, Jeffrey K., and John E. Prescott. "Variations in critical success factors over the stages in the project life cycle." ''Journal of Management'' 14.1 (1988): 5–18.
* Smith, Mitchell, & Summer, 1986.
* Booch, Grady, Ivar Jacobson, and James Rumbaugh. ''The Unified Software Development Process''. Reading: Addison-Wesley, 1999.
* Yearsley, William S. ''How Differences in Heavy Civil Project Set-up Practices Impact Performance''. ProQuest, 2007.
* Project Management Institute, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th ed., 2013.
* ISO 21500: ''Guidance on Project Management''.
* Wikipedia articles cited inline (ISO-21500, use cases, iterative and incremental development, etc.).

[[Category:Definition]]

Risk wiki:About

2025-11-29T19:24:58Z

Pooyan:

== Website Terms of Use ==

----

'''PLEASE REVIEW BEFORE USING THIS WEBSITE – IF YOU DO NOT AGREE TO THESE TERMS OF USE, DO NOT USE THIS WEBSITE.'''

----

To provide the Services of RiskWiki, we have to set out some ground rules for using the Site in this document (the "Terms"). By accessing, using, or contributing to the RiskWiki Services or the RiskWiki Site, and in consideration for the Services we provide to you, you agree to abide by the Terms.

RiskWiki may change the Terms from time to time, at RiskWiki's sole discretion. Your continued use of the RiskWiki Site following the posting of such changes will constitute your assent to all such changes. Please periodically visit this section of the RiskWiki Site to review the current version of the Terms.

The RiskWiki Site is an information starting point. RiskWiki does not provide or replace individualized engineering or legal advice. The RiskWiki Site may include information which is out of date, jurisdiction-specific, or applicable only based on a specific set of facts, and this may not apply to your situation. Use of the Services or Site does not constitute the practice of engineering, nor does it create an attorney–client relationship between the user and RiskWiki.

If you are in need of engineering advice, seek individual engineer advice and DO NOT rely on RiskWiki. '''RiskWiki IS NOT YOUR ENGINEER.'''
Similarly, if you are in need of legal advice, seek individual attorney advice and DO NOT rely on RiskWiki. '''RiskWiki IS NOT YOUR LAWYER.'''

The following are meant to be used as general guidelines for the use of RiskWiki. RiskWiki editors may block users from making changes or using the site if they violate these guidelines. For additional materials see [https://en.wikipedia.org/wiki/Wikipedia:About this site] as a general reference, but RiskWiki reserves the right to deviate from Wikipedia policies as noted below. The biggest difference is that RiskWiki allows original research.

=== Contribute or Report on subjects and facts that are Consistent with RiskWiki Site Objectives or newsworthy ===

Contributing or reporting on topics and facts to RiskWiki must be legitimately newsworthy and not invade the privacy of individuals portrayed or unlawfully exploit their names or likenesses.

=== '''Follow good Academic Research and Journalism practices''' ===

RiskWiki contributors will follow good journalistic and academic practices and standards — being thorough, fair, and accurate in what is published; carefully attributing sources and quotes; and not phrasing statements in such a way as to create implications that contributors do not intend or do not have the evidence to support.

=== '''Strive to be as accurate as possible''' ===

Under this principle, contributors should verify key facts before publishing.

=== '''Use reliable sources''' ===

It is important to report information accurately and to properly attribute that information. RiskWiki will not use confidential sources.

=== '''Document research''' ===

Contributors should document how they reached their conclusions and, where possible, provide links or citations to the underlying documents, reports, or data.

=== '''Neutral Point of View''' ===

Contributors’ statements that accuse someone of committing a crime or being arrested; acting immorally; acting with professional incompetence; committing malpractice; exhibiting evidence of substance abuse; or engaging in improper sexual activities are prohibited on RiskWiki. The same caution applies to publishing negative information about businesses; however, RiskWiki contributors have every right to criticize companies and their products and services, provided it is done accurately and fairly.

RiskWiki may require contributors to obtain express consent/permission, at its sole discretion, from the organizations or people the material covers. RiskWiki may require contributors to take additional steps to fact-check materials or submit linked materials to public affairs offices for their review or notice.

=== '''Correction or Retraction of Mistakes''' ===

RiskWiki is committed to publishing only accurate and factual materials that conform to professional standards. If someone asks RiskWiki to publish a correction or retraction, RiskWiki will investigate the request carefully and in a timely manner. If we find there is a basis for the complaint, then we will correct any inaccuracies and post a correction or retraction. RiskWiki will re-edit the material to reflect the new information and may take other steps, such as protecting the page, to prevent further problems. Other steps may be taken at our discretion to maintain the quality of the material on RiskWiki.

=== '''Opinion and Fair Comment Privileges''' ===

RiskWiki content may reflect professional opinion about organizations, projects, and in some cases about companies and people. Contributors will strive to ensure that the context and the language used clearly convey that an opinion is being stated.

Words such as "in my opinion", "I believe", and "we think", used without establishing context and in the absence of underlying, verifiable facts, are not acceptable and may be removed by RiskWiki editors.

As noted above in the requirement for verifiable support, if a contributor’s opinion is based in part on verifiable facts, contributors should state the facts being relied upon and carefully ensure that the opinion is reasonable in light of those facts. Where possible, contributors should link to a document or source containing those facts in order to make clear the underlying basis for the opinion.

RiskWiki contributors may flag materials, articles, etc. to advise readers if there are quality or accuracy issues that have been identified and are in the process of being addressed.

=== '''Activities or Statements of Government Officials or Institutions''' ===

A large part of RiskWiki contributions will consist of publishing information about the activities or statements of government officials or institutions. RiskWiki contributors will rely as much as possible upon official documentary sources and statements made by government officials or materials produced by their contractors.

RiskWiki contributors will provide clear and accurate attribution to all documentary sources and statements by government officials, and will make online copies available if possible.

RiskWiki contributors will "stick to the facts". While contributors may report the content of an official document or the proceedings of a government meeting, editorial additions (for example, speculation about the motives of those involved) that tend to give a defamatory spin to the report are prohibited.

RiskWiki contributors will be fair and even-handed in the use of these sources. Contributors should read the whole source document and characterize its statements accurately in their contributions; selective quoting is prohibited.

=== Attribution ===

This material was obtained and adapted from the Digital Media Law Project (the "DMLP") website:
[https://www.dmlp.org/website-terms-use https://www.dmlp.org/website-terms-use] (accessed July 20, 2014).

The attributed material has been modified to use "RiskWiki" instead of "Digital Media Law Project" as the site owner, along with other substantial modifications and edits. No warranties or endorsements by the Digital Media Law Project or other Creative Commons licensors are implied in the use or modification of the attributed material by RiskWiki.

Risk wiki:About

2025-11-29T19:22:24Z

Pooyan: Created page with "== Website Terms of Use == ---- '''PLEASE REVIEW BEFORE USING THIS WEBSITE – IF YOU DO NOT AGREE TO THESE TERMS OF USE, DO NOT USE THIS WEBSITE.''' ---- To provide the Services of RiskWiki, we have to set out some ground rules for using the Site in this document (the "Terms"). By accessing, using, or contributing to the RiskWiki Services or the RiskWiki Site, and in consideration for the Services we provide to you, you agree to abide by the Terms. RiskWiki may cha..."

== Website Terms of Use ==

----

'''PLEASE REVIEW BEFORE USING THIS WEBSITE – IF YOU DO NOT AGREE TO THESE TERMS OF USE, DO NOT USE THIS WEBSITE.'''

----

To provide the Services of RiskWiki, we have to set out some ground rules for using the Site in this document (the "Terms"). By accessing, using, or contributing to the RiskWiki Services or the RiskWiki Site, and in consideration for the Services we provide to you, you agree to abide by the Terms.

RiskWiki may change the Terms from time to time, at RiskWiki's sole discretion. Your continued use of the RiskWiki Site following the posting of such changes will constitute your assent to all such changes. Please periodically visit this section of the RiskWiki Site to review the current version of the Terms.

The RiskWiki Site is an information starting point. RiskWiki does not provide or replace individualized engineering or legal advice. The RiskWiki Site may include information which is out-of-date, jurisdiction-specific, or applicable only based on a specific set of facts, and this may not apply to your situation. Use of the Services or Site does not constitute the practice of engineering nor does it create an attorney–client relationship between the user and RiskWiki.

If you are in need of engineering advice, seek individual engineer advice and DO NOT rely on RiskWiki. '''RiskWiki IS NOT YOUR ENGINEER.'''
Similarly, if you are in need of legal advice, seek individual attorney advice and DO NOT rely on RiskWiki. '''RiskWiki IS NOT YOUR LAWYER.'''

The following are meant to be used as general guidelines for the use of RiskWiki. RiskWiki editors may block users from making changes or using the site if they violate these guidelines. For additional materials see [https://en.wikipedia.org/wiki/Wikipedia:About this site] as a general reference, but RiskWiki reserves the right to deviate from Wikipedia policies as noted below. The biggest difference is that RiskWiki allows original research.

=== Contribute or Report on subjects and facts that are Consistent with RiskWiki Site Objectives or newsworthy ===

Contributing or reporting on topics and facts to RiskWiki must be legitimately newsworthy and not invade the privacy of individuals portrayed or unlawfully exploit their names or likenesses.

=== '''Follow good Academic Research and Journalism practices''' ===

RiskWiki contributors will follow good journalistic and academic practices and standards — being thorough, fair, and accurate in what is published; carefully attributing sources and quotes; and not phrasing statements in such a way as to create implications that contributors do not intend or do not have the evidence to support.

=== '''Strive to be as accurate as possible''' ===

(Under this principle, contributors should verify key facts before publishing.)

=== '''Use reliable sources''' ===

It is important to report information accurately and to properly attribute that information. RiskWiki will not use confidential sources.

=== '''Document research''' ===

Contributors should document how they reached their conclusions and, where possible, provide links or citations to the underlying documents, reports, or data.

=== '''Neutral Point of View''' ===

Contributors statements that accuse someone of committing a crime or being arrested; acting immorally; acting with professional incompetence; committing malpractice; exhibiting evidence of substance abuse; or engaging in improper sexual activities are prohibited on RiskWiki. The same caution applies to publishing negative information about businesses; however, RiskWiki contributors have every right to criticize companies and their products and services, provided it is done accurately and fairly.

RiskWiki may require contributors to obtain express consent/permission, at its sole discretion, from the organizations or people the material covers. RiskWiki may require contributors to take additional steps to fact-check materials or submit linked materials to public affairs offices for their review or notice.

=== '''Correction or Retraction of Mistakes''' ===

RiskWiki is committed to publishing only accurate and factual materials that conform to professional standards. If someone asks RiskWiki to publish a correction or retraction, RiskWiki will investigate the request carefully and in a timely manner. If we find there is a basis for the complaint, then we will correct any inaccuracies and post a correction or retraction. RiskWiki will re-edit the material to reflect the new information and may take other steps such as protecting the page to prevent further problems. Other steps may be taken at our discretion to maintain the quality of the material on RiskWiki.

=== '''Opinion and Fair Comment Privileges''' ===

RiskWiki contributor materials may reflect professional opinion about organizations, projects, and in some cases about companies and people. Contributors will strive to ensure that the context and the language used clearly convey that an opinion is being stated.

Words such as "in my opinion", "I believe", and "we think", used without establishing context and in the absence of underlying, verifiable facts, are not acceptable and may be removed by RiskWiki editors.

As noted above in the requirement for verifiable support, if a contributor’s opinion is based in part on verifiable facts, contributors should state the facts being relied upon and carefully ensure that the opinion is reasonable in light of those facts. Where possible, contributors should link to a document or source containing those facts in order to make clear the underlying basis for the opinion.

RiskWiki contributors may flag materials, articles, etc. to advise readers if there are quality or accuracy issues that have been identified and are in the process of being addressed.

=== '''Activities or Statements of Government Officials or Institutions''' ===

A large part of RiskWiki contributions will consist of publishing information about the activities or statements of government officials or institutions. RiskWiki contributors will rely as much as possible upon official documentary sources and statements made by government officials or materials produced by their contractors.

RiskWiki contributors will provide clear and accurate attribution to all documentary sources and statements by government officials, and will make online copies available if possible.

RiskWiki contributors will "stick to the facts". While contributors may report the content of an official document or the proceedings of a government meeting, editorial additions (for example, speculation about the motives of those involved) that tend to give a defamatory spin to the report are prohibited.

RiskWiki contributors will be fair and even-handed in the use of these sources. Contributors should read the whole source document and characterize its statements accurately in their contributions; selective quoting is prohibited.

=== Attribution ===

This material was obtained and adapted from the Digital Media Law Project (the "DMLP") website:
[https://www.dmlp.org/website-terms-use https://www.dmlp.org/website-terms-use] (accessed July 20, 2014).

The attributed material has been modified to use "RiskWiki" instead of "Digital Media Law Project" as the site owner, along with other substantial modifications and edits. No warranties or endorsements by the Digital Media Law Project or other Creative Commons licensors are implied in the use or modification of the attributed material by RiskWiki.

Performance Management Systems (PMSs)

2025-11-29T19:20:20Z

Pooyan: Restored “Performance Management Systems (PMSs)” from archived RiskEngineering.org (Wayback, 2017).

== Basic considerations ==

''See also the main article on [[The_concept_of_performance_in_a_civil_engineering_context|performance in a civil engineering context]].''

'''Performance management systems (PMSs)''' represent a holistic approach to the management and control of organizational performance and, by extension, the [[The_concept_of_performance_in_a_civil_engineering_context|performance of the project management organization]]. The term ‘’performance management systems’’ is used here in the broadest possible sense, and includes all aspects of organizational control – including those usually discussed under the heading of '''[[Management_control|management control systems]]'''.

== Research frameworks in Academic media ==

(Under construction.)

== Logical Framework ==

(Under construction.)

== Regulatory Framework ==

(Under construction.)

== Practice Framework (Under construction) ==

''Work in the PMBOK materials on “management control”''

The [[Project_Management_Body_of_Knowledge_(PMIBoK)|PMI Body of Knowledge (PMBOK)]] contains many instances of the term “management control”. There are several definitions in the Glossary that use the term to define other concepts (such as contingency reserve, control account, management reserve, and performance measurement baseline), but the Glossary does not itself define **performance**. Similarly, the phrase “management control” is used repeatedly in the document but is not explicitly defined.

=== Performance Management framework ===

Otley proposes a general framework for performance management systems:<ref name="Otley1999">Otley, David. "Performance management: a framework for management control systems research." ''Management Accounting Research'' 10, no. 4 (1999): 363–382.</ref>

==== Further guidance ====

PMSs can be understood as:

: “the evolving formal and informal mechanisms, processes, systems, and networks used by (project management) organizations for conveying the key objectives and goals elicited by the sponsoring organization’s management; for assisting the strategic process and ongoing project management through analysis, planning, measurement, control, rewarding, and broadly managing performance; and for supporting and facilitating organizational learning and change. Hence we use the term performance management system to encapsulate these more general processes, and our working definition of a PMS includes both the formal mechanisms, processes, systems, and networks used by organizations, and also the more subtle, yet important, informal controls that are used.

: It is also based on the premise that key objectives and goals are set by managers at every level, but it does not assume that these objectives and goals are necessarily the ones that best serve the organization as a whole.”<ref name="FerreiraOtley2009">Ferreira, Aldónio, and David Otley. "The design and use of performance management systems: An extended framework for analysis." ''Management Accounting Research'' 20, no. 4 (2009): 263–282. doi:10.1016/j.mar.2009.07.003.</ref>

==== Beneficial Outcomes ====

(Under construction.)

== Working definition of the term ==

(Under construction.)

== Limitations of the definition ==

(Under construction.)

== See also ==

Wiki articles:

* [[wikipedia:Performance_management|Performance management]]
* [[wikipedia:Performance_engineering|Performance engineering]]
* [[wikipedia:Performance_(disambiguation)|Performance topics]]
* [[wikipedia:IT_performance_management|IT performance management]]

== Notes ==

(Under construction.)

== References ==

<references/>

[[Category:Definition]]

Practice Concepts Portal

2025-11-29T19:18:43Z

Pooyan: Restored “Practice Concepts Portal” from archived RiskEngineering.org (Wayback, 2017).

'''<big>This page is under construction ...</big>'''

''Again, please note our [[Risk_wiki:About#Website_Terms_of_Use|site terms of use!]]''

== Portal Overview ==

'''Life-cycle frameworks:''' for understanding the distinct roles played by phasing and delivery in programs and projects.

Civil engineers delivering projects do so in a series of activities that are sequenced to translate stakeholder objectives into a physical facility constructed and commissioned by third parties. The civil engineer practices in an environment where the vision, the plan, and the realized facility are often controlled by separate organizations. In this regard, the civil engineer advises the project sponsor on assigning the contractual responsibilities for designing and constructing the project. A specific approach to project delivery identifies the primary parties contracting for the performance of discrete subsets of project scope.

The integration of project phasing and delivery means that the civil engineer accomplishes these activities at multiple levels: work package level, design package level, contract package level, functional level, systems level, project level, and in some cases portfolio or program level.

* [[Program_Phase_Models|Program Phase Models]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]]
* [[Program_Delivery_Methods|Program Delivery Methods]], [[Project_Delivery_Methods|Project Delivery Methods]]
* [[Project_stakeholder|Project stakeholder]]
* [[Project_Oversight|Project Oversight]], [[Project_Monitoring/Assessment/Evaluations|Project Monitoring/Assessment/Evaluations]], [[Project_Governance/Internal_Controls/Charters|Project Governance/Internal Controls/Charters]]

'''Critical decision series''' in project delivery (see [[Decision_Making_In_Engineering#Fundamental_decisions|Decision Making in Engineering – Fundamental decisions]]):

* [[Critical_Decisions_in_Project_Management|Critical Decisions in Project Management]]
* [[Critical_Decisions_in_Design_Management|Critical Decisions in Design Management]]
* [[Critical_Decisions_in_Management_Controls|Critical Decisions in Management Controls]]
* [[Critical_Decisions_in_Risk_Management|Critical Decisions in Risk Management]]

[[Category:Portal]]

Professional Concepts Portal

2025-11-29T19:16:01Z

Pooyan: Restored “Professional Concepts Portal” from archived RiskEngineering.org (Wayback, 2017).

'''<big>This page is under construction ...</big>'''

'''Frameworks for professions series:''' for understanding engineering processes and the environments in which engineering professions practice.

== An aspirational vision of [[Civil_Engineering|Civil Engineering (CE)]] for 2025 ==

Not unexpectedly, the [[wikipedia:American_Society_of_Civil_Engineers|American Society of Civil Engineers (ASCE)]] dominates the field in defining the future vision of civil engineering. In ASCE's vision, outcomes paired with explanations provide "a desirable deliverable for stakeholders ... with each outcome supported by a descriptive and illustrative explanation." <ref name="ASCEVision">ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 19, ISBN 978-0-7844-7886-8.</ref> As ASCE itself acknowledges, these outcomes will evolve over time as stakeholders provide input and market changes drive the profession to adapt to future challenges. <ref name="ASCEBOK">American Society of Civil Engineers (ASCE), ''Civil Engineering Body of Knowledge for the 21st Century'', 2nd ed., 2008, Appendix J, p. 113.</ref>

== [[Semantics_of_Civil_Engineering|Semantics of Civil Engineering]] ==

[[wikipedia:Semantics|Semantics]] is the study of meaning, focusing on the relationship between words and how they are used. As used on this website, civil-engineering semantics is the study of meaning that is used for understanding the practice of civil engineering through language and models.

The general approach is to formalize the meanings of civil-engineering terms and models by constructing engineering objects, processes, workflows and [[wikipedia:Schema|schemas]] by [[wikipedia:Denotation|denotation]] – i.e., referring to something literal, rather than using metaphor.

The practical necessity for this study is the terminology issues in civil-engineering practice where terms are used interchangeably – or worse, inconsistently. These issues need to be sorted out before specific knowledge concepts can be advanced. For convenience, each article on civil-engineering practice and knowledge identifies semantic issues with a link back to a page in this section that addresses the problem in meaning and provides recommendations.

== [[Civil_Engineering_Models|Civil Engineering Models]] ==

(Under construction.)

== [[Civil_Engineering_Processes|Civil Engineering Processes]] ==

Organizational process assets are the plans, processes, policies, procedures, and knowledge bases specific to – and used by – the performing organization. They include any artifact, practice, or knowledge from any or all of the organizations involved in the project that can be used to perform or govern the project.

These process assets include formal and informal plans, processes, policies, procedures, and knowledge bases. They also include the organization’s knowledge bases such as lessons learned and historical information. Organizational process assets may include completed schedules, risk data, and earned-value data. They are inputs to most planning processes; throughout the project, project-team members may update and add to them as necessary. Organizational process assets are often grouped into two categories:

# Processes and procedures
# Corporate knowledge bases <ref name="PMIBOK2-19">Project Management Institute, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th ed., 2013, Sec. 2, p. 19.</ref>

== [[Civil_Engineering_Environments|Civil Engineering Environments]] ==

PMI notes in the PMBOK:

:"Projects and project management take place in an '''environment''' that is broader than that of the project itself. Understanding this broader context helps ensure that work is carried out in alignment with the organization’s goals and managed in accordance with the organization’s established practices." <ref name="PMIBOK2-19" />

=== [[Civil_Engineering_Projects|Civil Engineering Projects]] ===

Although ASCE does not formally define "project", the concept is deeply embedded in ASCE's vision of civil engineering. The term appears many times in the Vision 2025 document, which notes that civil engineers provide the "essential underpinnings of design and project oversight." <ref name="ASCEVision3">ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 3.</ref> Civil engineering will continue to be focused on "the definition, selection, and implementation of projects." <ref name="ASCEVision59">ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 59.</ref> These projects can range from simple subdivisions or road projects to immense public works.

:'''The primary focus of RiskWiki is complex civil-engineering projects.'''

=== [[Program_Management_in_Civil_Engineering|Civil Engineering Programs]] ===

Although ASCE does not define "program", the concept is also deeply embedded in ASCE's Vision 2025. The term appears even more frequently than "project," but mostly in relation to educational programs (ABET programs, baccalaureate degree programs, civil-engineering education programs, professional development programs, etc.), not in the context of physical project execution and delivery as practiced by, for example, the US Army Corps of Engineers, EPA, or DOE.

Civil engineers play a pivotal role in such programs, but they are not fully visible in that vision.

:'''A secondary focus of RiskWiki is civil-engineering programs.'''

== [[Civil_Engineering_Knowledge_and_Meta-Knowledge_Models|Civil Engineering Knowledge and Meta-Knowledge Models]] ==

=== [[Discipline_specific_knowledge_domains_and_models_for_Civil_Engineering#Taxonomy_and_ontology_models_in_engineering_knowledge|Classic taxonomic model of Civil Engineering Knowledge]] ===

As currently envisioned in the ASCE Body of Knowledge (2nd edition), the model is discipline-specific and makes no explicit distinction between civil-engineering knowledge and meta-knowledge.

==== Foundational Outcomes ====

* [[Foundational_Outcomes_for_Civil_Engineering:Mathematics|Mathematics]]
* [[Foundational_Outcomes_for_Civil_Engineering:Natural_Sciences|Natural Sciences]]
* [[Foundational_Outcomes_for_Civil_Engineering:Humanities|Humanities]]
* [[Foundational_Outcomes_for_Civil_Engineering:Social_Sciences|Social Sciences]]

==== Technical Outcomes ====

* [[Technical_Outcomes_for_Civil_Engineering:Materials_Science|Materials Science]]
* [[Technical_Outcomes_for_Civil_Engineering:Mechanics|Mechanics]]
* [[Technical_Outcomes_for_Civil_Engineering:Experiments|Experiments]]
* [[Technical_Outcomes_for_Civil_Engineering:Problem_Recognition_and_Solving|Problem Recognition and Solving]]
* [[Technical_Outcomes_for_Civil_Engineering:Design|Design]]
* [[Technical_Outcomes_for_Civil_Engineering:Sustainability|Sustainability]]
* [[Technical_Outcomes_for_Civil_Engineering:Contemporary_Issues_and_Historical_Perspectives|Contemporary Issues and Historical Perspectives]]
* [[Technical_Outcomes_for_Civil_Engineering:Risk_and_Uncertainty|Risk and Uncertainty]]
* [[Technical_Outcomes_for_Civil_Engineering:Project_Management|Project Management]]
* [[Technical_Outcomes_for_Civil_Engineering:Breadth_in_Civil_Engineering_Areas|Breadth in Civil Engineering Areas]]
* [[Technical_Outcomes_for_Civil_Engineering:Technical_Specialization|Technical Specialization]]

==== Professional (or Experiential) Outcomes ====

* [[Experiential_Outcomes_for_Civil_Engineering:Communication|Communication]]
* [[Experiential_Outcomes_for_Civil_Engineering:Public_Policy|Public Policy]]
* [[Experiential_Outcomes_for_Civil_Engineering:Business_and_Public_Administration|Business and Public Administration]]
* [[Experiential_Outcomes_for_Civil_Engineering:Globalization|Globalization]]
* [[Experiential_Outcomes_for_Civil_Engineering:Leadership|Leadership]]
* [[Experiential_Outcomes_for_Civil_Engineering:Teamwork|Teamwork]]
* [[Experiential_Outcomes_for_Civil_Engineering:Attitudes|Attitudes]] <ref name="TestNote">Internal test note from original RiskWiki draft.</ref>

The key pathway to this set of outcomes is a graduate-level course such as "Introduction to professional practice in Civil Engineering."

:See draft syllabus: [[Model_Syllabus:Introduction_to_professional_practice_in_Civil_Engineering|Introduction to professional practice in Civil Engineering]].

=== [[Discipline_specific_knowledge_domains_and_models_for_Civil_Engineering#Taxonomy_and_ontology_models_in_engineering_knowledge|Ontological models of Civil Engineering Knowledge and Meta-knowledge]] ===

Alternatively, civil-engineering outcomes can be structured on an ontological basis:

* First around civil-engineering design products (foundational and technical),
* Then around integrating these designs into executed projects and programs.

==== Discipline Specific Foundational Outcomes ====

* [[Discipline_Specific_Foundational_Outcomes_for_Civil_Engineering:Mathematics|Mathematics]]
* [[Discipline_Specific_Foundational_Outcomes_for_Civil_Engineering:Natural_Sciences|Natural Sciences]]
* [[Discipline_Specific_Foundational_Outcomes_for_Civil_Engineering:Humanities|Humanities]]
* [[Foundational_Outcomes_for_Civil_Engineering:Social_Sciences|Social Sciences]]

==== Discipline Specific Technical Outcomes ====

* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Materials_Science|Materials Science]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Mechanics|Mechanics]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Experiments|Experiments]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Problem_Recognition_and_Solving|Problem Recognition and Solving]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Design|Design]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Sustainability|Sustainability]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Contemporary_Issues_and_Historical_Perspectives|Contemporary Issues and Historical Perspectives]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:(Design)_Risk_and_Uncertainty|(Design) Risk and Uncertainty]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Project_Management|Design Management]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Breadth_in_Civil_Engineering_Areas|Breadth in Civil Engineering Areas]]
* [[Discipline_Specific_Technical_Outcomes_for_Civil_Engineering:Technical_Specialization|Technical Specialization in Design]]

==== Project Foundational Outcomes ====

* [[Foundational_Outcomes_for_Project_Execution:Mathematics|Probability, statistics and decision theory]]
* [[Foundational_Outcomes_for_Project_Execution:Natural_Sciences|Natural Sciences]]
* [[Foundational_Outcomes_for_Project_Execution:Humanities|Humanities]]
* [[Foundational_Outcomes_for_Project_Execution:Social_Sciences|Economics]]

==== Project Specific Technical Outcomes ====

* [[Project_Execution|Project Execution]]
* [[Project_Development|Project Development]]
* [[Project_Definition|Project Definition]]
* [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]]
* [[Project_Delivery_Methods|Project Delivery Methods]]

==== [[Civil_Engineering_Projects|Project]] Execution Outcomes ====

* [[Project_Execution_Outcomes:Knowledge_Objects|Knowledge Objects]]
* [[Project_Execution_Outcomes:Knowledge_Mechanics|Knowledge Mechanics]]
* [[Project_Execution_Outcomes:Knowledge_Experiments|Knowledge Experiments]]
* [[Project_Execution_Outcomes:Problem_Recognition_and_Solving_in_Project_Execution|Problem Recognition and Solving in Project Execution]]
* [[Project_Execution_Outcomes:Design_components_in_Project_Execution|Design components in Project Execution]]
* [[Project_Execution_Outcomes:Sustainability_in_Project_Execution|Sustainability in Project Execution]]
* [[Project_Execution_Outcomes:Contemporary_Issues_and_Historical_Perspectives_in_Project_Execution|Contemporary Issues and Historical Perspectives in Project Execution]]
* [[Project_Execution_Outcomes:_Risk_and_Uncertainty_in_Project_Execution|Risk and Uncertainty in Project Execution]]
* [[Project_Execution_Outcomes:Engineering_Management_of_Project_Execution|Engineering Management of Project Execution]]
* [[Project_Execution_Outcomes:Breadth_in_Project_Execution_Areas|Breadth in Project Execution Areas]]
* [[Project_Execution_Outcomes:Technical_Specialization_in_Project_Execution|Technical Specialization in Project Execution]]

The key pathway to this project-execution set of outcomes is a graduate-level course such as "A Civil Engineering platform for project management":

:See draft syllabus: [[Model_Syllabus:A_Civil_Engineering_platform_for_project_management|A Civil Engineering platform for project management]].

==== Program Execution Outcomes ====

(See also: [[Program_Development|Program Development]], [[Program_Definition|Program Definition]], [[Program_Life_Cycle_and_Phase_Models|Program Life Cycle and Phase Models]], [[Program_Delivery_Methods|Program Delivery Methods]].)

* [[Program_Execution_Outcomes:Policy_Objects|Policy Objects]]
* [[Program_Execution_Outcomes:Policy_Mechanics|Policy Mechanics]]
* [[Program_Execution_Outcomes:Policy_Experiments|Policy Experiments]]
* [[Program_Execution_Outcomes:Problem_Recognition_and_Solving_in_Program_Execution|Problem Recognition and Solving in Program Execution]]
* [[Program_Execution_Outcomes:Design_components_in_Program_Execution|Design components in Program Execution]]
* [[Program_Execution_Outcomes:Sustainability_in_Program_Execution|Sustainability in Program Execution]]
* [[Program_Execution_Outcomes:Contemporary_Issues_and_Historical_Perspectives_in_Program_Execution|Contemporary Issues and Historical Perspectives in Program Execution]]
* [[Program_Execution_Outcomes:_Risk_and_Uncertainty_in_Program_Execution|Risk and Uncertainty in Program Execution]]
* [[Program_Execution_Outcomes:Engineering_Management_of_Program_Execution|Engineering Management of Program Execution]]
* [[Program_Execution_Outcomes:Breadth_in_Program_Execution_Areas|Breadth in Program Execution Areas]]
* [[Program_Execution_Outcomes:Technical_Specialization_in_Program_Execution|Technical Specialization in Program Execution]]

==== Professional (or Experiential) Outcomes (again) ====

* [[Experiential_Outcomes_for_Civil_Engineering:Communication|Communication]]
* [[Experiential_Outcomes_for_Civil_Engineering:Public_Policy|Public Policy]]
* [[Experiential_Outcomes_for_Civil_Engineering:Business_and_Public_Administration|Business and Public Administration]]
* [[Experiential_Outcomes_for_Civil_Engineering:Globalization|Globalization]]
* [[Experiential_Outcomes_for_Civil_Engineering:Leadership|Leadership]]
* [[Experiential_Outcomes_for_Civil_Engineering:Teamwork|Teamwork]]
* [[Experiential_Outcomes_for_Civil_Engineering:Attitudes|Attitudes]] <ref name="TestNote" />

The key pathway to this project-execution set of outcomes is a graduate-level course in "Introduction to professional practice in Civil Engineering" (see syllabus link above).

== Notes ==

<references />

== See Also ==

Wikipedia articles and projects:

* [[wikipedia:Wikipedia:WikiProject_Civil_engineering|WikiProject Civil Engineering]]

== References ==

* ASCE, ''The Vision for Civil Engineering in 2025'', 2006.
* American Society of Civil Engineers (ASCE), ''Civil Engineering Body of Knowledge for the 21st Century'', 2nd ed., 2008.
* Project Management Institute, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th ed., 2013.

[[Category:Portal]]

Basic Concepts of Program Management

2025-11-29T19:12:53Z

Pooyan: Convert to redirect → Program_Management_in_Civil_Engineering (to match original RiskWiki structure)

#REDIRECT [[Program_Management_in_Civil_Engineering]]

Program Management in Civil Engineering

2025-11-29T19:07:48Z

Pooyan: Restored “Program Management in Civil Engineering” from archived RiskEngineering.org (Wayback, 2017).

'''<big>(Under Construction)</big>'''

; See also
''See also [[Project_Execution|Project Execution]], [[Project_Development|Project Development]], [[Project_Definition|Project Definition]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]], [[Project_Delivery_Methods|Project Delivery Methods]].''

''See also [[Civil_Engineering_Projects|Civil Engineering Projects]], [[Project_management|Project Management]] ...''

== Basic considerations ==

Program Management has emerged as a distinct discipline from the maturing of the project management discipline in the late 1990s. It progressively developed as project management was applied to more and more complex projects, to the management of strategic objectives, and to the management of multiple interrelated endeavours to produce strategic benefits. It is now generally agreed that programs are significant undertakings consisting of multiple actions spanning multiple business areas and that they are generally complex.<ref name="Thiry2010-1">Thiry, Michel. ''Program management''. Farnham, Surrey, GBR: Ashgate Publishing Ltd, 2010.</ref>

:'''Program management deals in both high ambiguity and uncertainty and requires a high degree of organizational maturity.'''<ref name="Thiry2010-2">Thiry, Michel. ''Program management''. Farnham, Surrey, GBR: Ashgate Publishing Ltd, 2010.</ref>

== Semantic, Epistemic and Logical frameworks ==

The semantic, epistemic and logical frameworks for the concept of program management for executing civil engineering projects have multiple issues arising largely from interchangeable usages and lack of definition between civil engineering programs, [[Civil_Engineering_Projects|projects]] and portfolios of projects.

Traditionally, most organizations undertake projects as part of their work. Mostly, these projects are treated as separate entities, independent from each other. They are often generated within a business unit and managed with that unit’s resources. Larger projects undertaken either for external clients or for strategic purposes are usually managed on an ad hoc basis by a dedicated team.

In this aspirational vision, however, civil engineers practice in mature organizations that use programs to execute projects and deliver intended benefits.

:'''Programs can either be “vision-led”, driven by strategy and organizational mission, or “emergent”, representing an expedient or convenient grouping of existing projects.'''

=== Semantic framework ===

No significant semantic issues were identified for this topic, although one author (Grasso) in the CMAA discussion below argues there is a prevalent misconception that equates program management with project-level delivery methods.

=== Epistemic framework ===

There are frameworks for distinguishing different types of civil engineering knowledge as well as that of related disciplines and sciences, and for describing [[Discipline_specific_knowledge_domains_and_models_for_Civil_Engineering#Dimensions_of_Civil_Engineering_Knowledge|knowledge components and knowledge architecture]]. The key aspect of civil engineering knowledge is its hierarchical structure and the process / sequential nature in which knowledge is developed and, most importantly, how it is applied. Its models are grounded in underlying knowledge domains.

Knowledge models can be developed as ontologies or taxonomies, with critical differences:

* Taxonomy is the practice and science of classification without necessarily requiring a hierarchical structure. Taxonomies are not very useful for problem solving outside of formal education.
* Ontologies concern the basic nature, essential properties, and relationships. Professions like civil engineering construct ontologies to limit complexity and organize information and thereby increase the value of knowledge for solving problems.

:'''Civil engineers are skilled at constructing engineering ontologies that control complexity, organize data, produce information and knowledge. These ontologies are useful for solving engineering problems, sequencing critical decisions, and sharing and reusing knowledge. This allows civil engineers to demonstrate mastery of the professional role in project execution and delivery.'''

Given this development, an [[Professional_Concepts_Portal#Ontological_models_of_Civil_Engineering_Knowledge_and_Meta-knowledge|onto-logic knowledge model]] for civil-engineering programs requires:

* The [[Civil_Engineering_Projects#Epistemic_framework|underlying knowledge framework for CE projects]], and
* The overlaying [[Professional_Concepts_Portal#Program_Execution_Outcomes|Program Execution Outcomes]]. [Note 1]

=== Logical framework ===

The logical framework for civil-engineering programs has several key concepts:

* A program necessarily starts with more than one project. (One project does not a program make.)
* The projects must be related in such a way that, when managed as a group, a net positive benefit is obtained.
* The group of projects must support controls such that, when managed as a program, performance exceeds what would occur if the projects were managed individually.
* Programs may include ancillary elements of related work outside the scope of the discrete projects in the program.

[[#top|Top of current page]]

== Practice frameworks in Program Management ==

Four “components” can be identified as essential to the practice of program management:

* Decision management
* Governance
* Stakeholder management
* Benefits management

These four components are intimately linked: stakeholders’ needs drive benefits; key stakeholders make decisions based on expected benefits; governance provides the structures necessary to achieve them.

The main program guides and standards already recognize governance, stakeholder and benefits management as key program components. Decision management is a newer area of development that requires both a learning cycle (decision-making process) and a performance cycle (decision realization process). Program managers understand that decision-making is not just about tools, but about making the right choices based on objectives that have been agreed upon and can be measured within a performance framework.<ref name="Thiry2004-1">Thiry, Michel. "Program management: a strategic decision management process." in ''The Wiley Guide to Project, Program, and Portfolio Management'' (2004): 113–143.</ref>

:'''There are four key program components: decision management, program governance, stakeholder management and benefits management.'''<ref name="Thiry2004-2">Thiry, Michel. "Program management: a strategic decision management process." in ''The Wiley Guide to Project, Program, and Portfolio Management'' (2004): 113–143.</ref>

Programs, like projects, have life cycles: **Formulation**, **Organization**, **Deployment**, **Appraisal**, and **Dissolution**.

The formulation process enables the program team, its sponsors and other key stakeholders to achieve agreement on the benefits that the program must realize and how they will be assessed within a performance framework. Formulation is a learning cycle of strategic decision-making in which stakeholders agree the objectives, critical success factors and measures of success for the program.<ref name="Thiry2004-3">Thiry, Michel. "Program management: a strategic decision management process." in ''The Wiley Guide to Project, Program, and Portfolio Management'' (2004): 113–143.</ref>

Formulation, organization, deployment and appraisal are linked through an iterative process where the program is progressively developed while continually verifying benefits and value realization. Program termination occurs using pre-determined criteria / performance frameworks and on the basis of significant data defined at the formulation and organization stages.<ref name="Thiry2004-4">Thiry, Michel. "Program management: a strategic decision management process." in ''The Wiley Guide to Project, Program, and Portfolio Management'' (2004): 113–143.</ref>

=== PMI Definition of Program Management ===

More recently, PMI work has defined Program Management as:

:"the centralized, coordinated management of a program to achieve the program’s strategic objectives and benefits", emphasizing programs’ long-term benefit orientation, strategic nature, and the challenge of integrating and coordinating a complex network of resources.<ref name="PMI-StdPgM">''The Standard for Program Management''. Project Management Institute, 2006, as cited in Artto et al.</ref>

==== Program Management Rationale ====

* Modern project management emerged in the mid-20th century. At that time, “project” and “program” management were often used interchangeably – a project-centric notion of program management.<ref name="Artto2009">Artto, Karlos, et al. "Foundations of program management: A bibliometric view." ''International Journal of Project Management'' 27.1 (2009): 1–18.</ref>
* As project management was applied more broadly, it became evident that managing multiple projects is more complex than managing a single project or even a simple portfolio. Issues arise in coordination, overall control, and management capacity and capability for the program versus individual projects.<ref name="Lycett2004-1">Lycett, Mark, Andreas Rassau, and John Danson. "Program management: a critical review." ''International Journal of Project Management'' 22.4 (2004): 289–299.</ref> Program management emerged as a way to integrate management of related projects so that performance exceeds what would be feasible if projects were managed separately.

While program management is similar to portfolio management, they are not the same. A common misconception is that program management is simply a scaled-up version of project management.<ref name="Lycett2004-2">Lycett, Mark, Andreas Rassau, and John Danson. "Program management: a critical review." ''International Journal of Project Management'' 22.4 (2004): 289–299.</ref>

* Lycett et al. argue programs create value by executing projects more efficiently than in isolation, while portfolios exist primarily to enable individual projects to reach their objectives. Program management is about both effectiveness and efficiency and can apply equally to business and policy / legislative goals, e.g. public works programs under FHWA or FTA.
* As project management became more integrated as a method for implementing strategic objectives through “hard” projects, it was also applied to less tangible or shifting objectives inherent in organizational change.<ref name="Pellegrinelli1997">Pellegrinelli, Sergio. "Program management: organizing project-based change." ''International Journal of Project Management'' 15.3 (1997): 141–149.</ref> Project management is increasingly used as an organizational design model (cross-functional project teams).

The main rationale for Program Management (PgM) as a separate discipline is to organize independent project execution in a coherent manner and:

* apply learning across projects,
* realign projects to changing objectives and strategies,
* and add value at the program layer.<ref name="PellegrinelliNote2">Concept from Pellegrinelli and Bowman (1994) as cited in Pellegrinelli (1997).</ref>

Many practitioners still see programs only as “projects plus more Gantt charts”. However, in multi-project environments the key challenge is often managing limited or critical resource pools.

Program management goes beyond portfolio techniques that focus mainly on common resources and finance. In practice, many organizations do not treat project initiation or termination as part of Program Management, but in reality:

:'''Programs exist prior to many specific projects, and they serve as vehicles for developing, initiating, controlling, and sometimes terminating projects that do not offer acceptable prospects of success or risk profiles.'''

Programs also:

* align multiple projects with major objectives,
* transfer knowledge between projects,
* adapt strategies to subtle shifts in program-layer goals,
* and mediate conflicts between sponsors and project-level stakeholders.<ref name="PellegrinelliNote3">Concept from Pellegrinelli (1997) and related discussions.</ref>

:'''Programs arise to manage business cases and processes for initiating projects, allocating resources, sequencing work, and balancing the often competing interests of program sponsors and project stakeholders.'''

Programs also offer more specialized forms of control, namely **oversight**, beyond ordinary project controls. Programs have archetypal configurations, life cycles and phasing.

==== Program Management Roles ====

(Under construction.)

=== CMAA Definition of Program Management ===

The CMAA (2006) definition of Program Management is:

:"Program Management is the practice of professional construction management applied to a capital improvement program of one or more projects from inception to completion. Comprehensive construction management services are used to integrate the different facets of the construction process – planning, design, procurement, construction and activation – for the purpose of providing standardized technical and management expertise on each project."<ref name="Grasso2007">Grasso, Barton. "Benchmarking the Management of Construction Programs." (2007).</ref>

CMAA emphasizes that:

* Program management is a **management technique** within construction.
* Management techniques differ from project delivery methods:
* A project delivery method is “a comprehensive process of assigning the contractual responsibilities for designing and constructing a project”.
* A management technique or method is “a method of managing design and construction services”.<ref name="Grasso2007" />

Grasso argues there is a common misconception that management techniques and project delivery methods are logically equivalent.

'''Commentary:'''

(Under construction.)

=== ISO Definition of Program Management ===

'''Commentary:'''

(Under construction.)

=== ASCE Definition of Program Management ===

'''Commentary:'''

(Under construction.)

[[#top|Top of current page]]

== Legislative framework for Program Management ==

[[#top|Top of current page]]

== Regulatory framework for Program Management ==

"Managing for results" – the idea that empirical performance data should guide public managers’ decision-making – has framed much of the discussion about management in public and non-profit agencies in the United States since the 1990s.<ref name="Newcomer2007">Newcomer, Kathryn E. "How does program performance assessment affect program management in the federal government?." ''Public Performance & Management Review'' 30.3 (2007): 332–350.</ref>

(Under construction.)

== Further Guidance ==

(Under construction.)

== Working definition of the term ==

:"Program Management is the centralized, coordinated management of a set of projects to achieve stated objectives and benefits. Program management deals in both high ambiguity and uncertainty and requires a high degree of organizational maturity. Programs manage project execution and delivery within a management framework of lifecycles and phases with milestone events termed ''kill points'' or ''off-ramps'' where program management, in an exercise of decision authority, determines whether the project goes forward. This decision is often made in the context of authorizing the project to transition to the next life cycle phase and is supported by a number of reviews. Programs constitute the missing link between enterprise-level strategy and the projects and operations that will enable the program to meet stakeholder expectations and deliver value."<ref name="Thiry2010-3">Thiry, Michel. ''Program management''. Farnham, Surrey, GBR: Ashgate Publishing Ltd, 2010.</ref>

[[#top|Top of current page]]

== Limitations of the definition ==

(Under construction.)

== Beneficial Outcomes ==

'''Commentary:'''

(Under construction.)

== See also ==

* J. LeRoy Ward, ''Program Management Complexity: A Competency Model''. Auerbach Publications, 2011. Print ISBN 978-1-4398-5111-1, eBook ISBN 978-1-4398-5112-8.
* [[wikipedia:Program_management|Wikipedia article on Program management]] (largely "project-centric" as discussed above).

[[#top|Top of current page]]

== Notes ==

* [Note 1] Onto-logic model for programs builds on the knowledge framework for civil-engineering projects and the program execution outcomes.
* [Note 2] Pellegrinelli & Bowman (1994) as cited in Pellegrinelli (1997) – program approach to managing interdependence between projects and strategy implementation.
* [Note 3] Pellegrinelli (1997) – programs as vehicles for initiating/terminating projects and balancing sponsor/stakeholder interests.

== References ==

<references/>

Project

2025-11-29T19:05:05Z

Pooyan: Redirect Project → Civil Engineering Projects.

#REDIRECT [[Civil_Engineering_Projects]]

Civil Engineering Projects

2025-11-29T19:03:11Z

Pooyan: Restored “Civil Engineering Projects” from archived RiskEngineering.org (Wayback, 2017).

'''<big>This page is under construction ...</big>'''

; See also
''See also [[Project_Execution|Project Execution]], [[Project_Development|Project Development]], [[Project_Definition|Project Definition]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]], [[Project_Delivery_Methods|Project Delivery Methods]].''

''See also [[Program_Management_in_Civil_Engineering|Program Management in Civil Engineering]], [[Project_management|Project Management]] ...''

== Basic considerations ==

[[#top|Top of current page]]

== Semantic, Epistemic and Logical frameworks ==

The semantic, epistemic and logical frameworks for the concept of civil engineering projects have multiple issues arising largely from interchangeable usages and lack of definition.

=== Semantic framework ===

* The semantics problems largely revolve around distinguishing between [[Program_Management_in_Civil_Engineering|civil engineering programs]], projects and portfolios of projects. [Note 1]

=== Epistemic framework ===

There are frameworks for distinguishing different types of civil engineering knowledge as well as that of related disciplines and sciences, as well as [[Discipline_specific_knowledge_domains_and_models_for_Civil_Engineering#Dimensions_of_Civil_Engineering_Knowledge|knowledge components and knowledge architecture]].

The key aspect of civil engineering knowledge is its hierarchical structure and the process or sequential nature in which its knowledge is developed and, most importantly, how it is applied. Its models are grounded in underlying knowledge domains.

The key characteristic in this analysis is that knowledge models can be developed as ontologies or taxonomies with critical differences between the two.

Taxonomy is the practice and science of classification without necessarily requiring a hierarchical structure. Taxonomies are not, by themselves, very useful for problem solving outside of the formal education process.

Ontologies, on the other hand, are the study of the basic nature, essential properties, and relationships. Disciplines or professions like civil engineering construct ontologies to limit complexity and organize information and thereby increase the value of knowledge for solving problems.

:'''Civil engineers are skilled at constructing engineering ontologies that control complexity, organize data, produce information and knowledge. These ontologies are useful for solving engineering problems, sequencing critical decisions and sharing and reusing knowledge, thereby allowing the civil engineer to demonstrate mastery of the professional's role in project execution and delivery.'''

Given this development, an [[Professional_Concepts_Portal#Ontological_models_of_Civil_Engineering_Knowledge_and_Meta-knowledge|onto-logic knowledge model]] for civil engineering projects requires underlying [[Professional_Concepts_Portal#Discipline_Specific_Foundational_Outcomes|Discipline Specific Foundational]] and [[Professional_Concepts_Portal#Discipline_Specific_Technical_Outcomes|Technical Outcomes]] as well as [[Professional_Concepts_Portal#Project_Foundational_Outcomes|Project Foundational]], [[Professional_Concepts_Portal#Project_Specific_Technical_Outcomes|Project Specific Technical]] and [[Professional_Concepts_Portal#Project_Execution_Outcomes|Execution outcomes]].

=== Logical framework ===

The logical framework for civil engineering projects has several key concepts.

[[#top|Top of current page]]

== Practice frameworks for Civil Engineering Projects ==

=== PMIBoK ===

PMI defines a project as:

:"a temporary endeavor undertaken to create a unique product, service, or result." [1]

PMI notes that temporary does not mean the duration of the project is short. Projects may provide tangible or intangible outcomes. Projects may contain repetitive artifacts in processes; PMI notes that this does not change "the fundamental, unique characteristics of the project work." (ibid.)

'''Commentary:'''

* The term is defined in a very loose, generic context and hardly reflective of actual civil engineering practice. Civil engineering projects are sets of activities and processes that are organized and directed towards a common purpose, objective or goal. More to the point, they result in a tangible result, a physical facility. They are undertaken by a project sponsor and assigned to a project office held responsible for project execution. [Note 2]

This is a much stronger but narrower definition than that envisaged by PMI.

=== International Organization for Standardization (ISO) ===

In its Quality Management System standard, ISO defines a project as a:

:"unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources." [2]

'''Commentary:'''

* None.

[[#top|Top of current page]]

=== American Society of Civil engineers (ASCE) ===

Although ASCE does not define "project" explicitly, the concept of the project is deeply embedded in ASCE's vision of civil engineering. ''Project'' is mentioned in the ASCE Vision 2025 document many times; civil engineers are described as providing the "essential underpinnings of design and project oversight." [3]

Civil engineering will continue to be focused on "the definition, selection, and implementation of projects." [4]

'''Commentary:'''

As noted above in the PMI discussion, civil engineering executes projects in a much more structured and prescribed manner than many of the projects envisaged under PMI’s Body of Knowledge. However, there is nothing in either the PMI or ISO definitions that is incompatible with the notions ASCE espouses in its 2025 vision for civil engineering.

In this sense, the PMI and ISO definitions are more abstract than the concept as practiced by civil engineering. Simply put, civil engineering executes projects within a much deeper but still narrower spectrum of practices than most PMI or ISO projects.

This is the result of unique aspects in the practice of civil engineering such as:

* '''Physicality'''
* '''Labor specialization'''
* '''The unique role played by engineering design'''

; Physicality – the property of being a physical object or process

Civil engineers execute physical projects. They may start out as planning concepts or fundamental research, but they all result in the application of resources (tangible and intangible) to modify the built or natural environment. Software starts out as a human thought product and remains a thought product.

Civil engineering, like other disciplines such as mechanical and electrical engineering, is about physical projects that in themselves may have advanced technology but in the end are physical objects. In this sense, engineering is transformative. In physical object domains, there is no “co-location in the cloud”; things must be physically integrated under constraints such as the urban environment. Civil engineers play a key role in physically integrating projects.

:'''Civil engineers transform thought into physical objects that exist in many places in the global economy and then integrate them into the executed project.'''

; Labor Specialization – the division of labour

Software development is a relatively homogeneous workforce composed largely of professionals with some technical support. Project execution for civil engineers means producing designs using multidisciplinary and multi-skilled teams that are then logistically and physically integrated by crews whose work is predominantly craft in nature.

This means that project phasing becomes more fragmented along the lines of division of work and labor specializations. This adds complexity due to regulatory environments for manufacturing physical goods, transporting them into confined assembly areas, and the requirements for using labor in most jurisdictions.

:'''Civil engineers practice in heterogeneous project team environments that are multidisciplinary, with multiple levels of specialization in the team and a tendency towards blurred professional responsibilities.'''

; Engineering Design

Project execution in the built environment has a heavy emphasis on public safety and welfare that is not present in many software development projects. A closer parallel is in the area of [[wikipedia:Medical_device|medical devices]] that use [[wikipedia:Medical_software|software controls]], where there are strong regulatory controls on reliability.

With the physicality and specialization properties, civil engineers play a key and regulated role in developing designs to be implemented by other specialized teams and physically integrated on site, and then systemically integrated into the customer facility for acceptance. This imposes a functional structure to project execution that is unlike most software development.

:'''Project execution in the built environment must be accomplished in functional, cascading phasing. The project is conceptualized, then designed, procured, mobilized, physically integrated, systemically integrated into the facility, and then accepted by the customer.'''

Given this, project life cycles in civil engineering are predominantly predictive or plan-driven early in project execution. This remains true as the life cycle is decomposed level by level to contract packaging. Below this level, the phasing becomes a mix of predictive and adaptive development.

While there is flexibility in overlapping phases and decomposing phases into sub-phases, contract packages and work packages, the fundamental process must remain the same:

:'''Any individual work element at any level must be scoped, designed, procured, mobilized, physically and systemically integrated, and accepted by the customer.'''

Any one functional item might be performed by one individual or by a team of civil engineers working for multiple organizations with different contractual responsibilities, but in the end the design must be integrated to a point where it can serve as a basis for procurement and construction.

:'''With this core role of engineering design in project execution, civil engineers must be skilled at maintaining the integrity and adequacy of the design throughout a variety of project phasing modes and at any depth of sub-phasing, from contract packaging down to individual work packages.'''

:'''Civil engineering adds value above and beyond its reserved core roles in design by predictably and reliably integrating procurement, construction, and commissioning considerations into the executed project.'''

[[#top|Top of current page]]

== Programmatic frameworks for Civil Engineering Projects ==

=== Office of Management and Budget (OMB) ===

(Under construction.)

=== Department of Defense (DOD) ===

(Under construction.)

=== Department of Energy (DOE) ===

DOE's program guidance notes that all DOE projects have a:

:"single, vital commonality: the preparation, documentation, approval, implementation, and verification of '''project requirements'''." [5]

These requirements define the framework for going forward with the detailed descriptions and design necessary to meet the project performance (products, deliverables) established in the Mission Need Statement (MNS).

:Requirements define and describe the extent to which a function(s) must be executed, and are generally measured in terms of quantity, quality, coverage, timelines, safety, environmental, products, deliverables, etc. (DOE, ibid.)

=== Department of Transportation ===

==== Federal Aviation Administration (FAA) ====

(Under construction.)

==== Federal Transit Administration (FTA) ====

FTA's PCM has instances of reference to ''requirements'', while PMI uses the term extensively and ASCE has fewer explicit uses. In ASCE’s Body of Knowledge the term “project phase” or “project delivery” is not always used explicitly, which can be problematic for stakeholders and sponsors. FTA does not define the term in the same way PMI does in the PMBOK.

==== Federal Highway Administration (FHWA) ====

(Under construction.)

== Regulatory framework for Civil Engineering Projects ==

[[#top|Top of current page]]

== Legislative framework for Civil Engineering Projects ==

[[#top|Top of current page]]

== Limitations of the definition ==

(Under construction.)

== Working definition of the term ==

:"A '''project''' is a unique process consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve a defined set of objectives, conforming to specific requirements, including the constraints of time, cost and resources."

Civil engineers practice within a narrower subset of the class of all projects as discussed above and so therefore:

:"A civil engineering '''project''' is a unique set of activities and processes that is organized and directed towards a common purpose, objective or goal. It is undertaken by a project sponsor and assigned to a project office held responsible and accountable for project execution under constraint." [Note 3]

[[#top|Top of current page]]

== Beneficial Outcomes ==

(Under construction.)

== See also ==

Wiki article on [[wikipedia:Project|project]].

== Learning Outcomes ==

Learning outcomes are about what skills, knowledge, and abilities can be demonstrated when the content in this article has been mastered by the reader.

== Notes ==

* [Note 1] Semantic distinction between civil engineering programs, projects, and portfolios (originally indicated by a note marker).
* [Note 2] Definition derived from the concept of programs in OMB Circular A-109 (Major Systems Acquisition) and related sources.
* [Note 3] Civil-engineering-specific refinement of the ISO/PMI project definition.

== References ==

# Project Management Institute, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th ed., 2013, Glossary, p. 552.
# International Organization for Standardization (ISO), ISO/FDIS 9000:2005, Sec. 3.4 "Terms relating to process and product", p. 11.
# ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 3.
# ASCE, ''The Vision for Civil Engineering in 2025'', 2006, p. 59.
# ''Project Management Practices, Engineering Support and Requirements Generation, Analysis, and Use'', Sec. 2.0 Requirements Generation, Rev. E, June 2003.

Project Objective

2025-11-29T19:01:01Z

Pooyan: Restored “Project Objective” from archived RiskEngineering.org (Wayback, 2017).

== Basic considerations ==

Given the discussion on requirements, the question arises as to what is the relationship between project requirements and project objectives?

=== PMIBoK ===

PMI defines "objective" as:

:"Something toward which work is to be directed, a strategic position to be attained, a purpose to be achieved, a result to be obtained, a product to be produced, or a service to be performed."
(PMBOK® Guide, p. 575)

=== ISO ===

(Under construction.)

== Limitations of the definition ==

(Under construction.)

== Working definition of the term ==

:Conditions or capabilities in the form of material assumptions, dependencies, and constraints that are to be met by the project or present in the product, service, or result to satisfy an agreement or other formally imposed specification and includes the needs and expectations of the project sponsor, customer, and other stakeholders in adequate and detailed quantification and documentation to be totally satisfactory as a basis for establishing the project scope baseline and to be measured once project execution begins.

:(What documentation issues are there?)

== See also ==

Wiki article on [[wikipedia:Project_management|Project management]].

== Notes ==

(Under construction.)

[[Category:Definition]]

Project stakeholder

2025-11-29T18:59:26Z

Pooyan: Restored “Project stakeholder” from archived RiskEngineering.org (Wayback, 2017).

Regulatory agency

2025-11-29T18:56:49Z

Pooyan: Restored “Regulatory agency” from archived RiskEngineering.org (Wayback, 2017).

== Basic considerations ==

=== Further Guidance ===

=== Beneficial Outcomes ===

== Working definition of the term ==

== Limitations of the definition ==

== See also ==

Wiki article on [[wikipedia:Regulatory_agency|Regulatory agency]].

== Notes ==

== References ==

[[Category:Definition]]

Resources Portal

2025-11-29T18:53:55Z

Pooyan: Restored Resources Portal from archived RiskEngineering.org (Wayback, 2017).

== Portal Overview ==

''Again, please note our [[Risk_wiki:About#Website_Terms_of_Use|site terms of use!]]''

'''[[Frameworks_for_program_management|Frameworks for program management]]''' series for understanding the evolution of agency policy and practice on program management at [[Framework_for_program_management_at_the_Federal_Transit_Administration_(FTA)|FTA]], [[Framework_for_program_management_at_the_Federal_Highway_Administration_(FHWA)|FHWA]], [[Framework_for_program_management_at_the_Environmental_Protection_Agency_(EPA)|EPA]], [[Framework_for_program_management_at_the_United_States_Army_Corps_of_Engineers_(USACE)|USACE]], [[Framework_for_program_management_at_the_United_States_Department_of_Energy_(DOE)|DOE]].

'''[[Frameworks_for_project_management|Frameworks for project management]]''' series for understanding the evolution of agency policy and practice on project management at [[Project_Management_Plan_Policy_Framework_for_FTA_projects|FTA]], [[Framework_for_project_management_at_the_Federal_Highway_Administration_(FHWA)|FHWA]], [[Framework_for_project_management_at_the_Environmental_Protection_Agency_(EPA)|EPA]], [[Framework_for_project_management_at_the_United_States_Army_Corps_of_Engineers_(USACE)|USACE]], [[Framework_for_project_management_at_the_United_States_Department_of_Energy_(DOE)|DOE]].

:[https://science.energy.gov/opa/project-management/processes-and-procedures/department-of-energy/ Project Management Processes and Procedures] at the U.S. Department of Energy. Hanford WA [http://pdw.hanford.gov/arpir/ public materials].

'''[[Uncertainty_and_Risk_in_Civil_Engineering_Practice|Frameworks for Uncertainty and Risk]]''' series for understanding the evolution of policy and practice on various uncertainty components such as [[Risk|risk]] and [[Hazard|hazard]] in [[Civil_Engineering|civil engineering]] and other professions.

'''[[Frameworks_for_project_risk|Frameworks for project risk]]''' series for understanding the evolution of agency policy and practice on project risk at [[Regulatory_Framework_for_project_risk_at_the_Federal_Transit_Administration_(FTA)|FTA]], [[Framework_for_project_risk_at_the_Federal_Highway_Administration_(FHWA)|FHWA]], [[Framework_for_project_risk_at_the_Environmental_Protection_Agency_(EPA)|EPA]], [[Framework_for_project_risk_at_the_United_States_Army_Corps_of_Engineers_(USACE)|USACE]], [[Framework_for_project_risk_at_the_United_States_Department_of_Energy_(DOE)|DOE]].

'''[[History_of_Risk|History of Risk]]''' series in a [[Basic_Concepts_of_Program_Management|program management]] context for History of Risk at [[History_of_Risk_at_the_Federal_Highway_Administration_(FHWA)|FHWA]], [[History_of_Risk_at_the_Environmental_Protection_Agency_(EPA)|EPA]], [[History_of_Risk_at_the_United_States_Army_Corps_of_Engineers_(USACE)|USACE]], [[History_of_Risk_at_the_United_States_Department_of_Energy_(DOE)|DOE]] and the [[Federal_Transit_Administration_(FTA)|FTA]]:

* [[History_of_Risk_Identification_at_the_Federal_Transit_Administration_(FTA)|History of Risk Identification at the Federal Transit Administration (FTA)]]
* [[History_of_Risk_Modeling_at_the_Federal_Transit_Administration_(FTA)|History of Risk Modeling at the Federal Transit Administration (FTA)]]
* [[History_of_Risk_Assessment_at_the_Federal_Transit_Administration_(FTA)|History of Risk Assessment at the Federal Transit Administration (FTA)]]
* [[History_of_Risk_Mitigation_at_the_Federal_Transit_Administration_(FTA)|History of Risk Mitigation at the Federal Transit Administration (FTA)]]

For different approaches to risk, consider the following:

* '''Evolution of risk''' at the [[History_of_Risk_at_the_National_Research_Council|National Research Council]].
* NOAA materials on [http://nrc.noaa.gov/ScientificIntegrityCommons/ResourcesandDocuments.aspx data quality and integrity].
* U.S. Department of Commerce materials on [http://ocio.os.doc.gov/ITPolicyandPrograms/Information_Quality/PROD01_003167 guidance documentation].

'''[[Functional_Risk|Functional Risk]]''' sub-practices in the context of managing specific projects or programs such as [[Project_Definition_risk|Project Definition risk]], [[Geotechnical_risk|Geotechnical risk]], [[Project_Delivery_Risk|Project Delivery Risk]], [[Construction_Phase_Risk|Construction Phase Risk]] and [[System_integration_and_testing_phase_risk|System integration and testing phase risk]].

'''[[Risk_CoFactor|Risk CoFactor]]''' series such as [[Stakeholder_Action|Stakeholder Action]], [[Knowledge_Gaps|Knowledge Gaps]], [[Data_Gaps|Data Gaps]], [[Underlying_Variability|Underlying Variability]].

'''[[Specific_Project_Risk|Specific Project Risk]]''' series for [[Transit_Project_Risk_Series|Transit Project Risk Series]], [[Highway_Project_Risk_Series|Highway Project Risk Series]], [[Waterway_Project_Risk_Series|Waterway Project Risk Series]], [[Reclamation_Project_Risk_Series|Reclamation Project Risk Series]], [[Energy_Project_Risk_Series|Energy Project Risk Series]].

'''General information on governmental agencies'''

* WikiSource materials at the Federal Government of the United States / Executive branch.

::[https://en.wikisource.org/wiki/Portal:United_States_Department_of_Transportation U.S. Department of Transportation] and its underlying agencies [https://en.wikisource.org/wiki/Portal:Federal_Transit_Administration FTA], [https://en.wikisource.org/wiki/Portal:Federal_Railroad_Administration FRA], [https://en.wikisource.org/wiki/Portal:Federal_Highway_Administration FHWA], [https://en.wikisource.org/wiki/Portal:Office_of_Inspector_General_for_the_Department_of_Transportation DOT OIG].

'''Knowledge and information'''

* [[wikipedia:Information_mapping|Information mapping]]
* [[Philosophy_of_Engineering|Philosophy of Engineering]] series.

'''Pedagogy'''

* On [http://writing.umn.edu/tww/discipline/engineering/ writing in engineering] (for use in syllabi).
* [http://www.teachthought.com/technology/100-search-engines-for-academic-research/ 100 search engines for engineering research] and [http://blog.teachthought.com/learning/project-based-learning/13-timeless-project-based-learning-resources/ project-based learning]. Thanks to Te@chthought and to [http://www.schrockguide.net/assessment-and-rubrics.html Kathy Schrock's Guide to Everything].
* [http://ar.cetl.hku.hk/am_cm.htm Concept mapping], [http://ar.cetl.hku.hk/am_case_study.htm case study rubrics from the University of Hong Kong].

Requirement

2025-11-29T18:52:06Z

Pooyan: Requirement” article from archived RiskEngineering.org (Wayback, 2017).

'''<big>This page is under construction ...</big>'''

; See also
''See also [[Project_Development|Project Development]], [[Project_Definition|Project Definition]], [[Project_Life_Cycle_and_Phase_Models|Project Life Cycle and Phase Models]], [[Project_Delivery_Methods|Project Delivery Methods]].''

; Quote
''The hardest single part of building a (project) is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements... No other part so cripples the resulting (project) if done wrong. No other part is as difficult to rectify later.''<ref name="Heimdahl">Heimdahl, Mats PE. "Let’s not forget validation." (2005) accessed at [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.3333&rep=rep1&type=pdf] on 26 October 2016. Heimdahl cites F. Brooks, "No silver bullet: Essence and accidents of software engineering", IEEE Computer, April 1997, pp. 10–19.</ref>

== Basic considerations ==

"Most contemporary design methodologies avoid premature freezing of requirements.

...

Traditional design engineering is still pursued, but it is less and less isolated by trade-offs and optimization within a discipline-limited set of purely physical variables. This is nowhere more evident than in the linkages of design variables to economic considerations. Representations of interactions of product and process variables on costs have become central to product realization in many domains. Multi-attribute, multi-stakeholder design contexts, laced with uncertainties and rich in information, are the norm. The framing of critical design decisions across contributing disciplines is central to success in such contexts."<ref name="DecisionMaking">"2. Decision Making in Engineering Design." in ''Theoretical Foundations for Decision Making in Engineering Design''. Washington, DC: The National Academies Press, 2001, ISBN 0-309-54224-3. [http://www.nap.edu/catalog/10502.html]</ref>

== Semantics and logical framework ==

(Under construction.)

The semantics and logical framework for the concept of requirements in civil engineering projects has several dimensions.

* The semantics problems are ...fold.

...

The logical framework for the concept of requirements in civil engineering projects has several dimensions:

*

Within the requirements term definition are more subcomponents such as [[Assumptions|assumptions]], [[Constraints|constraints]] and [[Dependency|dependencies]].
The three definitions for requirements used several common terms ([[Material|material]] and [[Reasonable|reasonable]]) for the first time and they should be defined in the project management context. (An aside on this point is that the case holds equally well for the engineer conducting the design process, which we will get to later.)

== Practice frameworks for Requirements ==

It is helpful to lay a foundation for this discussion with PMI's concept of requirement.

=== Project Management Institute BoK ===

PMI defines a requirement as a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.<ref name="PMI1">Project Management Institute, ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide)'', 5th edition, 2013, Glossary, p. 557.</ref>

PMI uses the term in defining [[Project_management|project management]], noting that it applies knowledge, among other things, to project activities to meet project requirements. One of the striking features of the PMI definition is the overlapping usage of requirements and objectives as well as a lack of integration with constraints.

Although the BoK glossary does define requirements, contextually some sections allow a synthetic definition to be developed (see Sec. 5.2 “Collect Requirements”, p. 110).

In PMI's vision, requirement ....<ref name="PMI2">Project Management Institute, ''PMBOK® Guide'', 5th edition, 2013, op. cit.</ref><ref name="PMI3">Project Management Institute, ''PMBOK® Guide'', 5th edition, 2013, op. cit.</ref>

=== International Organization for Standardization (ISO) ===

The [[wikipedia:International_Organization_for_Standardization|International Organization for Standardization (ISO)]] in its [[wikipedia:ISO_21500|ISO 21500]] document intends to provide overarching guidance on project management and is not intended for certification or registration purposes.<ref name="ISO21500">Wikipedia article on ISO-21500, accessed 5 February 2015.</ref>

=== Software Development Process ===

Wikipedia notes that the Unified Software Development Process or [[wikipedia:Unified_Process|Unified Process (UP)]] is an iterative and incremental software [[wikipedia:Iterative_and_incremental_development|iterative and incremental development]] process framework.<ref name="UP1">Wikipedia article on Unified Process, accessed 15 March 2015.</ref>

As a process, it provides the guidance and necessary steps to implement a software project; i.e. "a complete set of activities needed to transform users' requirements into a product; a process is a template for creating projects."<ref name="UP2">Booch, Grady; Ivar Jacobson; James Rumbaugh. ''The Unified Software Development Process''. Addison-Wesley, 1999, p. 15.</ref>

It defines '''requirements''' as ...

=== Civil Engineering practice frameworks ===

(Under construction.)

== Programmatic frameworks for Requirements ==

=== Office of Management and Budget (OMB) ===

(Under construction.)

=== Department of Defense (DOD) ===

(Under construction.)

=== Department of Energy (DOE) ===

DOE's program guidance notes that all DOE projects have a "...single, vital commonality: the preparation, documentation, approval, implementation, and verification of '''project requirements'''."<ref name="DOE">''Project Management Practices, Engineering Support and Requirements Generation, Analysis, and Use'', Sec. 2.0 Requirements Generation, Rev. E, June 2003.</ref>

These requirements define the framework for going forward with the detailed descriptions and design necessary to meet the project performance (products, deliverables) established in the Mission Need Statement (MNS).

:Requirements define and describe the extent to which a function(s) must be executed, and are generally measured in terms of quantity, quality, coverage, timelines, safety, environmental, products, deliverables, etc. (DOE, op. cit., p. 7.)

=== Department of Transportation ===

==== Federal Aviation Administration (FAA) ====

(Under construction.)

==== Federal Transit Administration (FTA) ====

FTA's PCM has ... instances of reference to requirement while PMI has ... and ASCE has none. In this case, ASCE does not use the term "project phase" or "project delivery" in its body of knowledge. For a stakeholder or sponsor this is very problematic. Lastly, FTA doesn't define the term but PMI in its BoK does.

==== Federal Highway Administration (FHWA) ====

(Under construction.)

== Regulatory framework for Requirements ==

(Under construction.)

== Further Guidance ==

(Under construction.)

== Beneficial Outcomes ==

(Under construction.)

== Working definition of the term ==

:Conditions or capabilities in the form of material assumptions, dependencies, and constraints that are to be met by the project or present in the product, service, or result to satisfy a set of objectives which includes the needs and expectations of the project sponsor, customer, and other stakeholders and established as part of an agreement or other formally imposed specification.

:Requirements are to be quantified and defined in adequate, detailed [[Documentation|documentation]] that is totally satisfactory as a basis for establishing the project scope baseline and performance measurement once project execution begins.

== Limitations of the definition ==

(Under construction.)

== See also ==

* [[wikipedia:Requirement|Requirement]]
* [[wikipedia:Requirements_analysis|Requirements analysis]]
* [[wikipedia:Project_management|Project management]]
* [[wikipedia:Systems_development_life_cycle#Life_cycle|Software life cycle]]

Google searches on project delivery:

* [https://www.google.com/search?tbm=isch&tbs=rimg%3ACWbL3K91spKcIjjBmhZX16d0xdLD_1cEvW0qcZgfDvlHZUDv0t_1nTNIxApMNHXGTZNMcmEMNXtFYTMMIzmkrh-7QxZioSCcGaFlfXp3TFETcNq85LxqayKhIJ0sP9wS9bSpwR_1P8Bz39yJZcqEglmB8O-UdlQOxEkcyBmUfRYvioSCfS3-dM0jECkESJUbHQI3P37KhIJw0dcZNk0xyYRRBzQsj2qJUYqEgkQw1e0VhMwwhGZXHDKr5ASpioSCTOaSuH7tDFmERT5DMJkI_17A Hand drawn class notes]

== Notes ==

(Under construction.)

== References ==

<references/>

[[Category:Definition]]

Agency Guidance Practices for Civil Engineering

2025-11-29T18:15:38Z

Pooyan: Restored page from archived RiskEngineering.org (Wayback, 2017).

== Basic considerations ==

==== Further Guidance ====

==== Beneficial Outcomes ====

Well-designed guidance documents serve many important or even critical functions in Federal regulatory programs:

* Agencies may provide helpful guidance to interpret existing law through an interpretive rule or to clarify how they tentatively will treat or enforce a governing legal norm through a policy statement.
* Guidance documents, used properly, can channel the discretion of agency employees, increase efficiency, and enhance fairness by providing the public clear notice of the line between permissible and impermissible conduct while ensuring equal treatment of similarly situated parties. [1]

== Logical framework for Engineering Guidance ==

== Regulatory framework for Engineering Guidance ==

=== US Office of Management and Budget (OMB) Policy guidance ===

OMB's objective was to ensure that agency guidance practices be more transparent, consistent and accountable. [2] The agency noted that:

"Because it is procedurally easier to issue guidance documents, there also may be an incentive for regulators to issue guidance documents in lieu of regulations."

A judicial comment put this concern in context:

> "Congress passes a broadly worded statute. The agency follows with regulations containing broad language, open-ended phrases, ambiguous standards and the like. Then as years pass, the agency issues circulars or guidance or memoranda, explaining, interpreting, defining and often expanding the commands in regulations. One guidance document may yield another and then another and so on. Several words in a regulation may spawn hundreds of pages of text as the agency offers more and more detail regarding what its regulations demand of regulated entities. Law is made, without notice and comment, without public participation, and without publication in the Federal Register or the Code of Federal Regulations." [3]

=== Working definition of the term ===

Guidance documents often come in a variety of formats and names, including interpretive memoranda, policy statements, guidances, manuals, circulars, memoranda, bulletins, advisories, and the like.

Guidance documents include, but are not limited to, agency interpretations or policies that relate to: the design, production, manufacturing, control, remediation, testing, analysis or assessment of products and substances, and the processing, content, and evaluation/approval of submissions or applications, as well as compliance guides.

Guidance documents do not include solely scientific research. Although a document that simply summarizes the protocol and conclusions of a specific research project (such as a clinical trial funded by the National Institutes of Health) would not qualify as a guidance document, such research may be the basis of a guidance.

=== Limitations of the definition ===

One important distinction in this process of issuing guidance is its distinction from [[wikipedia:Rulemaking|rule-making]].

OMB's 2007 bulletin in Section I(3) defined the term "guidance document" as an agency statement of general applicability and future effect, other than a regulatory action, that sets forth a policy on a statutory, regulatory, or technical issue, or an interpretation of a statutory or regulatory issue. The bulletin's definition of “guidance document” encompasses all guidance materials, regardless of format. [4]

* The intent of OMB's bulletin (itself the subject of a regulatory rule-making) was to make clear that a guidance document cannot impose a legally binding requirement. [5]

=== See also ===

* [[wikipedia:Guidance document#Good_Guidance_Practices|Guidance Practices]]

=== References ===

# Final Bulletin for Agency Good Guidance Practices, US Office of Management and Budget (OMB), Bulletin No. 07-02, 2007.
# 2007, OMB, op. cit.
# Judicial comment from Appalachian Power, 208 F.3d at 1019, cited by OMB at p. 3, op. cit.
# 2007, OMB, ibid., p. 7.
# 2007, OMB, ibid., p. 6.

[[Category:Definition]]

Body of Knowledge

2025-02-12T14:37:54Z

Pooyan: / Body of Knowledge

== Bodies of Knowledge ==

From **Risk Engineering/Civil Engineering**

== Basic Considerations ==
A **body of knowledge (BoK)** is the accepted **ontology** for a specific domain. A BoK is more than simply a:
* Collection of terms
* Professional reading list
* Library or website
* Collection of information

Instead, a BoK represents **consensus knowledge** that defines and organizes a profession's **understanding of itself** and its **role in the global economy**. Additionally, these knowledge bodies allow **technical and lay personnel** to access structured knowledge through a **taxonomy** such as Bloom’s.

### **Engineering Knowledge**
Unlike general knowledge, **engineering knowledge** is a specialized form of knowledge. Knowledge, in the broadest sense, can be defined as:

<blockquote>
"...a fluid mix of framed experience, values, contextual information, and expert insight that provides a framework for evaluating and incorporating new experiences and information." <ref>Davenport, T.H. and Prusak, L. (2000), Working Knowledge: How Organizations Manage What They Know, Harvard Business School Press, Boston, MA.</ref>
</blockquote>

In non-discipline cases, knowledge can be communicated through **documentation**. However, in fields like **civil engineering**, knowledge is embedded in **documents, repositories, organizational activities, processes, goodwill, and workflows**.<ref>Dutta/Madalli, Trends in Knowledge Modeling and Knowledge Management: An Editorial.</ref>

== Logical Framework ==
(Section under construction)

== Regulatory Framework ==
(Section under construction)

== Practice Frameworks (Under Construction) ==
Several institutions have developed **bodies of knowledge** that define engineering and technical disciplines.

### **Institute of Electrical and Electronics Engineers (IEEE) Computer Society**
The IEEE established **SWEBOK** to provide:

<blockquote>
"(A) consensually validated characterization of the bounds of the software engineering discipline and to provide topical access to the Body of Knowledge supporting that discipline. The descriptions of the Knowledge Areas (KA) are designed to discriminate among the various important concepts, permitting readers to find their way quickly to subjects of interest."<ref>Abran, Alain, et al. "Guide to the Software Engineering Body of Knowledge: 2004 Edition-SWEBOK." IEEE Computer Society (2004).</ref>
</blockquote>

### **American Society of Civil Engineers (ASCE) BoK**
(Details under construction)

### **National Society of Professional Engineers (NSPE) Engineering Body of Knowledge (BoK)**
The **NSPE BoK** defines the **depth and breadth of knowledge, skills, and attitudes** required for **entry into professional engineering practice**:

<blockquote>
"A profession’s BoK is its common intellectual ground—it is shared by everyone in the profession regardless of employment or engineering discipline."<ref>Engineering Body of Knowledge, National Society of Professional Engineers (NSPE) 2013.</ref>
</blockquote>

Capabilities within the **NSPE BoK** are learned through a **combination of education and experience** and define **professional competency**.

### **PMIBoK (Project Management Institute)**
The **PMI Body of Knowledge (PMIBoK)** defines:

<blockquote>
“The sum of knowledge, published and unpublished, within the profession of project management. It consists of proven, traditional practices that are widely applied and innovative, yet evolving.”<ref>Project Management Institute, Body of Knowledge (PMIBoK), 5th edition, 2013.</ref>
</blockquote>

The **PMIBoK Guide** identifies:
1. **Generally recognized practices** applicable to most projects.
2. **Good practices** that enhance success rates.
3. **Adaptable approaches** where practices should not be applied rigidly to all projects.

### **ISO**
(Section under construction)

== Limitations of the Definition ==
This **body of knowledge** represents a **distilled version** of the overall knowledge in engineering. Unlike **best practices**, PMI now refers to "good practices" to reflect the **evolutionary nature** of the profession.<ref>PMIBoK 5th Edition, 2013.</ref>

== Working Definition of the Term ==
(Section under construction)

== Beneficial Outcomes ==
Some of the **beneficial outcomes** of developing BoKs include:
* Achieving a **consistent national or global standard** for a profession.
* Establishing **disciplinary boundaries** between professions.
* Defining **policy or regulatory constraints** regarding professional responsibilities.

== See Also ==
* [[Wiki article on Body of Knowledge]]

== Notes ==
{{Notelist}}

== References ==
<references />

Bridging the Gaps: Better Infrastructure Project Management and Civil Engineering

2025-02-11T23:22:05Z

Pooyan: /* Metropolitan Transportation Authority */

'''Bridging the Gaps: Better Infrastructure Project Management and Civil Engineering

Practices Based on Lessons from the Second Avenue Subway Project'''

== Abstract==
The importance of thorough geotechnical investigations, effective communication, and adaptability to ensure the completion of complex transit projects on time and under budget cannot be emphasized enough. The Second Avenue Subway (SAS) project in New York City has come under intense scrutiny owing to numerous delays and massive cost overruns. This paper highlights the need for a transformation in civil engineering graduate programs to better equip students and practitioners for the complexities of transit project deliveries. Due to an overemphasis on theoretical computational practices, civil engineers have neglected the development and interpretation of policy knowledge, leading to critical decisions being made by those with limited sustainability understanding. This trend, combined with the ineffective communication of technical aspects, has contributed to escalating costs and misaligned sustainability outcomes in transit projects. Herein, a holistic learning approach that encompasses project management, public policy, and real-world case studies is presented to bridge the current knowledge gap and prepare future professionals for successfully delivering sustainable, on-time, within-budget transit projects.

Herein, the management, engineering, and administrative practices employed in the SAS project are comprehensively analyzed. Key assumptions made by the project management and design teams are highlighted that led to unexpected costs and delays. The role of the Metropolitan Transportation Authority (MTA) as an administrative agency is examined and gaps in engineering knowledge and practices within the MTA are identified.

The analysis results demonstrate the need to address the financial sustainability of transit projects and obtain a funding equilibrium. In addition, the MTA needs to prioritize hiring and promoting individuals with engineering credentials, increase transparency and accountability, and foster stronger partnerships with external stakeholders.
The lessons learned from the SAS project can be used to inform future infrastructure projects and guide the transformation of the MTA into a more efficient, cost-effective, and responsive organization.

==Practical Applications==

This paper addresses the challenges faced by civil engineering professionals in delivering transit projects on time and within budget. Modern civil engineers must have a diverse set of skills, encompassing engineering, planning, economics, environmental science, management, finance, and law. Additionally, they must understand public policy and sociology while being updated on the challenges of translating public policies into engineering outcomes.
The paper emphasizes the need for meaningful change in civil engineering graduate school programs to include project management, public policy, and professional practices using real-world cases and public projects. This will equip students and practitioners with necessary tools to plan and manage transit projects effectively.
Because of the increased complexity of US public administration since WWII, learning transit fundamentals and problem-solving techniques within the context of delivering sustainable projects by graduate students is urgently required. Additionally, this paper underscores the importance of modifying civil engineering education to better prepare professionals for the challenges and opportunities in the realm of transit project delivery.

==Introduction==

Unlike other engineering disciplines, civil engineering is inextricably intertwined with public projects, which differ dramatically from other engineering products because they do not follow a single pattern or protocol (Harris and McCaffer 2013). Public projects develop in response to particular societal and governmental needs, and thus the broader economic, environmental, and political contexts in which they are embedded must be considered. The successful completion of these projects requires civil engineers who are not just technically competent but also able to understand public policy as well as political, environmental, and sociological concerns (Labuschagne and Brent 2004). Relatedly, civil engineers do not develop or work on products that can be sold to generate revenue but on projects that must secure governmental funding and approval as well as satisfy not only individual users but also public stakeholders (Koppenjan and Enserink 2009).

Kaufman (1956) outlined three distinct phases in the evolution of administrative leadership in the United States to address the core value of representativeness in a democracy. The first phase focused on representativeness in the nascent government with “No taxation without representation” as the principal interest of independence. The second phase was the quest for “neutral competence” that began after the Civil War and continues to this day. The aim was for the government to work based on explicit and objective standards rather than personal, party, or other obligations and loyalties. The slogan “Take administration out of politics” gave rise to the Civil Service Act of 1883, which aimed to control the selection of government workers by establishing a merit-based hiring system and offering formal training to civil servants at universities (Kaufman 1956). Although states and localities were slow to adopt these practices, they have made significant strides in recent years. The third phase focuses on the need for “executive leadership” to bridge the gap between the unresponsiveness of neutral competence and the public’s demand for clear communication. Civil engineers can play a crucial role in this process by negotiating effectively with bureaucratic entities and forming alliances with legislative committees and groups, which will allow them to gain greater autonomy in decision-making if they can establish clear expectations for knowledge and outcomes.

However, civil engineering has not yet established best practices in three areas: public policy, project management, and professional practice. This has posed challenges for individual engineers within powerful organizations to influence policy decisions for the public’s benefit.

In the United States, transit projects have long been a source of frustration for the public because of their high costs and delays. Media headlines have highlighted these issues and have painted a picture of inefficiency and exorbitance in the public sector (Gordon and Schleicher 2015, Rosenthal and Fitzsimmons 2017). Scholars and policy analysts have proposed various explanations for these problems, including the cost of land, regulations, and community opposition (Glaeser and Poterba 2020). However, the evolution of civil engineering, particularly the narrowing of the knowledge base and skill set associated with the profession, may be a significant but overlooked factor. Of course, this narrowing is not a development exclusive to civil engineering alone. Abbott (1986) noted that professions often become more specialized over time, which leads to a reduction in the knowledge and skill set of individuals. However, while such specialization may make sense in other professions, the narrowing of civil engineering has contributed to a failure to fully integrate the technical requirements of transit projects with political, social, environmental, and economic needs. This has resulted in a disconnect between the technical aspects of transit projects, which civil engineers are trained to address, and the non-technical aspects, which they are not. This has led to increased costs and public frustration. Civil engineers can play a significant role in overcoming this disconnect and contributing to the development and execution of successful and sustainable transit projects, but only if their own education and training shifts to (re)emphasizing sustainability. A clearer understanding of how the capacity and role played by civil engineers has changed over time is needed to help address these problems.

The Second Avenue Subway (SAS) project in New York City (NYC) has garnered attention because of design issues, construction challenges, and decisions that led to massive cost overruns. This project faced numerous design challenges including building a new subway line in a densely populated urban area and accounting for varying geological conditions along the route. Ongoing criticism of the SAS project’s cost and delays in completion have resulted in scrutiny of the project management and decision-making processes. In this paper, the SAS project is used as a case study to highlight the need for a more detailed study on engineering alternatives and the establishment of best practices in project management to prevent cost overruns and delays in future projects.

== Civil Engineering Knowledge==
===From 1800 to 1950===
In the early days of civil engineering in the United States, ad hoc public commissions or chartered companies managed public construction projects (Kaufman 1956). With the evolution of the field, civil engineering became known as “land development” (Williams 1922). The primary concern of such commissions was feasibility, which led to the first wave of public projects consisting of canal construction (Poor 1860). The Concord Canal Report (1825) emphasized assessing a project’s economic and technical value before execution, which necessitated consulting experts in mechanics, hydraulics, geology, and soils to estimate the costs, benefits, and results. When debating whether Massachusetts should promote canals or railroads, Governor Levi Lincoln consulted experts in various fields to resolve questions related to labor, expenses, and project benefits and results (Poor 1860).

The Civil War represented a turning point for civil engineering as railroads were constructed to facilitate transportation of Union armies, which laid the groundwork for modern civil engineering. In the post-Civil War era, civil engineers collaborated with investors to finance and build railroads, which significantly contributed to the country’s economic growth (Civil War Railroad Report 1865). Railway engineers needed knowledge in finance and business management because private financiers were the primary investors in railroads while the government granted rights of way. Gotshall (1903) highlighted the importance of these skills by demonstrating the practicability of high-speed electric railways from both engineering and commercial perspectives. In the late 19th century, Thurston argued for a dedicated method of publication to provide engineers with detailed and specific knowledge in their field. He called for an institution devoted to providing individuals with technical training and practical laboratory experience (Durand 1929), which aligned with the trend for various fields at the time of specialization in knowledge and skills. The emergence of professional societies such as the American Society of Civil Engineers (ASCE) facilitated this trend by providing a platform for knowledge exchange and expertise. Thurston’s vision and the emergence of professional societies laid the foundation for the growth and development of civil engineering as a full-fledged profession in the United States. However, this also led to the emergence of new administrative challenges and changes that significantly affected its ability to expand its intellectual dominance among engineering disciplines (Durand 1929).

At the beginning of the 20th century, civil engineering encompassed a combination of factual, conceptual, and procedural knowledge. Unlike law and medicine, engineering schools were founded by college-trained professors who designed the curricula. Although the apprenticeship method was used to train engineers, it never developed into significant engineering schools. Teaching theory before practice led to many first- and second-year students feeling disoriented and disheartened because they continued to engage in the same routine of reading books and studying abstract symbols as they did in high school (Durand 1929). This disconnection between academia and engineering practice became evident during the construction of massive projects that required unprecedented coordination, planning, and management. Parsons (1902), who was the Chief Engineer of the NYC Rapid Transit Commission at the time, warned that the engineer of the future would need to deal not only with calculations but also with human needs, industrial demand, finance, and legislation. Engineers would need to combine technical and economic expertise to conceive, plan, design, execute, and manage projects.

===From 1950 to the Present===
The post-World War II era brought several challenges to civil engineering, including the bankruptcy of the railroad industry, massive administrative changes, and the widening gap between academia and professional practice. The United States underwent a major administrative shift by transitioning from ad hoc decision-making when funding transit projects to a more structured and centralized system emphasizing executive leadership, efficiency, and data-driven decisions (Barzelay 2001). This approach influenced agencies such as the Federal Transit Administration (FTA), where urban planners began to outnumber civil engineers (Lewis 2004). Despite improvements in transit planning, a disconnect persisted between professionals and politicians, which raised concerns about the effectiveness of decision-making and implementation (Levinson 2003). Urban planning evolved as a profession in response to the challenges of urbanization in the late 19th century (Hall 2002). Initially, city planning focused on the City Beautiful concept. However, as cities expanded, land economics became increasingly important (Filion and Hammond 2003). Lawyers, civil engineers, and urban planners all began playing key roles in shaping American infrastructure (Peterson 2003).

The ASCE did not heed Parsons’ warning from the early 20th century, and they neglected to advance their knowledge in project management, public policy, and professional practice (Fitch 1999). When the transit industry went bankrupt, the National Environmental Policy Act (NEPA, Department of Energy 1970) was published, and the FTA issued several policy documents on funding strategies for transit projects. Civil engineers struggled to add engineering interpretations of these policy documents with regard to recommending best practices and ensuring that new engineers are educated accordingly in universities (Barzelay 2001). In addition, a governmental shift toward a business-oriented approach led to a decline in practical professors and licensed engineers, which caused a loss of influence by civil engineers (Dzur 2008). Meanwhile, organizations such as the Project Management Institute have enabled managers without an engineering background to assume high decision-making positions within governments and engineering firms offering construction management services (Kerzner 2009). Abbott (1986) argued that business-oriented practices are more applicable to professions that lack technical roots and thus prioritize business strategies. However, professions such as civil engineering and medicine derive their legitimacy not just from efficiency and quality management but also from the technical skill and experience inherent to their fields.

Following the Civil Service Act and the rise of neutral competence, civil engineers should have developed a series of management practices tailored to enhance the overall functioning of transit organizations, which would have helped them to effectively manage and maintain the developed infrastructure as well as provide informed engineering interpretations of policy documents such as the NEPA (Perry and Rainey 1988). Unfortunately, civil engineers did not work on developing and interpreting policy knowledge, but rather they became focused on a narrow scope of computational practices in design, which was driven by an excessive theoretical focus in academia (Petroski 2011). This knowledge gap, combined with the lack of participation by civil engineers in interpreting the NEPA, led to major planning decisions being made by planners and economists with a limited understanding of sustainability (Council on Environmental Quality 2014). Consequently, NEPA is now perceived as a permitting tool rather than an engineering document, which has caused public participation to be associated with Not in My Backyard (NIMBY) attitudes and resulted in misaligned sustainability outcomes for transit projects (Kates et al. 2005; Real Estate Record and Builders’ Guide 1868–1884). Urban planners and civil engineers both play critical roles in evaluating transit project options. While urban planners focus on the socioeconomic impacts, civil engineers concentrate on the technical and operational aspects. However, the failure of civil engineers to effectively communicate technical issues to stakeholders has led to the NEPA being regarded as a bureaucratic process, which has caused transit project costs to soar (Petroski 2011).

The inability of civil engineering to adapt to the evolving landscape of public administration and the growing influence of policy documents on engineering practice may have weakened its standing. Furthermore, practitioners are unable to effectively shape their academic foundations, unlike their counterparts in medicine and law (Petroski 2011). This has led to disjointed and ad hoc academic solutions, particularly in graduate programs, which fail to provide civil engineering students with the necessary knowledge and skills to understand a project’s life cycle in the context of project management as well as policy knowledge for funding and executing transit projects on time and within budget (Perry and Rainey 1988).

In an attempt to address these shortcomings, construction management has been introduced as a hybrid program between business and engineering schools (Petroski 2011). Unfortunately, these programs often lack an engineering-focused approach to expanding undergraduate curricula to develop students’ understanding of public policies, project management, and professional practice. Instead, they primarily emphasize the memorization of terminology and the use of ad hoc computational software (Katz 2012). In professional practice, civil engineers have struggled to adapt to changing demands, including new technologies and increased regulations. The profession must reassess its approach and incorporate the necessary skills and knowledge to effectively contribute to the construction of sustainable infrastructure projects (Petroski 2011). The lack of engineering interpretation of public regulations such as the NEPA and the FTA’s Capital Investment Grants Program requirements has significantly affected the planning and execution of infrastructure projects (Council on Environmental Quality 2014). The ASCE has acknowledged the issue of practical experience within the profession, but it has struggled to intervene in graduate education (ASCE 2008). Moreover, the lack of input by civil engineers in interpreting the NEPA has led to major planning decisions being made by planners and economists with a limited understanding of sustainability (Council on Environmental Quality 2014).

To tackle the challenges faced by civil engineers, a holistic approach to project delivery is needed that combines technical expertise, policy understanding, and quality management practices. Although the Accreditation Board for Engineering and Technology (ABET) ensures the quality of undergraduate education, graduate programs often lack these three essential components. ABET was established in 1932 as the Engineers’ Council for Professional Development and was initially focused on the technical content taught in courses. In 1997, ABET shifted its emphasis to learning outcomes with the introduction of Engineering Criteria 2000 (EC2000) (ABET 2021). This transition led to a more flexible approach, which is a key quality needed for professionals to succeed in fields of vital importance to society (Kates et al. 2005). By investing in academic knowledge and prioritizing technical expertise over business-oriented practices, civil engineering can restore its value and effectively contribute to the construction of sustainable infrastructure projects in the future (Petroski 2011). Civil engineers must also play an active role in interpreting and complying with important policy documents such as the NEPA to ensure that the intended sustainability outcomes are achieved (Council on Environmental Quality 2014). By doing so, civil engineers can avoid the mistakes of the past and build a better future for our planet. The need for a more comprehensive approach to project delivery and a greater understanding of public policy is essential for the continued growth and success of civil engineering.

==Second Avenue Subway Project==
===Historical Context and the Need for Best Practices===

In this study, we have employed a research methodology centered on the SAS project. We used publicly available data from three main sources. First, we conducted an in-depth analysis of engineering reports and documentation from the SAS project found in the FTA’s oversight monitoring reports, published by its project management oversight contractor (PMOC reports 2013). Second, we examined the MTA’s publicly available quarterly comprehensive reports to stakeholders. Lastly, we reviewed relevant reports and literature on NYC subway construction during 1880–1920. These reports contained Rapid Transit Commission reports and best practices in the transportation infrastructure domain.

The data-analysis component of our methodology included qualitative and quantitative methods. Initially, we reviewed the engineering reports and the PMOC and MTA reports on the SAS project. Furthermore, this examination facilitated the extraction of pertinent data and identification of key themes and patterns concerning project performance, challenges encountered, and lessons learned. We have utilized our professional experience and expertise in the field to offer context and nuance to data analysis. This has allowed for a comprehensive understanding of the project’s complexities and highlighted the significant aspects that may otherwise have been overlooked. Moreover, we have compared the SAS project’s performance, challenges, and outcomes with those documented in the literature on the NYC subway project of 1900. This comparative analysis was aimed to pinpoint any unique aspects of the SAS project and evaluate its overall success in relation to the Rapid Transit Commission’s NYC subway in the early 20th century.

We devised evaluation criteria based on findings from the literature review to estimate the project’s performance. Furthermore, we considered the specific goals and objectives proposed in the SAS draft environmental impact statement (EIS) and final EIS. We employed these criteria to evaluate various dimensions of the SAS project, such as cost, schedule, quality, and stakeholder satisfaction (PMOC reports 2013).

The construction of the NYC subway system in the early 20th century exemplifies the technical and financial expertise required of civil engineers. The system cost approximately 350 million USD to construct in 1920 (New York Times 1920), which is equivalent to 4.48 billion USD in 2018. This is similar to the construction cost of the Panama Canal, which was approximately 375 million USD at the time, and it exceeded the cost of similar systems in all other great cities in the world combined. However, the NYC subway system has since become a vital part of the city’s transit infrastructure and has contributed to its economic growth and development. It serves as a testament to the importance of civil engineering in society (Kirkwood 2012). Although the term “sustainability” was not explicitly used during the planning and design of the NYC subway system, all three pillars of sustainability (i.e., economic viability, environmental protection, and social equity) were integral to its construction (Walker 1917). The importance of effective technical communication can be seen in the annual reports of the Rapid Transit Commission. Notably, the challenges faced by the commission at the time were not that different from those faced in the 21st century, such as the population density of Manhattan, subway routes, funding issues, concerns of the public, and tunnel depth (Hood 2004). Documents from the early 20th century (Gotshall 1903, Walker 1917) describe the cost and economic viability of the NYC subway system considering construction challenges and an 1896 court order while also highlighting the social, environmental, and economic impacts.

For new transit systems, the ASCE assesses how well they align with current engineering best practices and requirements. The ASCE Report Card offers insights into the necessary expenditures to maintain transit systems, but its primary objective is to ensure compliance with contemporary standards (Glaeser and Poterba 2020). This assessment can be influenced by subjective factors such as the performance of the responsible organization. It is crucial to understand that a poor evaluation does not always imply a poorly functioning subway system because the ASCE does not distinguish between management and engineering. In other words, a system could be well-engineered but poorly managed. Most subway systems were built in the 1940s, and since then agencies originally responsible for their construction have transitioned to their operation. Thus, such agencies have lacked involvement in engineering projects to build new subways for nearly six decades.

In the existing legal framework, project management contracts are neither considered professional service contracts nor backed by surety, and the ASCE has not yet formulated best practices for project management similar to those developed for design and temporary construction, which have clear guidelines and codes to which the design team must adhere. In the absence of clear guidelines, project management teams may not be held accountable for any issues, which can potentially jeopardize their reputation and credibility. To address this lack of knowledge, the ASCE can publish best practices for transit project management, design, and construction with a focus on consistent engineering principles and legal clarity. The ASCE should establish best practices for an acceptable level of performance concerning project management services. These can include constructability review documents, project budgets, contingency plans, and schedules on par with the approximately 70 design standards currently maintained by the organization.

===Design and Construction Decisions===
The SAS project has garnered attention due to its design, construction challenges, and decisions that led to massive cost overruns. The absence of best practices for project management contributed to the project’s setbacks.
The SAS project faced numerous design challenges, including building a new subway line in a densely populated urban area and accounting for varying geological conditions along the route. Table 1 presents the depths of stations for the SAS project. The draft environmental impact statement (DEIS) for the SAS did not discuss the three options of shallow, mid-depth, and deep tunnels to determine the most feasible path forward. The number of ventilation shafts and access shafts required is related to the depth of the tunnel. The Rapid Transit Subway Construction report provided guidelines for balancing the cost, soil type, construction method, and location to determine the optimal depth for subway tunnels (Associated Engineers-A Joint Venture 1975, New York Urban Transportation Group 1972).

During the preliminary engineering phase between 2000 and 2004, the project management team created budget and contingency plans before entering the final design phase. Despite these efforts, the budget at the Record of Decision had grown to 3.68 billion USD, which was an increase of 920 million USD over the original projection from the 1999 DEIS. By the time the SAS project secured federal government funds, the budget had reached 3.90 billion USD, and it eventually increased to 4.45 billion USD by the time of completion. The ongoing criticism of the cost overruns and delays has resulted in scrutiny of the project management and decision-making processes. The publication of the Final Environmental Impact Study (FEIS) in 2004 elaborated solely on different means of constructing a transit system on Second Avenue, which is primarily a planning practice. This highlights the need for a more detailed study of engineering alternatives and a stronger emphasis on establishing best practices in project management to prevent cost overruns and delays in future projects.

===Geotechnical Design and Construction Issues===
===Tunnel-Boring Machine===
The project management team faced several geotechnical design and construction issues. One of the challenges was related to the tunnel-boring machine (TBM). The team initially justified the use of a TBM because of its ability to dig underground without causing surface disruptions. However, they did not properly plan for the removal of soil excavated by the TBM, which led to the contractor having to install large muck removal and caused obstructions and disruptions at the street level. Furthermore, the cost of using the TBM was triple the amount needed for the more traditional method of cut and cover, which raised questions about the effectiveness of constructability review documents and project management practices (Urban Engineers 2012).

== Table 1: SAS Station Depth ==

{| class="wikitable"
|+ SAS Station Depth
|-
! Station !! Location !! Type !! Transfer Routes !! Preliminary Entrance Locations !! Approximate Station Depth
|-
| '''SECOND AVENUE LINE'''
| colspan="5" style="background-color:#dddddd;" |
|-
| 96th St || Second Ave/96th to south of 94th St || 2 track || || Second Ave/southwest corner of 96th St and northeast and southwest corners of 94th St || 40–45 ft
|-
| 86th St || Second Ave/87th to south of 82nd St || 2 track || || Second Ave/northeast and southeast corners of 86th St and eastern side of Second Ave between 83rd and 84th Sts || 85 ft
|-
| 72nd St || Second Ave/72nd to 69th St || 3 track || Bway/Second Ave Lines || Second Ave/northeast and southwest corners of 72nd St; and northeast corner of 69th St || 85 ft
|-
| '''63RD STREET LINE'''
| colspan="5" style="background-color:#dddddd;" |
|-
| Lexington Ave || 63rd Street/Lexington to Third Ave || 4 track || F || Existing: Lexington Ave/63rd St; New: Third Ave/63rd St (northwest, southeast, and possible northeast corners) || 105–135 ft
|}

== Notes ==
# Average depth of Manhattan tunnels constructed in 1900 was 30 feet.
# 72nd Street station became two tracks.
# All four tracks at Lexington Avenue (63rd Street station) exist today; only two are used for passenger services.

===Ground Support Challenges===
The 72nd and 85th Street stations faced constructability challenges related to ground support during the detailed design stage. Engineers discovered that the quality and depth of rock above the stations were not adequate to support the tunnel (Fulcher et al. 2013, Urban Engineers 2008). The original design of the 72nd Street station included three tracks, but it was at such a depth that the design team was forced to change the configuration to the current two tracks. This highlights the need for conducting thorough geotechnical studies and developing engineering alternatives rather than relying solely on a shallow FEIS analysis. This can prevent costly redesigns and reconstructions during the excavation process and ensure that the design aligns with the project’s goals.

===Utility Work and Contracting Challenges===
In the preliminary design phase, the project and design team initially planned to use six construction contracts, but they later encountered problems with utility work and the assumption that general contractors would handle all permits, engineering, and logistics. This resulted in the team having to break the contract into separate utility and station contracts as had been recommended by an engineering report on the construction of the original subway system in 1919 (NYC Engineering Report on Subway Construction). During construction, the project management team discovered that the buried foundations of elevated tracks on Second Avenue that had been demolished in the mid-1940s still existed, which presented a significant cleaning task. This was yet another instance where the project deviated from the best engineering practices in terms of a thorough geotechnical investigation prior to detailed design and risk management (Urban Engineers 2010).
===Real Estate Acquisition Challenges===
The design and project management team assumed that the acquisition of real estate for shaftways would be straightforward. However, accessing the ground beneath the surface was not without issue (Real Estate Record and Builders' Guide 1904). The team assumed that only one building would be necessary for real estate negotiations. However, in reality, access was needed through multiple interconnected buildings when the design team started the detailed design. Manhattan block buildings leaned on each other, and there was no gap between them (Eschenasy et al. 2017). Thus, an individual building provided support to the entire block. The design team had to construct a frame that supported the entire block to pull it out in one piece (Urban Engineers 2008).
In cases where the access shaft was going into a building, the SAS project needed an easement by law. However, the project needed to enter multiple buildings because the buildings were interconnected. Manhattan’s structures were designed so that someone living two or three buildings away from the access building had to walk through a hallway in the second or third building before arriving at the original access building. A deeded easement was required for this setup (Urban Engineers 2008).

A comprehensive approach to civil engineering best practices in project management is essential for understanding the intricacies of large-scale transit projects such as the SAS. Relying solely on individual perspectives and interpretations is insufficient for a profession that has built subway systems since the late 19th century. Successful projects necessitate a systemic understanding of project management, which includes thorough geotechnical studies, effective technical communication between stakeholders, and a detailed analysis of real estate acquisition and utility work. In addition, it is crucial to emphasize the importance of translating these efforts into the education of graduate students. They should be taught to understand construction deliverables, project delivery methods, and construction packaging in a practical manner, akin to the hands-on approach expected of law or medical students. This goes beyond mere memorization and equips future professionals with the skills necessary to navigate complex projects effectively. By learning from the experience of the SAS project, future project management teams can address challenges related to tunnel-boring machines, ground support, and utility work while also navigating the complexities of real estate acquisition and easement. Implementing these lessons will help minimize delays and cost overruns, which will ultimately lead to more efficient and cost-effective infrastructure development.

Moreover, it is vital for project management teams to remain adaptable and open to changes in their initial plans. This flexibility will enable them to respond effectively to unexpected challenges that may arise during the design and construction phases. It is equally important to invest time and resources in conducting comprehensive analyses, including geotechnical investigations and engineering alternative analyses, to ensure that projects are built on a solid foundation.

== Table 2: SAS Budget History ==

{| class="wikitable"
|+ SAS Budget History (in Millions)
|-
! Categories !! 1999 DEIS (Phase I & II) !! 1999 DEIS (Adjusted for Phase I) !! FEIS (2004 Record of Decision) !! FFGA (November 2007) !! Actual (2018)
|-
| '''Total Design''' || || || $410.00M || $410.00M ||
|-
| '''Construction Management Services''' || || || $86.00M || $80.94M ||
|-
| '''Construction''' || $4.82B || $2.17B || $2.81B || $2.69B || $2.78B
|-
| Contract 1: Tunneling || || || $375.88M || ||
|-
| Contract 2–6 & Others || || || $2,430.12M || ||
|-
| '''Rolling Stock *''' || $610.10M || $610.10M || $157.00M || $153.00M || ~~$0.00M~~
|-
| '''Real Estate''' || $131.40M || $59.13M || $191.00M || $240.96M || $281.50M
|-
| '''OCIP''' || || || $180.00M || $160.00M ||
|-
| '''Project Reserve''' || || || $8.00M || $173.10M ||
|-
| '''NYCT Labor, Utility Reimbursement, etc.''' || || || || || $145.30M
|-
| '''Subtotal Without Financing''' || $5.56B || $2.76B || $3.68B || $3.90B || $4.45B
|-
| '''Financing Cost''' || || || || || $796.31M
|-
| '''Total''' || || || || || $4.85B
|}

== Notes ==
# All estimates are for the **Year of Expenditure (2018)**.
# SAS Project Phase I **never paid for rolling stock**; therefore, the estimate is crossed out.

==Metropolitan Transportation Authority==
Public authorities acquired many of their transit systems from private companies that were in financial trouble after World War II. Because of the decline in profits and ridership, transit companies spent less money on maintenance and renovation, which resulted in their systems largely falling into disrepair by the time they were acquired by public authorities. The new transit authorities have had limited success in addressing the problem of station neglect, with a lack of funds being a major challenge. The NYC Transit Authority was established in 1953 (Homburger and Kennedy 1961), and the Metropolitan Transportation Authority (MTA) was created later in 1968 (New York Urban Transportation Group 1972). Since then, the MTA has consistently struggled with budget deficits and has been unable to establish a pricing equilibrium. It is not considered financially sustainable because of its reliance on government subsidies to balance its budget. It also lacks transparency in its financial system, and it is not held to the same standards of competency as private institutions. However, as a public institution, its value in terms of economic growth and employment through infrastructure investment must be recognized (Glaeser and Poterba 2020).

To operate sustainably and be responsive to taxpayers, the MTA needs to establish an equilibrium in funding to cover operating, maintenance, and capital improvement costs while recognizing that it may not conform to a normal pricing equilibrium (Mankiw 2018). It is crucial for project stakeholders to have confidence in the MTA’s management, whether practices are internal or external (Mayor's Committee on Management Survey 1953). The MTA has two primary roles in managing its transit projects: planning and economics, and engineering. To be competent in these practices, the MTA staff must possess the necessary knowledge and skills. Several reasons justify subsidizing public mass transit systems with taxes. First, taxation is the only practical way to collect from people who indirectly benefit from the transit system. Without taxes, the community would receive a benefit without contributing in return. Second, fares paid by riders do not fully cover the operating costs, depreciation, and capital asset investments. Therefore, it is necessary to collect part of the cost from both riders and the community through taxes (Litman 2021). Opponents may argue that fares should be high enough to cover the total costs of the transit system to eliminate the need for government subsidies (Coase 1960). This approach would discourage some people from using the system’s services and result in fewer riders. Subsidies help the MTA maintain affordable fares and allow the NYC transit system to operate at its intended capacity, as it has for over 100 years (Habib et al. 1978).

Notably, NYC’s transit system has always been subsidized, dating back to the first streets and docks built at public expense in 1684 and city-operated ferries crossing the East River. Even private investors were not allowed to increase fares to the level of pricing equilibrium. Transit facilities are generally more economical when heavily used, as reduced traffic leads to wasted capacity (Parry and Small 2009).

To achieve a funding equilibrium, the MTA must make an effort to itemize its costs and develop a plan to control them effectively. The complexity of its budget can be understood by examining three main categories: operating costs, maintenance costs, and capital investments in expanding the system (Engineering-Contracting 1910). Therefore, the MTA is responsible for managing taxpayer money in a way that balances its budget while also investing in capital growth to deliver sustainable transit projects. However, the MTA has struggled with effectively managing construction projects due to a lack of advancement in civil engineering practices and knowledge.

Theoretically, the MTA maintains a high level of accountability, but this is not consistently evident in its organizational practices (Hood 1992). As a result, while a design team may generate technical documents, the project management team of a consulting firm will not review them because it falls outside the scope of an engineering contract. In essence, the project management team satisfies the MTA’s staffing needs without requiring members to hold necessary engineering qualifications, understand engineering practices, or carry engineering liability insurance. Despite this, the MTA is the highest authority in the decision-making process and integrates the three variables of scope, cost, and schedule for capital projects. Most of the members of a project management team will not possess the necessary credentials to review engineering practices or deliverables because being a licensed engineer is not a key requirement. Rather, a certification in management is needed. This is a significant departure from reports from the early 20th century (Building the New Rapid Transit System of NYC 1915), which emphasized that the design and construction of the NYC subway system was primarily an engineering task with military-like organizational principles.

It is vital for the MTA to address this gap and prioritize engineering knowledge and practices in its project management. Currently, the project management team may move in one direction, the design team produce construction documents in another direction, and the construction team move in yet another direction independent of the other two. This lack of coordination can be seen in the SAS project, where the geotechnical design team produced design memos for the tunnels and stations that were signed off by the project management team and construction team. However, the construction documents did not consider the shallow depth of rock on top of the tunnels or the width of the tunnels in their original three-track design, which caused problems in the construction of the stations. The schedule and budget approved by the project management team confirmed that it reviewed the design, but no changes were made, which is likely because the FTA would not pay for a project redesign.

To overcome these challenges and improve overall performance, the MTA must make significant changes in its organizational structure and management practices. One critical step is to require project management staff to possess engineering credentials and knowledge. By doing so, the MTA can better align its various teams and ensure that they are working collaboratively toward a common goal. Furthermore, the MTA should invest in the professional development of its staff by providing ongoing training and resources related to civil engineering practices. This will help it keep up with advancements in the field and ensure that its projects are executed using the most up-to-date techniques and methods.

Another essential component of improving management practices is to increase transparency and accountability within the MTA. By implementing performance metrics and regularly tracking progress, it can ensure that it is effectively managing taxpayer money and delivering results in line with its objectives. Increased transparency can help build public trust and demonstrate that the MTA is committed to providing quality service while responsibly managing its resources. Finally, the MTA should focus on forging stronger partnerships with external stakeholders such as local governments, businesses, and community organizations.
Conclusion

The early 20th century witnessed the evolution of civil engineering into an established profession with a comprehensive knowledge base. Civil engineers contributed to the construction of massive projects such as the NYC subway system, which required technical and economic expertise. However, civil engineering faces vulnerabilities because of the absence of a well-rounded education system that can prepare engineering students for the complexities of future projects and the disconnect between academia and engineering practices. As civil engineering knowledge continues to develop, the profession must address these vulnerabilities and adapt to the changing demands of the industry.

The SAS project faced multiple design challenges and construction decisions that resulted in considerable cost overruns. The assumptions made by the project management and design teams regarding geotechnical issues, construction contract packaging, real estate acquisition, and easement were unable to handle the complexity of the SAS project. This resulted in unexpected costs and delays, as evidenced by the significant budget increases. To avoid similar issues, it is crucial to examine the logic and lessons learned from the project and apply these insights to future endeavors. The lack of well-defined best practices for project management played a role in these issues. To avoid similar problems in future transit projects, the ASCE should establish comprehensive best practices for project management, design, and construction encompassing consistent engineering principles, legal clarity, and acceptable performance levels for interpretation under the NEPA. By adopting these best practices, transit agencies and engineering firms can collaborate more effectively to complete crucial infrastructure projects on schedule and within budget. The SAS project serves as a case study for the importance of thorough planning, effective communication, and adaptability in the face of complex challenges. The lessons learned from this project can be applied to the better planning, design, and execution of future infrastructure projects, which will ultimately benefit both the industry and the public.

The MTA is a vital public institution responsible for providing essential transit services to NYC citizens. However, it faces significant challenges related to financial sustainability and management practices. By prioritizing engineering knowledge and practices, increasing transparency and accountability, and fostering stronger partnerships with external stakeholders, the MTA can transform itself into a more efficient, cost-effective, and responsive organization. These changes will ultimately lead to better transit services for the public and a more sustainable future. As the MTA evolves and adapts to these new management practices, it can serve as a model for other public institutions looking to improve their own operations and better serve their constituents.

==Data Availability Statement==

All data used in this study is publicly accessible and can be obtained through the provided references. For the PMOC reports, readers can access the FTA’s website at https://www.transit.dot.gov/foia/metropolitan-transportation-authority-second-avenue-subway. The 2013 “The Politics of Large Infrastructure Investment Decision-Making: The Case of the Second Avenue Subway Case Study” report can be found at https://rosap.ntl.bts.gov/view/dot/27119.

== References ==

* Abbott, A. (2014). ''The system of professions: An essay on the division of expert labor''. University of Chicago Press, Chicago, USA.
* Barzelay, M. (2001). ''The new public management: Improving research and policy dialogue''. University of California Press, Berkeley, CA.
* Civil War Railroad Report. (1865). ''Report on the construction of railroads during the Civil War''. War Department Records, USA.
* Coase, R. H. (1960). "The problem of social cost." ''J. Law Econ.'', 3, 1–44.
* Concord Canal Report. (1825). ''Report on the Concord Canal''. Massachusetts State Records, USA. 7, 6.
* Council on Environmental Quality. (2014). ''A citizen’s guide to the NEPA: Having your voice heard''. Council on Environmental Quality 2007, Washington, DC. [https://ceq.doe.gov/docs/get-involved/Citizens_Guide_Dec07.pdf Link].
* Department of Energy. (1970). "National Environmental Policy Act of 1970." ''Public Law'', 91, 11.
* Durand, W. F. (1929). ''Robert Henry Thurston: A biography, the record of a life of achievement as engineer, educator, and author''. The American Society of Mechanical Engineers, New York.
* Dzur, A. W. (2008). ''Democratic professionalism: Citizen participation and the reconstruction of professional ethics, identity, and practice''. Pennsylvania State University Press, University Park, PA.
* Engineering-Contracting. [https://www.google.com/books/edition/_/HAHQQxqfkRMC?hl=en&sa=X&ved=2ahUKEwjgveWIwv_-AhXaEVkFHTOmCfkQre8FegQIARAV&bshm=bshwcqp/1 Link].
* Eschenasy, P.E., F.SEI Bharat Gami, R.A., Gus Sirakis, P.E. (2017). "Special topics in construction safety course number SW0317." Presentation at the Build Safe/Live Safe Conference, NYC Department of Buildings, New York.
* Filion, P., & Hammond, K. (2003). "Neighbourhood land use and performance: The evolution of neighbourhood morphology over the 20th century." ''Environ. Plann. B Plann. Des.'', 30(2), 271–296.
* Fitch, R. (1999). ''The assassination of New York''. Verso, London, UK.
* Fulcher, B., Menge, S., & Grillo, J. (2013). "New York City—Second Avenue Subway: MTA’s 72nd Street Station and tunnels project construction of a large span station cavern, running tunnels, cross-over and turn-out caverns, shafts and entrances." ''Proc., Rapid Excavation Tunneling Conf 2013 Proceedings''. Society for Mining, Metallurgy, and Exploration.
* Glaeser, E. L., & Poterba, J. M. (2020). "Introduction to economic analysis and infrastructure investment." ''Economic Analysis and Infrastructure Investment''. University of Chicago Press, Chicago. [https://www.nber.org/books-and-chapters/economic-analysis-and-infrastructure-investment/introduction-economic-analysis-and-infrastructure-investment Link].
* Glaeser, E. L., & Poterba, J. M. (2021). ''Economic analysis and infrastructure investment'' (Vol. 28215). National Bureau of Economic Research, Inc., NY.
* Gordon, T., & Schleicher, D. (2015). "High costs may explain crumbling support for US infrastructure." ''Real Clear Policy''.
* Gotshall, W.C. (1903). ''Notes on electric railway, economics and preliminary engineering''. McGraw Publication Company, New York.
* Habib, P., Linzer, E., Jones, C., Nason, R., & Ablamsky, R.A. (1978). ''Fare policy and structure''. Polytechnic Institute of New York, Urban Transportation Research Center, New York.
* Hall, P. (2002). ''Urban and regional planning''. Routledge, London, UK.
* Harris, F., & McCaffer, R. (2013). ''Modern construction management''. Wiley-Blackwell, Chichester, UK.
* Homburger, W. S., & Kennedy, N. (1961). ''The organization of metropolitan transit agencies''. University of California, USA.
* Hood, C. (1992). ''The landscapes of modernity: Essays on New York City''. Russell Sage Foundation, Baltimore. [http://academic.brooklyn.cuny.edu/history/burrows/NYC/Documents/hood.htm Link].
* Hood, C. (2004). ''Miles: The building of the subways and how they transformed New York''. Johns Hopkins University Press, Baltimore, MD.
* Kates, W. R., Parris, T. M., & Leiserowitz, A. A. (2005). "What is sustainable development? Goals, indicators, values, and practice." ''Environ. Sci. Policy Sustain. Dev.'', 47(3), 8–21. [https://doi.org/10.1080/00139157.2005.10524444 Link].
* Kaufman, H. (1956). "Emerging conflicts in the doctrines of public administration." ''Am. Polit. Sci. Rev.'', 50(4), 1057–1073. [https://doi.org/10.2307/1951335 Link].
* Kerzner, H. (2009). ''Project management: A systems approach to planning, scheduling, and controlling''. John Wiley & Sons, Hoboken, NJ.
* Kirkwood, N. (2012). ''The end of the line: A history of railways in Great Britain''. The History Press, Stroud, UK.
* Koppenjan, J. F. M., & Enserink, B. (2009). "Public–private partnerships in urban infrastructures: Reconciling private sector participation and sustainability." ''Public Admin. Rev.'', 69(2), 284.
* Labuschagne, C., & Brent, A. C. (2004). ''Sustainable project life cycle management: Aligning project management methodologies with the principles of sustainable development''. PMSA, Johannesburg, South Africa. [http://hdl.handle.net/2263/4856 Link].
* Levinson, D. M. (2003). ''Financing transportation networks''. Edward Elgar Publishing, Cheltenham, UK.
* Lewis, P. (2004). ''Urban planning and the American family''. Temple University Press, Philadelphia, PA.
* Mankiw, N. G. (2018). ''Principles of economics''. 8th ed., Cengage Learning, Boston, MA.
* PMOC reports. (2013). [https://www.transit.dot.gov/foia/metropolitan-transportation-authority-second-avenue-subway Link].
* Real Estate Record and Builders’ Guide. (1904). ''Real estate record and builders guide''. LXXIV, 718. [https://www.google.com/books/edition/_/ZqdRAAAAYAAJ?hl=en&gbpv=0&bshm=bshwcqp/1 Link].
* Rosenthal, B. M., & Fitzsimmons, E. G. (2017). "Why does subway construction cost so much? Congress wants to find out." ''The New York Times''. [https://www.nytimes.com/2018/03/28/nyregion/new-york-subway-construction-costs-congress.html Link].
* Subway. (1920). "Cost $350,000,000." ''The New York Times''. [https://timesmachine.nytimes.com/timesmachine/1920/12/05/102965570.html?pageNumber=117 Link].
* The Politics of Large Infrastructure Investment Decision-Making: The Case of the Second Avenue Subway Case Study. Report No. 49111-16-23. [https://rosap.ntl.bts.gov/view/dot/27119 Link].

Bridging the Gaps: Better Infrastructure Project Management and Civil Engineering

2025-02-11T23:21:34Z

Pooyan: /* Real Estate Acquisition Challenges */

'''Bridging the Gaps: Better Infrastructure Project Management and Civil Engineering

Practices Based on Lessons from the Second Avenue Subway Project'''

== Abstract==
The importance of thorough geotechnical investigations, effective communication, and adaptability to ensure the completion of complex transit projects on time and under budget cannot be emphasized enough. The Second Avenue Subway (SAS) project in New York City has come under intense scrutiny owing to numerous delays and massive cost overruns. This paper highlights the need for a transformation in civil engineering graduate programs to better equip students and practitioners for the complexities of transit project deliveries. Due to an overemphasis on theoretical computational practices, civil engineers have neglected the development and interpretation of policy knowledge, leading to critical decisions being made by those with limited sustainability understanding. This trend, combined with the ineffective communication of technical aspects, has contributed to escalating costs and misaligned sustainability outcomes in transit projects. Herein, a holistic learning approach that encompasses project management, public policy, and real-world case studies is presented to bridge the current knowledge gap and prepare future professionals for successfully delivering sustainable, on-time, within-budget transit projects.

Herein, the management, engineering, and administrative practices employed in the SAS project are comprehensively analyzed. Key assumptions made by the project management and design teams are highlighted that led to unexpected costs and delays. The role of the Metropolitan Transportation Authority (MTA) as an administrative agency is examined and gaps in engineering knowledge and practices within the MTA are identified.

The analysis results demonstrate the need to address the financial sustainability of transit projects and obtain a funding equilibrium. In addition, the MTA needs to prioritize hiring and promoting individuals with engineering credentials, increase transparency and accountability, and foster stronger partnerships with external stakeholders.
The lessons learned from the SAS project can be used to inform future infrastructure projects and guide the transformation of the MTA into a more efficient, cost-effective, and responsive organization.

==Practical Applications==

This paper addresses the challenges faced by civil engineering professionals in delivering transit projects on time and within budget. Modern civil engineers must have a diverse set of skills, encompassing engineering, planning, economics, environmental science, management, finance, and law. Additionally, they must understand public policy and sociology while being updated on the challenges of translating public policies into engineering outcomes.
The paper emphasizes the need for meaningful change in civil engineering graduate school programs to include project management, public policy, and professional practices using real-world cases and public projects. This will equip students and practitioners with necessary tools to plan and manage transit projects effectively.
Because of the increased complexity of US public administration since WWII, learning transit fundamentals and problem-solving techniques within the context of delivering sustainable projects by graduate students is urgently required. Additionally, this paper underscores the importance of modifying civil engineering education to better prepare professionals for the challenges and opportunities in the realm of transit project delivery.

==Introduction==

Unlike other engineering disciplines, civil engineering is inextricably intertwined with public projects, which differ dramatically from other engineering products because they do not follow a single pattern or protocol (Harris and McCaffer 2013). Public projects develop in response to particular societal and governmental needs, and thus the broader economic, environmental, and political contexts in which they are embedded must be considered. The successful completion of these projects requires civil engineers who are not just technically competent but also able to understand public policy as well as political, environmental, and sociological concerns (Labuschagne and Brent 2004). Relatedly, civil engineers do not develop or work on products that can be sold to generate revenue but on projects that must secure governmental funding and approval as well as satisfy not only individual users but also public stakeholders (Koppenjan and Enserink 2009).

Kaufman (1956) outlined three distinct phases in the evolution of administrative leadership in the United States to address the core value of representativeness in a democracy. The first phase focused on representativeness in the nascent government with “No taxation without representation” as the principal interest of independence. The second phase was the quest for “neutral competence” that began after the Civil War and continues to this day. The aim was for the government to work based on explicit and objective standards rather than personal, party, or other obligations and loyalties. The slogan “Take administration out of politics” gave rise to the Civil Service Act of 1883, which aimed to control the selection of government workers by establishing a merit-based hiring system and offering formal training to civil servants at universities (Kaufman 1956). Although states and localities were slow to adopt these practices, they have made significant strides in recent years. The third phase focuses on the need for “executive leadership” to bridge the gap between the unresponsiveness of neutral competence and the public’s demand for clear communication. Civil engineers can play a crucial role in this process by negotiating effectively with bureaucratic entities and forming alliances with legislative committees and groups, which will allow them to gain greater autonomy in decision-making if they can establish clear expectations for knowledge and outcomes.

However, civil engineering has not yet established best practices in three areas: public policy, project management, and professional practice. This has posed challenges for individual engineers within powerful organizations to influence policy decisions for the public’s benefit.

In the United States, transit projects have long been a source of frustration for the public because of their high costs and delays. Media headlines have highlighted these issues and have painted a picture of inefficiency and exorbitance in the public sector (Gordon and Schleicher 2015, Rosenthal and Fitzsimmons 2017). Scholars and policy analysts have proposed various explanations for these problems, including the cost of land, regulations, and community opposition (Glaeser and Poterba 2020). However, the evolution of civil engineering, particularly the narrowing of the knowledge base and skill set associated with the profession, may be a significant but overlooked factor. Of course, this narrowing is not a development exclusive to civil engineering alone. Abbott (1986) noted that professions often become more specialized over time, which leads to a reduction in the knowledge and skill set of individuals. However, while such specialization may make sense in other professions, the narrowing of civil engineering has contributed to a failure to fully integrate the technical requirements of transit projects with political, social, environmental, and economic needs. This has resulted in a disconnect between the technical aspects of transit projects, which civil engineers are trained to address, and the non-technical aspects, which they are not. This has led to increased costs and public frustration. Civil engineers can play a significant role in overcoming this disconnect and contributing to the development and execution of successful and sustainable transit projects, but only if their own education and training shifts to (re)emphasizing sustainability. A clearer understanding of how the capacity and role played by civil engineers has changed over time is needed to help address these problems.

The Second Avenue Subway (SAS) project in New York City (NYC) has garnered attention because of design issues, construction challenges, and decisions that led to massive cost overruns. This project faced numerous design challenges including building a new subway line in a densely populated urban area and accounting for varying geological conditions along the route. Ongoing criticism of the SAS project’s cost and delays in completion have resulted in scrutiny of the project management and decision-making processes. In this paper, the SAS project is used as a case study to highlight the need for a more detailed study on engineering alternatives and the establishment of best practices in project management to prevent cost overruns and delays in future projects.

== Civil Engineering Knowledge==
===From 1800 to 1950===
In the early days of civil engineering in the United States, ad hoc public commissions or chartered companies managed public construction projects (Kaufman 1956). With the evolution of the field, civil engineering became known as “land development” (Williams 1922). The primary concern of such commissions was feasibility, which led to the first wave of public projects consisting of canal construction (Poor 1860). The Concord Canal Report (1825) emphasized assessing a project’s economic and technical value before execution, which necessitated consulting experts in mechanics, hydraulics, geology, and soils to estimate the costs, benefits, and results. When debating whether Massachusetts should promote canals or railroads, Governor Levi Lincoln consulted experts in various fields to resolve questions related to labor, expenses, and project benefits and results (Poor 1860).

The Civil War represented a turning point for civil engineering as railroads were constructed to facilitate transportation of Union armies, which laid the groundwork for modern civil engineering. In the post-Civil War era, civil engineers collaborated with investors to finance and build railroads, which significantly contributed to the country’s economic growth (Civil War Railroad Report 1865). Railway engineers needed knowledge in finance and business management because private financiers were the primary investors in railroads while the government granted rights of way. Gotshall (1903) highlighted the importance of these skills by demonstrating the practicability of high-speed electric railways from both engineering and commercial perspectives. In the late 19th century, Thurston argued for a dedicated method of publication to provide engineers with detailed and specific knowledge in their field. He called for an institution devoted to providing individuals with technical training and practical laboratory experience (Durand 1929), which aligned with the trend for various fields at the time of specialization in knowledge and skills. The emergence of professional societies such as the American Society of Civil Engineers (ASCE) facilitated this trend by providing a platform for knowledge exchange and expertise. Thurston’s vision and the emergence of professional societies laid the foundation for the growth and development of civil engineering as a full-fledged profession in the United States. However, this also led to the emergence of new administrative challenges and changes that significantly affected its ability to expand its intellectual dominance among engineering disciplines (Durand 1929).

At the beginning of the 20th century, civil engineering encompassed a combination of factual, conceptual, and procedural knowledge. Unlike law and medicine, engineering schools were founded by college-trained professors who designed the curricula. Although the apprenticeship method was used to train engineers, it never developed into significant engineering schools. Teaching theory before practice led to many first- and second-year students feeling disoriented and disheartened because they continued to engage in the same routine of reading books and studying abstract symbols as they did in high school (Durand 1929). This disconnection between academia and engineering practice became evident during the construction of massive projects that required unprecedented coordination, planning, and management. Parsons (1902), who was the Chief Engineer of the NYC Rapid Transit Commission at the time, warned that the engineer of the future would need to deal not only with calculations but also with human needs, industrial demand, finance, and legislation. Engineers would need to combine technical and economic expertise to conceive, plan, design, execute, and manage projects.

===From 1950 to the Present===
The post-World War II era brought several challenges to civil engineering, including the bankruptcy of the railroad industry, massive administrative changes, and the widening gap between academia and professional practice. The United States underwent a major administrative shift by transitioning from ad hoc decision-making when funding transit projects to a more structured and centralized system emphasizing executive leadership, efficiency, and data-driven decisions (Barzelay 2001). This approach influenced agencies such as the Federal Transit Administration (FTA), where urban planners began to outnumber civil engineers (Lewis 2004). Despite improvements in transit planning, a disconnect persisted between professionals and politicians, which raised concerns about the effectiveness of decision-making and implementation (Levinson 2003). Urban planning evolved as a profession in response to the challenges of urbanization in the late 19th century (Hall 2002). Initially, city planning focused on the City Beautiful concept. However, as cities expanded, land economics became increasingly important (Filion and Hammond 2003). Lawyers, civil engineers, and urban planners all began playing key roles in shaping American infrastructure (Peterson 2003).

The ASCE did not heed Parsons’ warning from the early 20th century, and they neglected to advance their knowledge in project management, public policy, and professional practice (Fitch 1999). When the transit industry went bankrupt, the National Environmental Policy Act (NEPA, Department of Energy 1970) was published, and the FTA issued several policy documents on funding strategies for transit projects. Civil engineers struggled to add engineering interpretations of these policy documents with regard to recommending best practices and ensuring that new engineers are educated accordingly in universities (Barzelay 2001). In addition, a governmental shift toward a business-oriented approach led to a decline in practical professors and licensed engineers, which caused a loss of influence by civil engineers (Dzur 2008). Meanwhile, organizations such as the Project Management Institute have enabled managers without an engineering background to assume high decision-making positions within governments and engineering firms offering construction management services (Kerzner 2009). Abbott (1986) argued that business-oriented practices are more applicable to professions that lack technical roots and thus prioritize business strategies. However, professions such as civil engineering and medicine derive their legitimacy not just from efficiency and quality management but also from the technical skill and experience inherent to their fields.

Following the Civil Service Act and the rise of neutral competence, civil engineers should have developed a series of management practices tailored to enhance the overall functioning of transit organizations, which would have helped them to effectively manage and maintain the developed infrastructure as well as provide informed engineering interpretations of policy documents such as the NEPA (Perry and Rainey 1988). Unfortunately, civil engineers did not work on developing and interpreting policy knowledge, but rather they became focused on a narrow scope of computational practices in design, which was driven by an excessive theoretical focus in academia (Petroski 2011). This knowledge gap, combined with the lack of participation by civil engineers in interpreting the NEPA, led to major planning decisions being made by planners and economists with a limited understanding of sustainability (Council on Environmental Quality 2014). Consequently, NEPA is now perceived as a permitting tool rather than an engineering document, which has caused public participation to be associated with Not in My Backyard (NIMBY) attitudes and resulted in misaligned sustainability outcomes for transit projects (Kates et al. 2005; Real Estate Record and Builders’ Guide 1868–1884). Urban planners and civil engineers both play critical roles in evaluating transit project options. While urban planners focus on the socioeconomic impacts, civil engineers concentrate on the technical and operational aspects. However, the failure of civil engineers to effectively communicate technical issues to stakeholders has led to the NEPA being regarded as a bureaucratic process, which has caused transit project costs to soar (Petroski 2011).

The inability of civil engineering to adapt to the evolving landscape of public administration and the growing influence of policy documents on engineering practice may have weakened its standing. Furthermore, practitioners are unable to effectively shape their academic foundations, unlike their counterparts in medicine and law (Petroski 2011). This has led to disjointed and ad hoc academic solutions, particularly in graduate programs, which fail to provide civil engineering students with the necessary knowledge and skills to understand a project’s life cycle in the context of project management as well as policy knowledge for funding and executing transit projects on time and within budget (Perry and Rainey 1988).

In an attempt to address these shortcomings, construction management has been introduced as a hybrid program between business and engineering schools (Petroski 2011). Unfortunately, these programs often lack an engineering-focused approach to expanding undergraduate curricula to develop students’ understanding of public policies, project management, and professional practice. Instead, they primarily emphasize the memorization of terminology and the use of ad hoc computational software (Katz 2012). In professional practice, civil engineers have struggled to adapt to changing demands, including new technologies and increased regulations. The profession must reassess its approach and incorporate the necessary skills and knowledge to effectively contribute to the construction of sustainable infrastructure projects (Petroski 2011). The lack of engineering interpretation of public regulations such as the NEPA and the FTA’s Capital Investment Grants Program requirements has significantly affected the planning and execution of infrastructure projects (Council on Environmental Quality 2014). The ASCE has acknowledged the issue of practical experience within the profession, but it has struggled to intervene in graduate education (ASCE 2008). Moreover, the lack of input by civil engineers in interpreting the NEPA has led to major planning decisions being made by planners and economists with a limited understanding of sustainability (Council on Environmental Quality 2014).

To tackle the challenges faced by civil engineers, a holistic approach to project delivery is needed that combines technical expertise, policy understanding, and quality management practices. Although the Accreditation Board for Engineering and Technology (ABET) ensures the quality of undergraduate education, graduate programs often lack these three essential components. ABET was established in 1932 as the Engineers’ Council for Professional Development and was initially focused on the technical content taught in courses. In 1997, ABET shifted its emphasis to learning outcomes with the introduction of Engineering Criteria 2000 (EC2000) (ABET 2021). This transition led to a more flexible approach, which is a key quality needed for professionals to succeed in fields of vital importance to society (Kates et al. 2005). By investing in academic knowledge and prioritizing technical expertise over business-oriented practices, civil engineering can restore its value and effectively contribute to the construction of sustainable infrastructure projects in the future (Petroski 2011). Civil engineers must also play an active role in interpreting and complying with important policy documents such as the NEPA to ensure that the intended sustainability outcomes are achieved (Council on Environmental Quality 2014). By doing so, civil engineers can avoid the mistakes of the past and build a better future for our planet. The need for a more comprehensive approach to project delivery and a greater understanding of public policy is essential for the continued growth and success of civil engineering.

==Second Avenue Subway Project==
===Historical Context and the Need for Best Practices===

In this study, we have employed a research methodology centered on the SAS project. We used publicly available data from three main sources. First, we conducted an in-depth analysis of engineering reports and documentation from the SAS project found in the FTA’s oversight monitoring reports, published by its project management oversight contractor (PMOC reports 2013). Second, we examined the MTA’s publicly available quarterly comprehensive reports to stakeholders. Lastly, we reviewed relevant reports and literature on NYC subway construction during 1880–1920. These reports contained Rapid Transit Commission reports and best practices in the transportation infrastructure domain.

The data-analysis component of our methodology included qualitative and quantitative methods. Initially, we reviewed the engineering reports and the PMOC and MTA reports on the SAS project. Furthermore, this examination facilitated the extraction of pertinent data and identification of key themes and patterns concerning project performance, challenges encountered, and lessons learned. We have utilized our professional experience and expertise in the field to offer context and nuance to data analysis. This has allowed for a comprehensive understanding of the project’s complexities and highlighted the significant aspects that may otherwise have been overlooked. Moreover, we have compared the SAS project’s performance, challenges, and outcomes with those documented in the literature on the NYC subway project of 1900. This comparative analysis was aimed to pinpoint any unique aspects of the SAS project and evaluate its overall success in relation to the Rapid Transit Commission’s NYC subway in the early 20th century.

We devised evaluation criteria based on findings from the literature review to estimate the project’s performance. Furthermore, we considered the specific goals and objectives proposed in the SAS draft environmental impact statement (EIS) and final EIS. We employed these criteria to evaluate various dimensions of the SAS project, such as cost, schedule, quality, and stakeholder satisfaction (PMOC reports 2013).

The construction of the NYC subway system in the early 20th century exemplifies the technical and financial expertise required of civil engineers. The system cost approximately 350 million USD to construct in 1920 (New York Times 1920), which is equivalent to 4.48 billion USD in 2018. This is similar to the construction cost of the Panama Canal, which was approximately 375 million USD at the time, and it exceeded the cost of similar systems in all other great cities in the world combined. However, the NYC subway system has since become a vital part of the city’s transit infrastructure and has contributed to its economic growth and development. It serves as a testament to the importance of civil engineering in society (Kirkwood 2012). Although the term “sustainability” was not explicitly used during the planning and design of the NYC subway system, all three pillars of sustainability (i.e., economic viability, environmental protection, and social equity) were integral to its construction (Walker 1917). The importance of effective technical communication can be seen in the annual reports of the Rapid Transit Commission. Notably, the challenges faced by the commission at the time were not that different from those faced in the 21st century, such as the population density of Manhattan, subway routes, funding issues, concerns of the public, and tunnel depth (Hood 2004). Documents from the early 20th century (Gotshall 1903, Walker 1917) describe the cost and economic viability of the NYC subway system considering construction challenges and an 1896 court order while also highlighting the social, environmental, and economic impacts.

For new transit systems, the ASCE assesses how well they align with current engineering best practices and requirements. The ASCE Report Card offers insights into the necessary expenditures to maintain transit systems, but its primary objective is to ensure compliance with contemporary standards (Glaeser and Poterba 2020). This assessment can be influenced by subjective factors such as the performance of the responsible organization. It is crucial to understand that a poor evaluation does not always imply a poorly functioning subway system because the ASCE does not distinguish between management and engineering. In other words, a system could be well-engineered but poorly managed. Most subway systems were built in the 1940s, and since then agencies originally responsible for their construction have transitioned to their operation. Thus, such agencies have lacked involvement in engineering projects to build new subways for nearly six decades.

In the existing legal framework, project management contracts are neither considered professional service contracts nor backed by surety, and the ASCE has not yet formulated best practices for project management similar to those developed for design and temporary construction, which have clear guidelines and codes to which the design team must adhere. In the absence of clear guidelines, project management teams may not be held accountable for any issues, which can potentially jeopardize their reputation and credibility. To address this lack of knowledge, the ASCE can publish best practices for transit project management, design, and construction with a focus on consistent engineering principles and legal clarity. The ASCE should establish best practices for an acceptable level of performance concerning project management services. These can include constructability review documents, project budgets, contingency plans, and schedules on par with the approximately 70 design standards currently maintained by the organization.

===Design and Construction Decisions===
The SAS project has garnered attention due to its design, construction challenges, and decisions that led to massive cost overruns. The absence of best practices for project management contributed to the project’s setbacks.
The SAS project faced numerous design challenges, including building a new subway line in a densely populated urban area and accounting for varying geological conditions along the route. Table 1 presents the depths of stations for the SAS project. The draft environmental impact statement (DEIS) for the SAS did not discuss the three options of shallow, mid-depth, and deep tunnels to determine the most feasible path forward. The number of ventilation shafts and access shafts required is related to the depth of the tunnel. The Rapid Transit Subway Construction report provided guidelines for balancing the cost, soil type, construction method, and location to determine the optimal depth for subway tunnels (Associated Engineers-A Joint Venture 1975, New York Urban Transportation Group 1972).

During the preliminary engineering phase between 2000 and 2004, the project management team created budget and contingency plans before entering the final design phase. Despite these efforts, the budget at the Record of Decision had grown to 3.68 billion USD, which was an increase of 920 million USD over the original projection from the 1999 DEIS. By the time the SAS project secured federal government funds, the budget had reached 3.90 billion USD, and it eventually increased to 4.45 billion USD by the time of completion. The ongoing criticism of the cost overruns and delays has resulted in scrutiny of the project management and decision-making processes. The publication of the Final Environmental Impact Study (FEIS) in 2004 elaborated solely on different means of constructing a transit system on Second Avenue, which is primarily a planning practice. This highlights the need for a more detailed study of engineering alternatives and a stronger emphasis on establishing best practices in project management to prevent cost overruns and delays in future projects.

===Geotechnical Design and Construction Issues===
===Tunnel-Boring Machine===
The project management team faced several geotechnical design and construction issues. One of the challenges was related to the tunnel-boring machine (TBM). The team initially justified the use of a TBM because of its ability to dig underground without causing surface disruptions. However, they did not properly plan for the removal of soil excavated by the TBM, which led to the contractor having to install large muck removal and caused obstructions and disruptions at the street level. Furthermore, the cost of using the TBM was triple the amount needed for the more traditional method of cut and cover, which raised questions about the effectiveness of constructability review documents and project management practices (Urban Engineers 2012).

== Table 1: SAS Station Depth ==

{| class="wikitable"
|+ SAS Station Depth
|-
! Station !! Location !! Type !! Transfer Routes !! Preliminary Entrance Locations !! Approximate Station Depth
|-
| '''SECOND AVENUE LINE'''
| colspan="5" style="background-color:#dddddd;" |
|-
| 96th St || Second Ave/96th to south of 94th St || 2 track || || Second Ave/southwest corner of 96th St and northeast and southwest corners of 94th St || 40–45 ft
|-
| 86th St || Second Ave/87th to south of 82nd St || 2 track || || Second Ave/northeast and southeast corners of 86th St and eastern side of Second Ave between 83rd and 84th Sts || 85 ft
|-
| 72nd St || Second Ave/72nd to 69th St || 3 track || Bway/Second Ave Lines || Second Ave/northeast and southwest corners of 72nd St; and northeast corner of 69th St || 85 ft
|-
| '''63RD STREET LINE'''
| colspan="5" style="background-color:#dddddd;" |
|-
| Lexington Ave || 63rd Street/Lexington to Third Ave || 4 track || F || Existing: Lexington Ave/63rd St; New: Third Ave/63rd St (northwest, southeast, and possible northeast corners) || 105–135 ft
|}

== Notes ==
# Average depth of Manhattan tunnels constructed in 1900 was 30 feet.
# 72nd Street station became two tracks.
# All four tracks at Lexington Avenue (63rd Street station) exist today; only two are used for passenger services.

===Ground Support Challenges===
The 72nd and 85th Street stations faced constructability challenges related to ground support during the detailed design stage. Engineers discovered that the quality and depth of rock above the stations were not adequate to support the tunnel (Fulcher et al. 2013, Urban Engineers 2008). The original design of the 72nd Street station included three tracks, but it was at such a depth that the design team was forced to change the configuration to the current two tracks. This highlights the need for conducting thorough geotechnical studies and developing engineering alternatives rather than relying solely on a shallow FEIS analysis. This can prevent costly redesigns and reconstructions during the excavation process and ensure that the design aligns with the project’s goals.

===Utility Work and Contracting Challenges===
In the preliminary design phase, the project and design team initially planned to use six construction contracts, but they later encountered problems with utility work and the assumption that general contractors would handle all permits, engineering, and logistics. This resulted in the team having to break the contract into separate utility and station contracts as had been recommended by an engineering report on the construction of the original subway system in 1919 (NYC Engineering Report on Subway Construction). During construction, the project management team discovered that the buried foundations of elevated tracks on Second Avenue that had been demolished in the mid-1940s still existed, which presented a significant cleaning task. This was yet another instance where the project deviated from the best engineering practices in terms of a thorough geotechnical investigation prior to detailed design and risk management (Urban Engineers 2010).
===Real Estate Acquisition Challenges===
The design and project management team assumed that the acquisition of real estate for shaftways would be straightforward. However, accessing the ground beneath the surface was not without issue (Real Estate Record and Builders' Guide 1904). The team assumed that only one building would be necessary for real estate negotiations. However, in reality, access was needed through multiple interconnected buildings when the design team started the detailed design. Manhattan block buildings leaned on each other, and there was no gap between them (Eschenasy et al. 2017). Thus, an individual building provided support to the entire block. The design team had to construct a frame that supported the entire block to pull it out in one piece (Urban Engineers 2008).
In cases where the access shaft was going into a building, the SAS project needed an easement by law. However, the project needed to enter multiple buildings because the buildings were interconnected. Manhattan’s structures were designed so that someone living two or three buildings away from the access building had to walk through a hallway in the second or third building before arriving at the original access building. A deeded easement was required for this setup (Urban Engineers 2008).

A comprehensive approach to civil engineering best practices in project management is essential for understanding the intricacies of large-scale transit projects such as the SAS. Relying solely on individual perspectives and interpretations is insufficient for a profession that has built subway systems since the late 19th century. Successful projects necessitate a systemic understanding of project management, which includes thorough geotechnical studies, effective technical communication between stakeholders, and a detailed analysis of real estate acquisition and utility work. In addition, it is crucial to emphasize the importance of translating these efforts into the education of graduate students. They should be taught to understand construction deliverables, project delivery methods, and construction packaging in a practical manner, akin to the hands-on approach expected of law or medical students. This goes beyond mere memorization and equips future professionals with the skills necessary to navigate complex projects effectively. By learning from the experience of the SAS project, future project management teams can address challenges related to tunnel-boring machines, ground support, and utility work while also navigating the complexities of real estate acquisition and easement. Implementing these lessons will help minimize delays and cost overruns, which will ultimately lead to more efficient and cost-effective infrastructure development.

Moreover, it is vital for project management teams to remain adaptable and open to changes in their initial plans. This flexibility will enable them to respond effectively to unexpected challenges that may arise during the design and construction phases. It is equally important to invest time and resources in conducting comprehensive analyses, including geotechnical investigations and engineering alternative analyses, to ensure that projects are built on a solid foundation.

== Table 2: SAS Budget History ==

{| class="wikitable"
|+ SAS Budget History (in Millions)
|-
! Categories !! 1999 DEIS (Phase I & II) !! 1999 DEIS (Adjusted for Phase I) !! FEIS (2004 Record of Decision) !! FFGA (November 2007) !! Actual (2018)
|-
| '''Total Design''' || || || $410.00M || $410.00M ||
|-
| '''Construction Management Services''' || || || $86.00M || $80.94M ||
|-
| '''Construction''' || $4.82B || $2.17B || $2.81B || $2.69B || $2.78B
|-
| Contract 1: Tunneling || || || $375.88M || ||
|-
| Contract 2–6 & Others || || || $2,430.12M || ||
|-
| '''Rolling Stock *''' || $610.10M || $610.10M || $157.00M || $153.00M || ~~$0.00M~~
|-
| '''Real Estate''' || $131.40M || $59.13M || $191.00M || $240.96M || $281.50M
|-
| '''OCIP''' || || || $180.00M || $160.00M ||
|-
| '''Project Reserve''' || || || $8.00M || $173.10M ||
|-
| '''NYCT Labor, Utility Reimbursement, etc.''' || || || || || $145.30M
|-
| '''Subtotal Without Financing''' || $5.56B || $2.76B || $3.68B || $3.90B || $4.45B
|-
| '''Financing Cost''' || || || || || $796.31M
|-
| '''Total''' || || || || || $4.85B
|}

== Notes ==
# All estimates are for the **Year of Expenditure (2018)**.
# SAS Project Phase I **never paid for rolling stock**; therefore, the estimate is crossed out.

==Metropolitan Transportation Authority==
Public authorities acquired many of their transit systems from private companies that were in financial trouble after World War II. Because of the decline in profits and ridership, transit companies spent less money on maintenance and renovation, which resulted in their systems largely falling into disrepair by the time they were acquired by public authorities. The new transit authorities have had limited success in addressing the problem of station neglect, with a lack of funds being a major challenge. The NYC Transit Authority was established in 1953 (Homburger and Kennedy 1961), and the Metropolitan Transportation Authority (MTA) was created later in 1968 (New York Urban Transportation Group 1972). Since then, the MTA has consistently struggled with budget deficits and has been unable to establish a pricing equilibrium. It is not considered financially sustainable because of its reliance on government subsidies to balance its budget. It also lacks transparency in its financial system, and it is not held to the same standards of competency as private institutions. However, as a public institution, its value in terms of economic growth and employment through infrastructure investment must be recognized (Glaeser and Poterba 2020).
To operate sustainably and be responsive to taxpayers, the MTA needs to establish an equilibrium in funding to cover operating, maintenance, and capital improvement costs while recognizing that it may not conform to a normal pricing equilibrium (Mankiw 2018). It is crucial for project stakeholders to have confidence in the MTA’s management, whether practices are internal or external (Mayor's Committee on Management Survey 1953). The MTA has two primary roles in managing its transit projects: planning and economics, and engineering. To be competent in these practices, the MTA staff must possess the necessary knowledge and skills. Several reasons justify subsidizing public mass transit systems with taxes. First, taxation is the only practical way to collect from people who indirectly benefit from the transit system. Without taxes, the community would receive a benefit without contributing in return. Second, fares paid by riders do not fully cover the operating costs, depreciation, and capital asset investments. Therefore, it is necessary to collect part of the cost from both riders and the community through taxes (Litman 2021). Opponents may argue that fares should be high enough to cover the total costs of the transit system to eliminate the need for government subsidies (Coase 1960). This approach would discourage some people from using the system’s services and result in fewer riders. Subsidies help the MTA maintain affordable fares and allow the NYC transit system to operate at its intended capacity, as it has for over 100 years (Habib et al. 1978).
Notably, NYC’s transit system has always been subsidized, dating back to the first streets and docks built at public expense in 1684 and city-operated ferries crossing the East River. Even private investors were not allowed to increase fares to the level of pricing equilibrium. Transit facilities are generally more economical when heavily used, as reduced traffic leads to wasted capacity (Parry and Small 2009).

To achieve a funding equilibrium, the MTA must make an effort to itemize its costs and develop a plan to control them effectively. The complexity of its budget can be understood by examining three main categories: operating costs, maintenance costs, and capital investments in expanding the system (Engineering-Contracting 1910). Therefore, the MTA is responsible for managing taxpayer money in a way that balances its budget while also investing in capital growth to deliver sustainable transit projects. However, the MTA has struggled with effectively managing construction projects due to a lack of advancement in civil engineering practices and knowledge.

Theoretically, the MTA maintains a high level of accountability, but this is not consistently evident in its organizational practices (Hood 1992). As a result, while a design team may generate technical documents, the project management team of a consulting firm will not review them because it falls outside the scope of an engineering contract. In essence, the project management team satisfies the MTA’s staffing needs without requiring members to hold necessary engineering qualifications, understand engineering practices, or carry engineering liability insurance. Despite this, the MTA is the highest authority in the decision-making process and integrates the three variables of scope, cost, and schedule for capital projects. Most of the members of a project management team will not possess the necessary credentials to review engineering practices or deliverables because being a licensed engineer is not a key requirement. Rather, a certification in management is needed. This is a significant departure from reports from the early 20th century (Building the New Rapid Transit System of NYC 1915), which emphasized that the design and construction of the NYC subway system was primarily an engineering task with military-like organizational principles.
It is vital for the MTA to address this gap and prioritize engineering knowledge and practices in its project management. Currently, the project management team may move in one direction, the design team produce construction documents in another direction, and the construction team move in yet another direction independent of the other two. This lack of coordination can be seen in the SAS project, where the geotechnical design team produced design memos for the tunnels and stations that were signed off by the project management team and construction team. However, the construction documents did not consider the shallow depth of rock on top of the tunnels or the width of the tunnels in their original three-track design, which caused problems in the construction of the stations. The schedule and budget approved by the project management team confirmed that it reviewed the design, but no changes were made, which is likely because the FTA would not pay for a project redesign.

To overcome these challenges and improve overall performance, the MTA must make significant changes in its organizational structure and management practices. One critical step is to require project management staff to possess engineering credentials and knowledge. By doing so, the MTA can better align its various teams and ensure that they are working collaboratively toward a common goal. Furthermore, the MTA should invest in the professional development of its staff by providing ongoing training and resources related to civil engineering practices. This will help it keep up with advancements in the field and ensure that its projects are executed using the most up-to-date techniques and methods.

Another essential component of improving management practices is to increase transparency and accountability within the MTA. By implementing performance metrics and regularly tracking progress, it can ensure that it is effectively managing taxpayer money and delivering results in line with its objectives. Increased transparency can help build public trust and demonstrate that the MTA is committed to providing quality service while responsibly managing its resources. Finally, the MTA should focus on forging stronger partnerships with external stakeholders such as local governments, businesses, and community organizations.
Conclusion

The early 20th century witnessed the evolution of civil engineering into an established profession with a comprehensive knowledge base. Civil engineers contributed to the construction of massive projects such as the NYC subway system, which required technical and economic expertise. However, civil engineering faces vulnerabilities because of the absence of a well-rounded education system that can prepare engineering students for the complexities of future projects and the disconnect between academia and engineering practices. As civil engineering knowledge continues to develop, the profession must address these vulnerabilities and adapt to the changing demands of the industry.

The SAS project faced multiple design challenges and construction decisions that resulted in considerable cost overruns. The assumptions made by the project management and design teams regarding geotechnical issues, construction contract packaging, real estate acquisition, and easement were unable to handle the complexity of the SAS project. This resulted in unexpected costs and delays, as evidenced by the significant budget increases. To avoid similar issues, it is crucial to examine the logic and lessons learned from the project and apply these insights to future endeavors. The lack of well-defined best practices for project management played a role in these issues. To avoid similar problems in future transit projects, the ASCE should establish comprehensive best practices for project management, design, and construction encompassing consistent engineering principles, legal clarity, and acceptable performance levels for interpretation under the NEPA. By adopting these best practices, transit agencies and engineering firms can collaborate more effectively to complete crucial infrastructure projects on schedule and within budget. The SAS project serves as a case study for the importance of thorough planning, effective communication, and adaptability in the face of complex challenges. The lessons learned from this project can be applied to the better planning, design, and execution of future infrastructure projects, which will ultimately benefit both the industry and the public.
The MTA is a vital public institution responsible for providing essential transit services to NYC citizens. However, it faces significant challenges related to financial sustainability and management practices. By prioritizing engineering knowledge and practices, increasing transparency and accountability, and fostering stronger partnerships with external stakeholders, the MTA can transform itself into a more efficient, cost-effective, and responsive organization. These changes will ultimately lead to better transit services for the public and a more sustainable future. As the MTA evolves and adapts to these new management practices, it can serve as a model for other public institutions looking to improve their own operations and better serve their constituents.

==Data Availability Statement==

All data used in this study is publicly accessible and can be obtained through the provided references. For the PMOC reports, readers can access the FTA’s website at https://www.transit.dot.gov/foia/metropolitan-transportation-authority-second-avenue-subway. The 2013 “The Politics of Large Infrastructure Investment Decision-Making: The Case of the Second Avenue Subway Case Study” report can be found at https://rosap.ntl.bts.gov/view/dot/27119.

== References ==

* Abbott, A. (2014). ''The system of professions: An essay on the division of expert labor''. University of Chicago Press, Chicago, USA.
* Barzelay, M. (2001). ''The new public management: Improving research and policy dialogue''. University of California Press, Berkeley, CA.
* Civil War Railroad Report. (1865). ''Report on the construction of railroads during the Civil War''. War Department Records, USA.
* Coase, R. H. (1960). "The problem of social cost." ''J. Law Econ.'', 3, 1–44.
* Concord Canal Report. (1825). ''Report on the Concord Canal''. Massachusetts State Records, USA. 7, 6.
* Council on Environmental Quality. (2014). ''A citizen’s guide to the NEPA: Having your voice heard''. Council on Environmental Quality 2007, Washington, DC. [https://ceq.doe.gov/docs/get-involved/Citizens_Guide_Dec07.pdf Link].
* Department of Energy. (1970). "National Environmental Policy Act of 1970." ''Public Law'', 91, 11.
* Durand, W. F. (1929). ''Robert Henry Thurston: A biography, the record of a life of achievement as engineer, educator, and author''. The American Society of Mechanical Engineers, New York.
* Dzur, A. W. (2008). ''Democratic professionalism: Citizen participation and the reconstruction of professional ethics, identity, and practice''. Pennsylvania State University Press, University Park, PA.
* Engineering-Contracting. [https://www.google.com/books/edition/_/HAHQQxqfkRMC?hl=en&sa=X&ved=2ahUKEwjgveWIwv_-AhXaEVkFHTOmCfkQre8FegQIARAV&bshm=bshwcqp/1 Link].
* Eschenasy, P.E., F.SEI Bharat Gami, R.A., Gus Sirakis, P.E. (2017). "Special topics in construction safety course number SW0317." Presentation at the Build Safe/Live Safe Conference, NYC Department of Buildings, New York.
* Filion, P., & Hammond, K. (2003). "Neighbourhood land use and performance: The evolution of neighbourhood morphology over the 20th century." ''Environ. Plann. B Plann. Des.'', 30(2), 271–296.
* Fitch, R. (1999). ''The assassination of New York''. Verso, London, UK.
* Fulcher, B., Menge, S., & Grillo, J. (2013). "New York City—Second Avenue Subway: MTA’s 72nd Street Station and tunnels project construction of a large span station cavern, running tunnels, cross-over and turn-out caverns, shafts and entrances." ''Proc., Rapid Excavation Tunneling Conf 2013 Proceedings''. Society for Mining, Metallurgy, and Exploration.
* Glaeser, E. L., & Poterba, J. M. (2020). "Introduction to economic analysis and infrastructure investment." ''Economic Analysis and Infrastructure Investment''. University of Chicago Press, Chicago. [https://www.nber.org/books-and-chapters/economic-analysis-and-infrastructure-investment/introduction-economic-analysis-and-infrastructure-investment Link].
* Glaeser, E. L., & Poterba, J. M. (2021). ''Economic analysis and infrastructure investment'' (Vol. 28215). National Bureau of Economic Research, Inc., NY.
* Gordon, T., & Schleicher, D. (2015). "High costs may explain crumbling support for US infrastructure." ''Real Clear Policy''.
* Gotshall, W.C. (1903). ''Notes on electric railway, economics and preliminary engineering''. McGraw Publication Company, New York.
* Habib, P., Linzer, E., Jones, C., Nason, R., & Ablamsky, R.A. (1978). ''Fare policy and structure''. Polytechnic Institute of New York, Urban Transportation Research Center, New York.
* Hall, P. (2002). ''Urban and regional planning''. Routledge, London, UK.
* Harris, F., & McCaffer, R. (2013). ''Modern construction management''. Wiley-Blackwell, Chichester, UK.
* Homburger, W. S., & Kennedy, N. (1961). ''The organization of metropolitan transit agencies''. University of California, USA.
* Hood, C. (1992). ''The landscapes of modernity: Essays on New York City''. Russell Sage Foundation, Baltimore. [http://academic.brooklyn.cuny.edu/history/burrows/NYC/Documents/hood.htm Link].
* Hood, C. (2004). ''Miles: The building of the subways and how they transformed New York''. Johns Hopkins University Press, Baltimore, MD.
* Kates, W. R., Parris, T. M., & Leiserowitz, A. A. (2005). "What is sustainable development? Goals, indicators, values, and practice." ''Environ. Sci. Policy Sustain. Dev.'', 47(3), 8–21. [https://doi.org/10.1080/00139157.2005.10524444 Link].
* Kaufman, H. (1956). "Emerging conflicts in the doctrines of public administration." ''Am. Polit. Sci. Rev.'', 50(4), 1057–1073. [https://doi.org/10.2307/1951335 Link].
* Kerzner, H. (2009). ''Project management: A systems approach to planning, scheduling, and controlling''. John Wiley & Sons, Hoboken, NJ.
* Kirkwood, N. (2012). ''The end of the line: A history of railways in Great Britain''. The History Press, Stroud, UK.
* Koppenjan, J. F. M., & Enserink, B. (2009). "Public–private partnerships in urban infrastructures: Reconciling private sector participation and sustainability." ''Public Admin. Rev.'', 69(2), 284.
* Labuschagne, C., & Brent, A. C. (2004). ''Sustainable project life cycle management: Aligning project management methodologies with the principles of sustainable development''. PMSA, Johannesburg, South Africa. [http://hdl.handle.net/2263/4856 Link].
* Levinson, D. M. (2003). ''Financing transportation networks''. Edward Elgar Publishing, Cheltenham, UK.
* Lewis, P. (2004). ''Urban planning and the American family''. Temple University Press, Philadelphia, PA.
* Mankiw, N. G. (2018). ''Principles of economics''. 8th ed., Cengage Learning, Boston, MA.
* PMOC reports. (2013). [https://www.transit.dot.gov/foia/metropolitan-transportation-authority-second-avenue-subway Link].
* Real Estate Record and Builders’ Guide. (1904). ''Real estate record and builders guide''. LXXIV, 718. [https://www.google.com/books/edition/_/ZqdRAAAAYAAJ?hl=en&gbpv=0&bshm=bshwcqp/1 Link].
* Rosenthal, B. M., & Fitzsimmons, E. G. (2017). "Why does subway construction cost so much? Congress wants to find out." ''The New York Times''. [https://www.nytimes.com/2018/03/28/nyregion/new-york-subway-construction-costs-congress.html Link].
* Subway. (1920). "Cost $350,000,000." ''The New York Times''. [https://timesmachine.nytimes.com/timesmachine/1920/12/05/102965570.html?pageNumber=117 Link].
* The Politics of Large Infrastructure Investment Decision-Making: The Case of the Second Avenue Subway Case Study. Report No. 49111-16-23. [https://rosap.ntl.bts.gov/view/dot/27119 Link].

Bridging the Gaps: Better Infrastructure Project Management and Civil Engineering

2025-02-11T23:21:19Z

Pooyan: /* Design and Construction Decisions */

'''Bridging the Gaps: Better Infrastructure Project Management and Civil Engineering

Practices Based on Lessons from the Second Avenue Subway Project'''

== Abstract==
The importance of thorough geotechnical investigations, effective communication, and adaptability to ensure the completion of complex transit projects on time and under budget cannot be emphasized enough. The Second Avenue Subway (SAS) project in New York City has come under intense scrutiny owing to numerous delays and massive cost overruns. This paper highlights the need for a transformation in civil engineering graduate programs to better equip students and practitioners for the complexities of transit project deliveries. Due to an overemphasis on theoretical computational practices, civil engineers have neglected the development and interpretation of policy knowledge, leading to critical decisions being made by those with limited sustainability understanding. This trend, combined with the ineffective communication of technical aspects, has contributed to escalating costs and misaligned sustainability outcomes in transit projects. Herein, a holistic learning approach that encompasses project management, public policy, and real-world case studies is presented to bridge the current knowledge gap and prepare future professionals for successfully delivering sustainable, on-time, within-budget transit projects.

Herein, the management, engineering, and administrative practices employed in the SAS project are comprehensively analyzed. Key assumptions made by the project management and design teams are highlighted that led to unexpected costs and delays. The role of the Metropolitan Transportation Authority (MTA) as an administrative agency is examined and gaps in engineering knowledge and practices within the MTA are identified.

The analysis results demonstrate the need to address the financial sustainability of transit projects and obtain a funding equilibrium. In addition, the MTA needs to prioritize hiring and promoting individuals with engineering credentials, increase transparency and accountability, and foster stronger partnerships with external stakeholders.
The lessons learned from the SAS project can be used to inform future infrastructure projects and guide the transformation of the MTA into a more efficient, cost-effective, and responsive organization.

==Practical Applications==

This paper addresses the challenges faced by civil engineering professionals in delivering transit projects on time and within budget. Modern civil engineers must have a diverse set of skills, encompassing engineering, planning, economics, environmental science, management, finance, and law. Additionally, they must understand public policy and sociology while being updated on the challenges of translating public policies into engineering outcomes.
The paper emphasizes the need for meaningful change in civil engineering graduate school programs to include project management, public policy, and professional practices using real-world cases and public projects. This will equip students and practitioners with necessary tools to plan and manage transit projects effectively.
Because of the increased complexity of US public administration since WWII, learning transit fundamentals and problem-solving techniques within the context of delivering sustainable projects by graduate students is urgently required. Additionally, this paper underscores the importance of modifying civil engineering education to better prepare professionals for the challenges and opportunities in the realm of transit project delivery.

==Introduction==

Unlike other engineering disciplines, civil engineering is inextricably intertwined with public projects, which differ dramatically from other engineering products because they do not follow a single pattern or protocol (Harris and McCaffer 2013). Public projects develop in response to particular societal and governmental needs, and thus the broader economic, environmental, and political contexts in which they are embedded must be considered. The successful completion of these projects requires civil engineers who are not just technically competent but also able to understand public policy as well as political, environmental, and sociological concerns (Labuschagne and Brent 2004). Relatedly, civil engineers do not develop or work on products that can be sold to generate revenue but on projects that must secure governmental funding and approval as well as satisfy not only individual users but also public stakeholders (Koppenjan and Enserink 2009).

Kaufman (1956) outlined three distinct phases in the evolution of administrative leadership in the United States to address the core value of representativeness in a democracy. The first phase focused on representativeness in the nascent government with “No taxation without representation” as the principal interest of independence. The second phase was the quest for “neutral competence” that began after the Civil War and continues to this day. The aim was for the government to work based on explicit and objective standards rather than personal, party, or other obligations and loyalties. The slogan “Take administration out of politics” gave rise to the Civil Service Act of 1883, which aimed to control the selection of government workers by establishing a merit-based hiring system and offering formal training to civil servants at universities (Kaufman 1956). Although states and localities were slow to adopt these practices, they have made significant strides in recent years. The third phase focuses on the need for “executive leadership” to bridge the gap between the unresponsiveness of neutral competence and the public’s demand for clear communication. Civil engineers can play a crucial role in this process by negotiating effectively with bureaucratic entities and forming alliances with legislative committees and groups, which will allow them to gain greater autonomy in decision-making if they can establish clear expectations for knowledge and outcomes.

However, civil engineering has not yet established best practices in three areas: public policy, project management, and professional practice. This has posed challenges for individual engineers within powerful organizations to influence policy decisions for the public’s benefit.

In the United States, transit projects have long been a source of frustration for the public because of their high costs and delays. Media headlines have highlighted these issues and have painted a picture of inefficiency and exorbitance in the public sector (Gordon and Schleicher 2015, Rosenthal and Fitzsimmons 2017). Scholars and policy analysts have proposed various explanations for these problems, including the cost of land, regulations, and community opposition (Glaeser and Poterba 2020). However, the evolution of civil engineering, particularly the narrowing of the knowledge base and skill set associated with the profession, may be a significant but overlooked factor. Of course, this narrowing is not a development exclusive to civil engineering alone. Abbott (1986) noted that professions often become more specialized over time, which leads to a reduction in the knowledge and skill set of individuals. However, while such specialization may make sense in other professions, the narrowing of civil engineering has contributed to a failure to fully integrate the technical requirements of transit projects with political, social, environmental, and economic needs. This has resulted in a disconnect between the technical aspects of transit projects, which civil engineers are trained to address, and the non-technical aspects, which they are not. This has led to increased costs and public frustration. Civil engineers can play a significant role in overcoming this disconnect and contributing to the development and execution of successful and sustainable transit projects, but only if their own education and training shifts to (re)emphasizing sustainability. A clearer understanding of how the capacity and role played by civil engineers has changed over time is needed to help address these problems.

The Second Avenue Subway (SAS) project in New York City (NYC) has garnered attention because of design issues, construction challenges, and decisions that led to massive cost overruns. This project faced numerous design challenges including building a new subway line in a densely populated urban area and accounting for varying geological conditions along the route. Ongoing criticism of the SAS project’s cost and delays in completion have resulted in scrutiny of the project management and decision-making processes. In this paper, the SAS project is used as a case study to highlight the need for a more detailed study on engineering alternatives and the establishment of best practices in project management to prevent cost overruns and delays in future projects.

== Civil Engineering Knowledge==
===From 1800 to 1950===
In the early days of civil engineering in the United States, ad hoc public commissions or chartered companies managed public construction projects (Kaufman 1956). With the evolution of the field, civil engineering became known as “land development” (Williams 1922). The primary concern of such commissions was feasibility, which led to the first wave of public projects consisting of canal construction (Poor 1860). The Concord Canal Report (1825) emphasized assessing a project’s economic and technical value before execution, which necessitated consulting experts in mechanics, hydraulics, geology, and soils to estimate the costs, benefits, and results. When debating whether Massachusetts should promote canals or railroads, Governor Levi Lincoln consulted experts in various fields to resolve questions related to labor, expenses, and project benefits and results (Poor 1860).

The Civil War represented a turning point for civil engineering as railroads were constructed to facilitate transportation of Union armies, which laid the groundwork for modern civil engineering. In the post-Civil War era, civil engineers collaborated with investors to finance and build railroads, which significantly contributed to the country’s economic growth (Civil War Railroad Report 1865). Railway engineers needed knowledge in finance and business management because private financiers were the primary investors in railroads while the government granted rights of way. Gotshall (1903) highlighted the importance of these skills by demonstrating the practicability of high-speed electric railways from both engineering and commercial perspectives. In the late 19th century, Thurston argued for a dedicated method of publication to provide engineers with detailed and specific knowledge in their field. He called for an institution devoted to providing individuals with technical training and practical laboratory experience (Durand 1929), which aligned with the trend for various fields at the time of specialization in knowledge and skills. The emergence of professional societies such as the American Society of Civil Engineers (ASCE) facilitated this trend by providing a platform for knowledge exchange and expertise. Thurston’s vision and the emergence of professional societies laid the foundation for the growth and development of civil engineering as a full-fledged profession in the United States. However, this also led to the emergence of new administrative challenges and changes that significantly affected its ability to expand its intellectual dominance among engineering disciplines (Durand 1929).

At the beginning of the 20th century, civil engineering encompassed a combination of factual, conceptual, and procedural knowledge. Unlike law and medicine, engineering schools were founded by college-trained professors who designed the curricula. Although the apprenticeship method was used to train engineers, it never developed into significant engineering schools. Teaching theory before practice led to many first- and second-year students feeling disoriented and disheartened because they continued to engage in the same routine of reading books and studying abstract symbols as they did in high school (Durand 1929). This disconnection between academia and engineering practice became evident during the construction of massive projects that required unprecedented coordination, planning, and management. Parsons (1902), who was the Chief Engineer of the NYC Rapid Transit Commission at the time, warned that the engineer of the future would need to deal not only with calculations but also with human needs, industrial demand, finance, and legislation. Engineers would need to combine technical and economic expertise to conceive, plan, design, execute, and manage projects.

===From 1950 to the Present===
The post-World War II era brought several challenges to civil engineering, including the bankruptcy of the railroad industry, massive administrative changes, and the widening gap between academia and professional practice. The United States underwent a major administrative shift by transitioning from ad hoc decision-making when funding transit projects to a more structured and centralized system emphasizing executive leadership, efficiency, and data-driven decisions (Barzelay 2001). This approach influenced agencies such as the Federal Transit Administration (FTA), where urban planners began to outnumber civil engineers (Lewis 2004). Despite improvements in transit planning, a disconnect persisted between professionals and politicians, which raised concerns about the effectiveness of decision-making and implementation (Levinson 2003). Urban planning evolved as a profession in response to the challenges of urbanization in the late 19th century (Hall 2002). Initially, city planning focused on the City Beautiful concept. However, as cities expanded, land economics became increasingly important (Filion and Hammond 2003). Lawyers, civil engineers, and urban planners all began playing key roles in shaping American infrastructure (Peterson 2003).

The ASCE did not heed Parsons’ warning from the early 20th century, and they neglected to advance their knowledge in project management, public policy, and professional practice (Fitch 1999). When the transit industry went bankrupt, the National Environmental Policy Act (NEPA, Department of Energy 1970) was published, and the FTA issued several policy documents on funding strategies for transit projects. Civil engineers struggled to add engineering interpretations of these policy documents with regard to recommending best practices and ensuring that new engineers are educated accordingly in universities (Barzelay 2001). In addition, a governmental shift toward a business-oriented approach led to a decline in practical professors and licensed engineers, which caused a loss of influence by civil engineers (Dzur 2008). Meanwhile, organizations such as the Project Management Institute have enabled managers without an engineering background to assume high decision-making positions within governments and engineering firms offering construction management services (Kerzner 2009). Abbott (1986) argued that business-oriented practices are more applicable to professions that lack technical roots and thus prioritize business strategies. However, professions such as civil engineering and medicine derive their legitimacy not just from efficiency and quality management but also from the technical skill and experience inherent to their fields.

Following the Civil Service Act and the rise of neutral competence, civil engineers should have developed a series of management practices tailored to enhance the overall functioning of transit organizations, which would have helped them to effectively manage and maintain the developed infrastructure as well as provide informed engineering interpretations of policy documents such as the NEPA (Perry and Rainey 1988). Unfortunately, civil engineers did not work on developing and interpreting policy knowledge, but rather they became focused on a narrow scope of computational practices in design, which was driven by an excessive theoretical focus in academia (Petroski 2011). This knowledge gap, combined with the lack of participation by civil engineers in interpreting the NEPA, led to major planning decisions being made by planners and economists with a limited understanding of sustainability (Council on Environmental Quality 2014). Consequently, NEPA is now perceived as a permitting tool rather than an engineering document, which has caused public participation to be associated with Not in My Backyard (NIMBY) attitudes and resulted in misaligned sustainability outcomes for transit projects (Kates et al. 2005; Real Estate Record and Builders’ Guide 1868–1884). Urban planners and civil engineers both play critical roles in evaluating transit project options. While urban planners focus on the socioeconomic impacts, civil engineers concentrate on the technical and operational aspects. However, the failure of civil engineers to effectively communicate technical issues to stakeholders has led to the NEPA being regarded as a bureaucratic process, which has caused transit project costs to soar (Petroski 2011).

The inability of civil engineering to adapt to the evolving landscape of public administration and the growing influence of policy documents on engineering practice may have weakened its standing. Furthermore, practitioners are unable to effectively shape their academic foundations, unlike their counterparts in medicine and law (Petroski 2011). This has led to disjointed and ad hoc academic solutions, particularly in graduate programs, which fail to provide civil engineering students with the necessary knowledge and skills to understand a project’s life cycle in the context of project management as well as policy knowledge for funding and executing transit projects on time and within budget (Perry and Rainey 1988).

In an attempt to address these shortcomings, construction management has been introduced as a hybrid program between business and engineering schools (Petroski 2011). Unfortunately, these programs often lack an engineering-focused approach to expanding undergraduate curricula to develop students’ understanding of public policies, project management, and professional practice. Instead, they primarily emphasize the memorization of terminology and the use of ad hoc computational software (Katz 2012). In professional practice, civil engineers have struggled to adapt to changing demands, including new technologies and increased regulations. The profession must reassess its approach and incorporate the necessary skills and knowledge to effectively contribute to the construction of sustainable infrastructure projects (Petroski 2011). The lack of engineering interpretation of public regulations such as the NEPA and the FTA’s Capital Investment Grants Program requirements has significantly affected the planning and execution of infrastructure projects (Council on Environmental Quality 2014). The ASCE has acknowledged the issue of practical experience within the profession, but it has struggled to intervene in graduate education (ASCE 2008). Moreover, the lack of input by civil engineers in interpreting the NEPA has led to major planning decisions being made by planners and economists with a limited understanding of sustainability (Council on Environmental Quality 2014).

To tackle the challenges faced by civil engineers, a holistic approach to project delivery is needed that combines technical expertise, policy understanding, and quality management practices. Although the Accreditation Board for Engineering and Technology (ABET) ensures the quality of undergraduate education, graduate programs often lack these three essential components. ABET was established in 1932 as the Engineers’ Council for Professional Development and was initially focused on the technical content taught in courses. In 1997, ABET shifted its emphasis to learning outcomes with the introduction of Engineering Criteria 2000 (EC2000) (ABET 2021). This transition led to a more flexible approach, which is a key quality needed for professionals to succeed in fields of vital importance to society (Kates et al. 2005). By investing in academic knowledge and prioritizing technical expertise over business-oriented practices, civil engineering can restore its value and effectively contribute to the construction of sustainable infrastructure projects in the future (Petroski 2011). Civil engineers must also play an active role in interpreting and complying with important policy documents such as the NEPA to ensure that the intended sustainability outcomes are achieved (Council on Environmental Quality 2014). By doing so, civil engineers can avoid the mistakes of the past and build a better future for our planet. The need for a more comprehensive approach to project delivery and a greater understanding of public policy is essential for the continued growth and success of civil engineering.

==Second Avenue Subway Project==
===Historical Context and the Need for Best Practices===

In this study, we have employed a research methodology centered on the SAS project. We used publicly available data from three main sources. First, we conducted an in-depth analysis of engineering reports and documentation from the SAS project found in the FTA’s oversight monitoring reports, published by its project management oversight contractor (PMOC reports 2013). Second, we examined the MTA’s publicly available quarterly comprehensive reports to stakeholders. Lastly, we reviewed relevant reports and literature on NYC subway construction during 1880–1920. These reports contained Rapid Transit Commission reports and best practices in the transportation infrastructure domain.

The data-analysis component of our methodology included qualitative and quantitative methods. Initially, we reviewed the engineering reports and the PMOC and MTA reports on the SAS project. Furthermore, this examination facilitated the extraction of pertinent data and identification of key themes and patterns concerning project performance, challenges encountered, and lessons learned. We have utilized our professional experience and expertise in the field to offer context and nuance to data analysis. This has allowed for a comprehensive understanding of the project’s complexities and highlighted the significant aspects that may otherwise have been overlooked. Moreover, we have compared the SAS project’s performance, challenges, and outcomes with those documented in the literature on the NYC subway project of 1900. This comparative analysis was aimed to pinpoint any unique aspects of the SAS project and evaluate its overall success in relation to the Rapid Transit Commission’s NYC subway in the early 20th century.

We devised evaluation criteria based on findings from the literature review to estimate the project’s performance. Furthermore, we considered the specific goals and objectives proposed in the SAS draft environmental impact statement (EIS) and final EIS. We employed these criteria to evaluate various dimensions of the SAS project, such as cost, schedule, quality, and stakeholder satisfaction (PMOC reports 2013).

The construction of the NYC subway system in the early 20th century exemplifies the technical and financial expertise required of civil engineers. The system cost approximately 350 million USD to construct in 1920 (New York Times 1920), which is equivalent to 4.48 billion USD in 2018. This is similar to the construction cost of the Panama Canal, which was approximately 375 million USD at the time, and it exceeded the cost of similar systems in all other great cities in the world combined. However, the NYC subway system has since become a vital part of the city’s transit infrastructure and has contributed to its economic growth and development. It serves as a testament to the importance of civil engineering in society (Kirkwood 2012). Although the term “sustainability” was not explicitly used during the planning and design of the NYC subway system, all three pillars of sustainability (i.e., economic viability, environmental protection, and social equity) were integral to its construction (Walker 1917). The importance of effective technical communication can be seen in the annual reports of the Rapid Transit Commission. Notably, the challenges faced by the commission at the time were not that different from those faced in the 21st century, such as the population density of Manhattan, subway routes, funding issues, concerns of the public, and tunnel depth (Hood 2004). Documents from the early 20th century (Gotshall 1903, Walker 1917) describe the cost and economic viability of the NYC subway system considering construction challenges and an 1896 court order while also highlighting the social, environmental, and economic impacts.

For new transit systems, the ASCE assesses how well they align with current engineering best practices and requirements. The ASCE Report Card offers insights into the necessary expenditures to maintain transit systems, but its primary objective is to ensure compliance with contemporary standards (Glaeser and Poterba 2020). This assessment can be influenced by subjective factors such as the performance of the responsible organization. It is crucial to understand that a poor evaluation does not always imply a poorly functioning subway system because the ASCE does not distinguish between management and engineering. In other words, a system could be well-engineered but poorly managed. Most subway systems were built in the 1940s, and since then agencies originally responsible for their construction have transitioned to their operation. Thus, such agencies have lacked involvement in engineering projects to build new subways for nearly six decades.

In the existing legal framework, project management contracts are neither considered professional service contracts nor backed by surety, and the ASCE has not yet formulated best practices for project management similar to those developed for design and temporary construction, which have clear guidelines and codes to which the design team must adhere. In the absence of clear guidelines, project management teams may not be held accountable for any issues, which can potentially jeopardize their reputation and credibility. To address this lack of knowledge, the ASCE can publish best practices for transit project management, design, and construction with a focus on consistent engineering principles and legal clarity. The ASCE should establish best practices for an acceptable level of performance concerning project management services. These can include constructability review documents, project budgets, contingency plans, and schedules on par with the approximately 70 design standards currently maintained by the organization.

===Design and Construction Decisions===
The SAS project has garnered attention due to its design, construction challenges, and decisions that led to massive cost overruns. The absence of best practices for project management contributed to the project’s setbacks.
The SAS project faced numerous design challenges, including building a new subway line in a densely populated urban area and accounting for varying geological conditions along the route. Table 1 presents the depths of stations for the SAS project. The draft environmental impact statement (DEIS) for the SAS did not discuss the three options of shallow, mid-depth, and deep tunnels to determine the most feasible path forward. The number of ventilation shafts and access shafts required is related to the depth of the tunnel. The Rapid Transit Subway Construction report provided guidelines for balancing the cost, soil type, construction method, and location to determine the optimal depth for subway tunnels (Associated Engineers-A Joint Venture 1975, New York Urban Transportation Group 1972).

During the preliminary engineering phase between 2000 and 2004, the project management team created budget and contingency plans before entering the final design phase. Despite these efforts, the budget at the Record of Decision had grown to 3.68 billion USD, which was an increase of 920 million USD over the original projection from the 1999 DEIS. By the time the SAS project secured federal government funds, the budget had reached 3.90 billion USD, and it eventually increased to 4.45 billion USD by the time of completion. The ongoing criticism of the cost overruns and delays has resulted in scrutiny of the project management and decision-making processes. The publication of the Final Environmental Impact Study (FEIS) in 2004 elaborated solely on different means of constructing a transit system on Second Avenue, which is primarily a planning practice. This highlights the need for a more detailed study of engineering alternatives and a stronger emphasis on establishing best practices in project management to prevent cost overruns and delays in future projects.

===Geotechnical Design and Construction Issues===
===Tunnel-Boring Machine===
The project management team faced several geotechnical design and construction issues. One of the challenges was related to the tunnel-boring machine (TBM). The team initially justified the use of a TBM because of its ability to dig underground without causing surface disruptions. However, they did not properly plan for the removal of soil excavated by the TBM, which led to the contractor having to install large muck removal and caused obstructions and disruptions at the street level. Furthermore, the cost of using the TBM was triple the amount needed for the more traditional method of cut and cover, which raised questions about the effectiveness of constructability review documents and project management practices (Urban Engineers 2012).

== Table 1: SAS Station Depth ==

{| class="wikitable"
|+ SAS Station Depth
|-
! Station !! Location !! Type !! Transfer Routes !! Preliminary Entrance Locations !! Approximate Station Depth
|-
| '''SECOND AVENUE LINE'''
| colspan="5" style="background-color:#dddddd;" |
|-
| 96th St || Second Ave/96th to south of 94th St || 2 track || || Second Ave/southwest corner of 96th St and northeast and southwest corners of 94th St || 40–45 ft
|-
| 86th St || Second Ave/87th to south of 82nd St || 2 track || || Second Ave/northeast and southeast corners of 86th St and eastern side of Second Ave between 83rd and 84th Sts || 85 ft
|-
| 72nd St || Second Ave/72nd to 69th St || 3 track || Bway/Second Ave Lines || Second Ave/northeast and southwest corners of 72nd St; and northeast corner of 69th St || 85 ft
|-
| '''63RD STREET LINE'''
| colspan="5" style="background-color:#dddddd;" |
|-
| Lexington Ave || 63rd Street/Lexington to Third Ave || 4 track || F || Existing: Lexington Ave/63rd St; New: Third Ave/63rd St (northwest, southeast, and possible northeast corners) || 105–135 ft
|}

== Notes ==
# Average depth of Manhattan tunnels constructed in 1900 was 30 feet.
# 72nd Street station became two tracks.
# All four tracks at Lexington Avenue (63rd Street station) exist today; only two are used for passenger services.

===Ground Support Challenges===
The 72nd and 85th Street stations faced constructability challenges related to ground support during the detailed design stage. Engineers discovered that the quality and depth of rock above the stations were not adequate to support the tunnel (Fulcher et al. 2013, Urban Engineers 2008). The original design of the 72nd Street station included three tracks, but it was at such a depth that the design team was forced to change the configuration to the current two tracks. This highlights the need for conducting thorough geotechnical studies and developing engineering alternatives rather than relying solely on a shallow FEIS analysis. This can prevent costly redesigns and reconstructions during the excavation process and ensure that the design aligns with the project’s goals.

===Utility Work and Contracting Challenges===
In the preliminary design phase, the project and design team initially planned to use six construction contracts, but they later encountered problems with utility work and the assumption that general contractors would handle all permits, engineering, and logistics. This resulted in the team having to break the contract into separate utility and station contracts as had been recommended by an engineering report on the construction of the original subway system in 1919 (NYC Engineering Report on Subway Construction). During construction, the project management team discovered that the buried foundations of elevated tracks on Second Avenue that had been demolished in the mid-1940s still existed, which presented a significant cleaning task. This was yet another instance where the project deviated from the best engineering practices in terms of a thorough geotechnical investigation prior to detailed design and risk management (Urban Engineers 2010).
===Real Estate Acquisition Challenges===
The design and project management team assumed that the acquisition of real estate for shaftways would be straightforward. However, accessing the ground beneath the surface was not without issue (Real Estate Record and Builders' Guide 1904). The team assumed that only one building would be necessary for real estate negotiations. However, in reality, access was needed through multiple interconnected buildings when the design team started the detailed design. Manhattan block buildings leaned on each other, and there was no gap between them (Eschenasy et al. 2017). Thus, an individual building provided support to the entire block. The design team had to construct a frame that supported the entire block to pull it out in one piece (Urban Engineers 2008).
In cases where the access shaft was going into a building, the SAS project needed an easement by law. However, the project needed to enter multiple buildings because the buildings were interconnected. Manhattan’s structures were designed so that someone living two or three buildings away from the access building had to walk through a hallway in the second or third building before arriving at the original access building. A deeded easement was required for this setup (Urban Engineers 2008).

A comprehensive approach to civil engineering best practices in project management is essential for understanding the intricacies of large-scale transit projects such as the SAS. Relying solely on individual perspectives and interpretations is insufficient for a profession that has built subway systems since the late 19th century. Successful projects necessitate a systemic understanding of project management, which includes thorough geotechnical studies, effective technical communication between stakeholders, and a detailed analysis of real estate acquisition and utility work. In addition, it is crucial to emphasize the importance of translating these efforts into the education of graduate students. They should be taught to understand construction deliverables, project delivery methods, and construction packaging in a practical manner, akin to the hands-on approach expected of law or medical students. This goes beyond mere memorization and equips future professionals with the skills necessary to navigate complex projects effectively. By learning from the experience of the SAS project, future project management teams can address challenges related to tunnel-boring machines, ground support, and utility work while also navigating the complexities of real estate acquisition and easement. Implementing these lessons will help minimize delays and cost overruns, which will ultimately lead to more efficient and cost-effective infrastructure development.
Moreover, it is vital for project management teams to remain adaptable and open to changes in their initial plans. This flexibility will enable them to respond effectively to unexpected challenges that may arise during the design and construction phases. It is equally important to invest time and resources in conducting comprehensive analyses, including geotechnical investigations and engineering alternative analyses, to ensure that projects are built on a solid foundation.

== Table 2: SAS Budget History ==

{| class="wikitable"
|+ SAS Budget History (in Millions)
|-
! Categories !! 1999 DEIS (Phase I & II) !! 1999 DEIS (Adjusted for Phase I) !! FEIS (2004 Record of Decision) !! FFGA (November 2007) !! Actual (2018)
|-
| '''Total Design''' || || || $410.00M || $410.00M ||
|-
| '''Construction Management Services''' || || || $86.00M || $80.94M ||
|-
| '''Construction''' || $4.82B || $2.17B || $2.81B || $2.69B || $2.78B
|-
| Contract 1: Tunneling || || || $375.88M || ||
|-
| Contract 2–6 & Others || || || $2,430.12M || ||
|-
| '''Rolling Stock *''' || $610.10M || $610.10M || $157.00M || $153.00M || ~~$0.00M~~
|-
| '''Real Estate''' || $131.40M || $59.13M || $191.00M || $240.96M || $281.50M
|-
| '''OCIP''' || || || $180.00M || $160.00M ||
|-
| '''Project Reserve''' || || || $8.00M || $173.10M ||
|-
| '''NYCT Labor, Utility Reimbursement, etc.''' || || || || || $145.30M
|-
| '''Subtotal Without Financing''' || $5.56B || $2.76B || $3.68B || $3.90B || $4.45B
|-
| '''Financing Cost''' || || || || || $796.31M
|-
| '''Total''' || || || || || $4.85B
|}

== Notes ==
# All estimates are for the **Year of Expenditure (2018)**.
# SAS Project Phase I **never paid for rolling stock**; therefore, the estimate is crossed out.

==Metropolitan Transportation Authority==
Public authorities acquired many of their transit systems from private companies that were in financial trouble after World War II. Because of the decline in profits and ridership, transit companies spent less money on maintenance and renovation, which resulted in their systems largely falling into disrepair by the time they were acquired by public authorities. The new transit authorities have had limited success in addressing the problem of station neglect, with a lack of funds being a major challenge. The NYC Transit Authority was established in 1953 (Homburger and Kennedy 1961), and the Metropolitan Transportation Authority (MTA) was created later in 1968 (New York Urban Transportation Group 1972). Since then, the MTA has consistently struggled with budget deficits and has been unable to establish a pricing equilibrium. It is not considered financially sustainable because of its reliance on government subsidies to balance its budget. It also lacks transparency in its financial system, and it is not held to the same standards of competency as private institutions. However, as a public institution, its value in terms of economic growth and employment through infrastructure investment must be recognized (Glaeser and Poterba 2020).
To operate sustainably and be responsive to taxpayers, the MTA needs to establish an equilibrium in funding to cover operating, maintenance, and capital improvement costs while recognizing that it may not conform to a normal pricing equilibrium (Mankiw 2018). It is crucial for project stakeholders to have confidence in the MTA’s management, whether practices are internal or external (Mayor's Committee on Management Survey 1953). The MTA has two primary roles in managing its transit projects: planning and economics, and engineering. To be competent in these practices, the MTA staff must possess the necessary knowledge and skills. Several reasons justify subsidizing public mass transit systems with taxes. First, taxation is the only practical way to collect from people who indirectly benefit from the transit system. Without taxes, the community would receive a benefit without contributing in return. Second, fares paid by riders do not fully cover the operating costs, depreciation, and capital asset investments. Therefore, it is necessary to collect part of the cost from both riders and the community through taxes (Litman 2021). Opponents may argue that fares should be high enough to cover the total costs of the transit system to eliminate the need for government subsidies (Coase 1960). This approach would discourage some people from using the system’s services and result in fewer riders. Subsidies help the MTA maintain affordable fares and allow the NYC transit system to operate at its intended capacity, as it has for over 100 years (Habib et al. 1978).
Notably, NYC’s transit system has always been subsidized, dating back to the first streets and docks built at public expense in 1684 and city-operated ferries crossing the East River. Even private investors were not allowed to increase fares to the level of pricing equilibrium. Transit facilities are generally more economical when heavily used, as reduced traffic leads to wasted capacity (Parry and Small 2009).

To achieve a funding equilibrium, the MTA must make an effort to itemize its costs and develop a plan to control them effectively. The complexity of its budget can be understood by examining three main categories: operating costs, maintenance costs, and capital investments in expanding the system (Engineering-Contracting 1910). Therefore, the MTA is responsible for managing taxpayer money in a way that balances its budget while also investing in capital growth to deliver sustainable transit projects. However, the MTA has struggled with effectively managing construction projects due to a lack of advancement in civil engineering practices and knowledge.

Theoretically, the MTA maintains a high level of accountability, but this is not consistently evident in its organizational practices (Hood 1992). As a result, while a design team may generate technical documents, the project management team of a consulting firm will not review them because it falls outside the scope of an engineering contract. In essence, the project management team satisfies the MTA’s staffing needs without requiring members to hold necessary engineering qualifications, understand engineering practices, or carry engineering liability insurance. Despite this, the MTA is the highest authority in the decision-making process and integrates the three variables of scope, cost, and schedule for capital projects. Most of the members of a project management team will not possess the necessary credentials to review engineering practices or deliverables because being a licensed engineer is not a key requirement. Rather, a certification in management is needed. This is a significant departure from reports from the early 20th century (Building the New Rapid Transit System of NYC 1915), which emphasized that the design and construction of the NYC subway system was primarily an engineering task with military-like organizational principles.
It is vital for the MTA to address this gap and prioritize engineering knowledge and practices in its project management. Currently, the project management team may move in one direction, the design team produce construction documents in another direction, and the construction team move in yet another direction independent of the other two. This lack of coordination can be seen in the SAS project, where the geotechnical design team produced design memos for the tunnels and stations that were signed off by the project management team and construction team. However, the construction documents did not consider the shallow depth of rock on top of the tunnels or the width of the tunnels in their original three-track design, which caused problems in the construction of the stations. The schedule and budget approved by the project management team confirmed that it reviewed the design, but no changes were made, which is likely because the FTA would not pay for a project redesign.

To overcome these challenges and improve overall performance, the MTA must make significant changes in its organizational structure and management practices. One critical step is to require project management staff to possess engineering credentials and knowledge. By doing so, the MTA can better align its various teams and ensure that they are working collaboratively toward a common goal. Furthermore, the MTA should invest in the professional development of its staff by providing ongoing training and resources related to civil engineering practices. This will help it keep up with advancements in the field and ensure that its projects are executed using the most up-to-date techniques and methods.

Another essential component of improving management practices is to increase transparency and accountability within the MTA. By implementing performance metrics and regularly tracking progress, it can ensure that it is effectively managing taxpayer money and delivering results in line with its objectives. Increased transparency can help build public trust and demonstrate that the MTA is committed to providing quality service while responsibly managing its resources. Finally, the MTA should focus on forging stronger partnerships with external stakeholders such as local governments, businesses, and community organizations.
Conclusion

The early 20th century witnessed the evolution of civil engineering into an established profession with a comprehensive knowledge base. Civil engineers contributed to the construction of massive projects such as the NYC subway system, which required technical and economic expertise. However, civil engineering faces vulnerabilities because of the absence of a well-rounded education system that can prepare engineering students for the complexities of future projects and the disconnect between academia and engineering practices. As civil engineering knowledge continues to develop, the profession must address these vulnerabilities and adapt to the changing demands of the industry.

The SAS project faced multiple design challenges and construction decisions that resulted in considerable cost overruns. The assumptions made by the project management and design teams regarding geotechnical issues, construction contract packaging, real estate acquisition, and easement were unable to handle the complexity of the SAS project. This resulted in unexpected costs and delays, as evidenced by the significant budget increases. To avoid similar issues, it is crucial to examine the logic and lessons learned from the project and apply these insights to future endeavors. The lack of well-defined best practices for project management played a role in these issues. To avoid similar problems in future transit projects, the ASCE should establish comprehensive best practices for project management, design, and construction encompassing consistent engineering principles, legal clarity, and acceptable performance levels for interpretation under the NEPA. By adopting these best practices, transit agencies and engineering firms can collaborate more effectively to complete crucial infrastructure projects on schedule and within budget. The SAS project serves as a case study for the importance of thorough planning, effective communication, and adaptability in the face of complex challenges. The lessons learned from this project can be applied to the better planning, design, and execution of future infrastructure projects, which will ultimately benefit both the industry and the public.
The MTA is a vital public institution responsible for providing essential transit services to NYC citizens. However, it faces significant challenges related to financial sustainability and management practices. By prioritizing engineering knowledge and practices, increasing transparency and accountability, and fostering stronger partnerships with external stakeholders, the MTA can transform itself into a more efficient, cost-effective, and responsive organization. These changes will ultimately lead to better transit services for the public and a more sustainable future. As the MTA evolves and adapts to these new management practices, it can serve as a model for other public institutions looking to improve their own operations and better serve their constituents.

==Data Availability Statement==

All data used in this study is publicly accessible and can be obtained through the provided references. For the PMOC reports, readers can access the FTA’s website at https://www.transit.dot.gov/foia/metropolitan-transportation-authority-second-avenue-subway. The 2013 “The Politics of Large Infrastructure Investment Decision-Making: The Case of the Second Avenue Subway Case Study” report can be found at https://rosap.ntl.bts.gov/view/dot/27119.

== References ==

* Abbott, A. (2014). ''The system of professions: An essay on the division of expert labor''. University of Chicago Press, Chicago, USA.
* Barzelay, M. (2001). ''The new public management: Improving research and policy dialogue''. University of California Press, Berkeley, CA.
* Civil War Railroad Report. (1865). ''Report on the construction of railroads during the Civil War''. War Department Records, USA.
* Coase, R. H. (1960). "The problem of social cost." ''J. Law Econ.'', 3, 1–44.
* Concord Canal Report. (1825). ''Report on the Concord Canal''. Massachusetts State Records, USA. 7, 6.
* Council on Environmental Quality. (2014). ''A citizen’s guide to the NEPA: Having your voice heard''. Council on Environmental Quality 2007, Washington, DC. [https://ceq.doe.gov/docs/get-involved/Citizens_Guide_Dec07.pdf Link].
* Department of Energy. (1970). "National Environmental Policy Act of 1970." ''Public Law'', 91, 11.
* Durand, W. F. (1929). ''Robert Henry Thurston: A biography, the record of a life of achievement as engineer, educator, and author''. The American Society of Mechanical Engineers, New York.
* Dzur, A. W. (2008). ''Democratic professionalism: Citizen participation and the reconstruction of professional ethics, identity, and practice''. Pennsylvania State University Press, University Park, PA.
* Engineering-Contracting. [https://www.google.com/books/edition/_/HAHQQxqfkRMC?hl=en&sa=X&ved=2ahUKEwjgveWIwv_-AhXaEVkFHTOmCfkQre8FegQIARAV&bshm=bshwcqp/1 Link].
* Eschenasy, P.E., F.SEI Bharat Gami, R.A., Gus Sirakis, P.E. (2017). "Special topics in construction safety course number SW0317." Presentation at the Build Safe/Live Safe Conference, NYC Department of Buildings, New York.
* Filion, P., & Hammond, K. (2003). "Neighbourhood land use and performance: The evolution of neighbourhood morphology over the 20th century." ''Environ. Plann. B Plann. Des.'', 30(2), 271–296.
* Fitch, R. (1999). ''The assassination of New York''. Verso, London, UK.
* Fulcher, B., Menge, S., & Grillo, J. (2013). "New York City—Second Avenue Subway: MTA’s 72nd Street Station and tunnels project construction of a large span station cavern, running tunnels, cross-over and turn-out caverns, shafts and entrances." ''Proc., Rapid Excavation Tunneling Conf 2013 Proceedings''. Society for Mining, Metallurgy, and Exploration.
* Glaeser, E. L., & Poterba, J. M. (2020). "Introduction to economic analysis and infrastructure investment." ''Economic Analysis and Infrastructure Investment''. University of Chicago Press, Chicago. [https://www.nber.org/books-and-chapters/economic-analysis-and-infrastructure-investment/introduction-economic-analysis-and-infrastructure-investment Link].
* Glaeser, E. L., & Poterba, J. M. (2021). ''Economic analysis and infrastructure investment'' (Vol. 28215). National Bureau of Economic Research, Inc., NY.
* Gordon, T., & Schleicher, D. (2015). "High costs may explain crumbling support for US infrastructure." ''Real Clear Policy''.
* Gotshall, W.C. (1903). ''Notes on electric railway, economics and preliminary engineering''. McGraw Publication Company, New York.
* Habib, P., Linzer, E., Jones, C., Nason, R., & Ablamsky, R.A. (1978). ''Fare policy and structure''. Polytechnic Institute of New York, Urban Transportation Research Center, New York.
* Hall, P. (2002). ''Urban and regional planning''. Routledge, London, UK.
* Harris, F., & McCaffer, R. (2013). ''Modern construction management''. Wiley-Blackwell, Chichester, UK.
* Homburger, W. S., & Kennedy, N. (1961). ''The organization of metropolitan transit agencies''. University of California, USA.
* Hood, C. (1992). ''The landscapes of modernity: Essays on New York City''. Russell Sage Foundation, Baltimore. [http://academic.brooklyn.cuny.edu/history/burrows/NYC/Documents/hood.htm Link].
* Hood, C. (2004). ''Miles: The building of the subways and how they transformed New York''. Johns Hopkins University Press, Baltimore, MD.
* Kates, W. R., Parris, T. M., & Leiserowitz, A. A. (2005). "What is sustainable development? Goals, indicators, values, and practice." ''Environ. Sci. Policy Sustain. Dev.'', 47(3), 8–21. [https://doi.org/10.1080/00139157.2005.10524444 Link].
* Kaufman, H. (1956). "Emerging conflicts in the doctrines of public administration." ''Am. Polit. Sci. Rev.'', 50(4), 1057–1073. [https://doi.org/10.2307/1951335 Link].
* Kerzner, H. (2009). ''Project management: A systems approach to planning, scheduling, and controlling''. John Wiley & Sons, Hoboken, NJ.
* Kirkwood, N. (2012). ''The end of the line: A history of railways in Great Britain''. The History Press, Stroud, UK.
* Koppenjan, J. F. M., & Enserink, B. (2009). "Public–private partnerships in urban infrastructures: Reconciling private sector participation and sustainability." ''Public Admin. Rev.'', 69(2), 284.
* Labuschagne, C., & Brent, A. C. (2004). ''Sustainable project life cycle management: Aligning project management methodologies with the principles of sustainable development''. PMSA, Johannesburg, South Africa. [http://hdl.handle.net/2263/4856 Link].
* Levinson, D. M. (2003). ''Financing transportation networks''. Edward Elgar Publishing, Cheltenham, UK.
* Lewis, P. (2004). ''Urban planning and the American family''. Temple University Press, Philadelphia, PA.
* Mankiw, N. G. (2018). ''Principles of economics''. 8th ed., Cengage Learning, Boston, MA.
* PMOC reports. (2013). [https://www.transit.dot.gov/foia/metropolitan-transportation-authority-second-avenue-subway Link].
* Real Estate Record and Builders’ Guide. (1904). ''Real estate record and builders guide''. LXXIV, 718. [https://www.google.com/books/edition/_/ZqdRAAAAYAAJ?hl=en&gbpv=0&bshm=bshwcqp/1 Link].
* Rosenthal, B. M., & Fitzsimmons, E. G. (2017). "Why does subway construction cost so much? Congress wants to find out." ''The New York Times''. [https://www.nytimes.com/2018/03/28/nyregion/new-york-subway-construction-costs-congress.html Link].
* Subway. (1920). "Cost $350,000,000." ''The New York Times''. [https://timesmachine.nytimes.com/timesmachine/1920/12/05/102965570.html?pageNumber=117 Link].
* The Politics of Large Infrastructure Investment Decision-Making: The Case of the Second Avenue Subway Case Study. Report No. 49111-16-23. [https://rosap.ntl.bts.gov/view/dot/27119 Link].