return to model

2.1 Project Phases and the Project Life Cycle

Because projects are unique undertaking, they involve a degree of uncertainty. Organizations performing projects will usually divide each project into several project phases to improve management control and provide for links to the ongoing operations of the performing organization. Collectively, the project phases are known as the project life cycle.

2.1.1 Characteristics of Project Phases
Each project phase is marked by complation of one or more deliverables. A deliverable is a tangible, verifiable work product such as a feasibility atudy, a detail design, or a working prototype. The deliverables, and hence the phases, are part of a generally sequential logic designed to ensure proper definition of the product of the project.
  The conclusion of a project phase is generally marked by a review of both key deliverables and project performance to date, to a) determine if the project should continue into its next phase and b) detect and correct errors cost effectively. These phase-end reviews are often called phase exits, stage gates, or kill points.
  Each project phase normally includes a set of defined deliverables designed to establish the desired level of management control. The majority of these items are related to the primary phase deliverable, and the phases typically take their names from these items: requirements, design, build, text, startup, turnover, and others as appropriate. Several representative project life cycles are described in Section 2.1.3.

2.1.2 Characteristics of the Project Life Cycle
The project life cycle serves to define the beginning and the end of a project. For example, when an organization identifies an opportunity to which it would like to respond, it will often authorize a needs assessment and/or a feasibility study to decide if it should undertake a project. The project life-cycle definition will determine whether the feasibility study is treated as the first project phase or as a separate, standalone project.
  The project life-cycle definition will also determine which transitional actions at the beginning and the end of the project are included and which are not. In this manner, the project life-cycle definition can be used to link the project to the ongoing operations of the performing organization.
  The phase sequence defined by most project life cycles generally involves some form of technology transfer or hand off such as requirements to design, construction to operations, or design to manufacturing. Deliverables from the preceding phase are usually approved before work starts on the next phase. However, a subsequent phase is sometimes begun prior to approval of the previous phase deliverables when the risks involved are deemed acceptable. This practice of overlapping phases is often called fast tracking.
  Project life cycles generally define:

   What technical work should be done in each phase (e.g., is the work of the architect part of the definition phase or part of the execution phase?).

   Who should be involved in each phase (e.g., implementers who need to be involved with requirements and design).

Project life-cycle descriptions may be very general or very detailed. Highly detailed descriptions may have numerous forms, charts, and checklists to provide structure and consistency. Such detailed approaches are often called project management methodologies.
Most project life-cycle descriptions share a number of common characteristics:

   Cost and staffing levels are low at the start, higher towards the end, and drop rapidly as the project draws to a conclusion. This pattern is illustrated in Figure 2-1.

   The probability of successfully completing the project is lowest, and hence risk and uncertainty are highest, at the start of the project. The probability of successful completion generally gets progressively higher as the project continues.

   The ability of the stakeholders to influence the final characteristics of the project's product and the final cost of the project is highest at the start and gets progressively lower as the project continues. A major contributor to this phenomenon is that the cost of changes and error correction generally increases as the project continues.

  Care should be taken to distinguish the project life cycle from the product life cycle. For example, a project undertaken to bring a new desktop computer to market is but one phase or stage of the product life cycle.
  Although many project life cycles have similar phase names with similar deliverables required, few are identical. Most have four or five phases, but some have nine or more. Even within a single application area there can be significant variations—one organization's software development life cycle may have a single design phase while another's has separate phases for functional and detail design.
  Subprojects within projects may also have distinct project life cycles. For example, an architectural firm hired to design a new office building is first involved in the owner's definition phase when doing the design and in the owner's implementation phase when supporting the construction effort. The architect's design project, however, will have its own series of phases from conceptual development through definition and implementation to closure. The architect may even treat designing the facility and supporting the construction as separate projects with their own distinct phases.

2.1.3 Representative Project Life Cycles
The following project life cycles have been chosen to illustrate the diversity of approaches in use. The examples shown are typical; they are neither recommended nor preferred. In each case, the phase names and major deliverables are those described by the author for each of the figures.
  Defense acquisition. The United States Department of Defense Instruction 5000.2, in Final Coordination Draft, April 2000, describes a series of acquisition milestones and phases as illustrated in Figure 2-2.

   Concept and technology development—paper studies of alternative concepts for meeting a mission need; development of subsystems/components and concept/technology demonstration of new system concepts. Ends with selection of a system architecture and a mature technology to be used.

   System development and demonstration—system integration; risk reduction; demonstration of engineering development models; development and early operational test and evaluation. Ends with system demonstration in an operational environment.

   Production and deployment—low rate initial production (LRIP); complete development of manufacturing capability; phase overlaps with ongoing operations and support.

   Support—this phase is part of the product life cycle, but is really ongoing management. Various projects may be conducted during this phase to improve capability, correct defects, etc.

  Construction. Adapted from Morris (1), describes a construction project life cycle, as illustrated in Figure 2-3:

   Feasibility—project formulation, feasibility studies, and strategy design and approval. A go/no-go decision is made at the end of this phase.

   Planning and Design—base design, cost and schedule, contract terms and conditions, and detailed planning. Major contracts are let at the end of this phase.

   Construction—manufacturing, delivery, civil works, installation, and testing. The facility is substantially complete at the end of this phase.

   Turnover and startup—final testing and maintenance. The facility is in full operation at the end of this phase.

  Pharmaceuticals. Murphy (2) describes a project life cycle for pharmaceutical new product development in the United States as illustrated in Figure 2-4:

   Discovery and screening—includes basic and applied research to identify candidates for preclinical testing.

   Preclinical development—includes laboratory and animal testing to determine safety and efficacy as well as preparation and filing of an Investigational New Drug (IND) application.

   Registration(s) workup—includes Clinical Phase I, II, and III tests as well as preparation and filing of a New Drug Application (NDA).

   Postsubmission activity—includes additional work as required to support Food and Drug Administration review of the NDA.

  Software development. There are a number of software life-cycle models in use such as the waterfall model. Muench, et al. (3) describe a spiral model for software development with four cycles and four quadrants as illustrated in Figure 2-5:

   Proof-of-concept cycle—capture business requirements, define goals for proof of concept, produce conceptual system design, design and construct the proof of concept, produce acceptance test plans, conduct risk analysis and make recommendations.

   First-build cycle—derive system requirements, define goals for first build, produce logical system design, design and construct the first build, produce system test plans, evaluate the first build and make recommendations.

   Second-build cycle—derive subsystem requirements, define goals for second build, produce physical design, construct the second build, produce system test plans, evaluate the second build and make recommendations.

   Final cycle—complete unit requirements, final design, construct final build, perform unit, subsystem, system, and acceptance tests.