Civil Engineering Projects
This page is under construction ...
See also Project Execution, Project Development, Project Definition, Project Life Cycle and Phase Models, Project Delivery Methods.
See also Program Management in Civil Engineering, Project Management ...
Basic considerations
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 civil engineering programs, projects, and portfolios of projects.[1]
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 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 onto-logic knowledge model for civil-engineering (CE) projects requires:
- Discipline-specific foundational outcomes
- Discipline-specific technical outcomes
- Project foundational outcomes
- Project-specific technical 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.
Practice frameworks for Civil Engineering Projects
PMIBoK
PMI defines a project as:
- “…a temporary endeavor undertaken to create a unique product, service, or result.”[2]
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.[3]
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.”[4]
Commentary:
- None – this definition is compatible with the civil-engineering perspective, though still abstract.
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.”[5]
- Civil engineering will continue to focus on “the definition, selection, and implementation of projects.”[6]
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:
- medical devices using 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.
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.”[7]
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.)
Legislative framework for Civil Engineering Projects
(Under construction.)
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.”[8]
Beneficial Outcomes
(Under construction.)
See also
- 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
- <a href="#cite_ref-1">↑</a>
- <a href="#cite_ref-3">↑</a> 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.
- <a href="#cite_ref-8">↑</a> Internal test note in original RiskWiki draft.
References
- <a href="#cite_ref-2">↑</a> Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed., 2013, Glossary, p. 552.
- <a href="#cite_ref-4">↑</a> International Organization for Standardization (ISO), ISO/FDIS 9000:2005, Sec. 3.4 “Terms relating to process and product”, p. 11.
- <a href="#cite_ref-5">↑</a> ASCE, The Vision for Civil Engineering in 2025, 2006, p. 3.
- <a href="#cite_ref-6">↑</a> ASCE, The Vision for Civil Engineering in 2025, 2006, p. 59.
- <a href="#cite_ref-7">↑</a> Project Management Practices, Engineering Support and Requirements Generation, Analysis, and Use, Sec. 2.0 Requirements Generation (Rev. E, June 2003).
- ↑ Internal note in original RiskWiki draft.
- ↑ Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed., 2013, Glossary, p. 552.
- ↑ 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.
- ↑ 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).
- ↑ Definition derived from OMB Circular A-109 and Kerzner (2013), as noted above.