A paper presented to the Project Management Symposium on PM: Project Manager Role Evolution, Rome, Italy, 2004.

Updated 7/3/04

"PMI" and "PMBOK" are the registered trademarks of the Project Management Institute.
Published here August 2004.

PART 1 | Introduction | Areas of Project Management Application
Project-Driven and Project-Dependent Organizations
Project Life Cycle Models| Specific Life Cycle Model Examples
Project Management Planning and Control Practices, Systems, and Tools
Managing Risk in Programs and Projects | PART 3

Project Life Cycle Models

A number of commonly used models, consisting of a number of phases or stages and related decision points, have been developed and are currently in use to portray project life cycles within each project category and sub-category shown previously in Table 1. Such models provide a major starting point for applying systems thinking to managing projects. The models within each category and/or subcategory will show considerable similarities, but in most cases there will be significant differences in the life cycle models from one category/sub-category to the next.

Purposes of Project Life Cycle Process Models

The purposes of designing and documenting the overall project life cycle process for each project category are to:

  • Enable all persons concerned with creating, planning and executing projects to understand the process to be followed during the life of the project.
  • Capture the best experience within the organization so that the life cycle process can be improved continually and duplicated on future projects.
  • Enable all the project roles and responsibilities, and the project planning, estimating, scheduling, monitoring and control methods and tools, to be appropriately related to the overall project life cycle management process.

Unless a well-documented, understandable picture of the life cycle process - the model - for each project category/sub-category exists it is difficult (if not impossible) to achieve the full benefits of modern, systematic project management.

Life Cycle Phases and Decision Points

There is general agreement that the four broad, generic project phases are (common alternative terms are shown in parentheses):

  • Concept (initiation, identification, selection.)
  • Definition (feasibility, development, demonstration, design prototype, quantification.)
  • Execution (implementation, realization, production and deployment, design/construct/commission, installation and test.)
  • Closeout (termination, including post-completion evaluation.)

However, these phases are so broad and the titles so generic that they are of little value in documenting the life cycle process so that it can be widely understood, reproduced, and continually improved. What is needed is the specific definition of perhaps five to ten basic phases for each project category and subcategory, usually with several sub-phases defined within each of the basic phases.

In designing and documenting a life cycle process (or model) for a given project category there are three parameters to work with:

  1. The number of basic phases and the number of sub-phases within each, together with the short title and full definition of each of these.
  2. Which of the basic phases and sub-phases will be strictly sequential, which will overlap, and for those that overlap how much overlap can be tolerated; whether any phases are repeated; and how they are inter-related in a process flow chart (continuous flow, spiral, or other graphic shape.)
  3. The number and placement of decision points (approval to proceed, revise project objectives or scope, kill/terminate, put on hold, repeat a previous phase or sub-phase, and others) in the process.

Identification of Products or Results (Deliverables) to be Produced in Each Phase

It is desirable (some would say mandatory) to identify the products or results to be produced (documents and physical products) during each of the phases and sub-phases:

  • Documents related to the project include all those required for the subsequent phases, e.g. revised, updated, and/or elaborated statements of project objectives and scope, plans, schedules, resource and cost estimates, evaluation of risks, earned value and other cost reports, work orders, contracts, project release authorizations, and other project management documentation.
  • Documents related to the product or results include specifications, drawings, descriptions, test procedures, process and other designs, flow charts, product cost estimates, test and other reports, product change orders, and other documentation closely related to the products or results of the project.
  • Physical products or results include intermediate or final mock-ups, scale or full size models, prototypes, test articles, tools and tooling, items of equipment, facilities, consumable materials and supplies, and other physical objects. In many projects the final end results will be one or more documents (including CDs, which are electronic documents) that embody a system or describe a service to be implemented, provided, or sold, but do not include physical objects. The results of an information system project may be embodied on a CD-ROM, but the system itself is usable only of course when invisibly stored in the memory of a set of computer hardware.
    • The product development process for the end result to be produced by the project will of course have a direct impact on the project life cycle model to be used, and must be integrated into that life cycle model.

Defining the Decision Points

Key decision points (events or milestones) occur at the start and end of each phase or sub-phase. They may also occur within any of the life cycle phases. The decisions typically authorize the project manager and team to:

  • Proceed with the remaining work in the current phase.
  • Start work on the ensuing phase.
  • Re-plan and re-start a phase or sub-phase already completed if satisfactory results have not been achieved.
  • Revise the project objectives, plans and schedules when major changes in scope are required.
  • Terminate the project if the conclusion has been reached that its objectives cannot be achieved successfully or if the risks have been determined to be too great.
  • Place the project on hold pending availability of funds, new technology, or some other external event.

Documenting a Project Life Cycle Management Process: For each project category or subcategory we must document and describe the project life cycle process to:

  • Select the life cycle model to use, name the phases and sub-phases, determine their interrelationships, and identify the key decision points.
  • Describe the methods, procedures, forms, documents, tools, systems, and other practices for authorizing, planning, analyzing and mitigating risks, budgeting, scheduling, monitoring, and controlling all projects within the category.
  • Specify the documents and related levels of approval authority for initiating and authorizing new projects and major changes to authorized projects.
  • Identify the key project roles and define their responsibilities and authority.
  • Identify and describe the major deliverables to be produced in each phase and sub-phase.
  • Specify the procedures for escalating the inevitable conflicts (competition for key resources, priorities between projects, and others) and unresolved issues to the appropriate level for their prompt resolution.

The detailed project management project process for a given project category must also include provisions for handling projects of different sizes, complexities, risks, durations, sources of funding, and serving different customers.

Project-Driven and Project-Dependent Organizations  Project-Driven and Project-Dependent Organizations

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page