View source for Project Life Cycle and Phase Models

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