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:
- 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.
- 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.)
- 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
