|
|
| Line 1: |
Line 1: |
| '''<big>This page is under construction ...</big>'''
| | = 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. |
|
| |
|
| ''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]].''
| | == Definition of a project == |
| | A widely used definition is: |
|
| |
|
| ''See also [[Program_Management_in_Civil_Engineering|Program Management in Civil Engineering]], [[Project_management|Project Management]] ...''
| | ;Project |
| | : a temporary endeavor undertaken to create a unique product, service, or result. |
|
| |
|
| == Basic considerations ==
| | Civil engineering projects are typically constrained by scope, time, resources, and performance requirements, and are managed through planning, execution, and control. |
|
| |
|
| [[#top|Top of current page]]
| | == 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. |
|
| |
|
| == Semantic, Epistemic and Logical frameworks == | | == Typical project structure == |
| | | * front-end development (definition and feasibility), |
| 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.
| | * design (concept to final), |
| | | * procurement and contracting, |
| === Semantic framework ===
| | * construction and commissioning, |
| | | * handover and closeout, |
| * 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> | | * operations interface (performance, maintenance, renewal). |
| | |
| === 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 == | | == See also == |
| | * [[Program Management in Civil Engineering]] |
| | * [[Project Life Cycle and Phase Models]] |
| | * [[Requirements]] |
| | * [[Uncertainty and Risk in Civil Engineering Practice]] |
|
| |
|
| * [[wikipedia:Project|Project]] (Wikipedia)
| | [[Category:Civil Engineering]] |
| | | [[Category:Project Management]] |
| == 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]] | |