LECTURE 5

PROJECT LIFE CYCLES

BROAD CONTENTS

Life cycle phases of a Product

Life cycle phases of a System
System Costs
Cost Benefit Analysis
Characteristics of Project Life Cycle
Project Management Office
Project Management Officer (PMO)
Difference between Project Manager and Project Management Officer
Some Examples of Project Life Cycle

5.1 LIFE CYCLE PHASES OF A PRODUCT:

Every program, project, or product has certain phases of development. A

clear understanding of these phases permits managers and executives to
better control total corporate resources in the achievement of desired
goals. The phases of development are known as life-cycle phases.
However, the breakdown and terminology of these phases differ,
depending on whether we are discussing products or projects.

During the past few years, there has been at least partial agreement about
the life cycle phases of a product. They include:

• Research and development

• Market introduction
• Growth
• Maturity
• Deterioration
• Death

Today, there is no agreement among industries, or even companies within

the same industry, about the life cycle phases of a project. This is
understandable because of the complex nature and diversity of projects.
 Figure 5.1: Maturity Path

5.2 LIFE CYCLE PHASES OF A SYSTEM:

The theoretical definitions of the life cycle phases of a system can be

applied to a project. These phases include:

• Conceptual
• Planning
• Testing
• Implementation
• Closure

5.2.1 Conceptual Phase:

The first phase, the conceptual phase, includes the preliminary
evaluation of an idea. Most important in this phase is a preliminary
analysis of risk and the resulting impact on the time, cost, and
performance requirements, together with the potential impact on
company resources. The conceptual phase also includes a "first cut"
at the feasibility of the effort.
5.2.2 Planning Phase:
The second phase is the planning phase. It is mainly a refinement of
the elements described under the conceptual phase. The planning
phase requires a firm identification of the resources to be required
together with the establishment of realistic time, cost, and
performance parameters. This phase also includes the initial
preparation of all documentation necessary to support the system.
For a project based on competitive bidding, the conceptual phase
would include the decision of whether to bid, and the planning
phase would include the development of the total bid package (i.e.,
time, schedule, cost, and performance).

Figure 5.2: System Costs

5.2.2.1 System Costs:

Because of the amount of estimating involved, analyzing

system costs during the conceptual and planning phases is
not an easy task. As shown in Figure 5.2, most project or
system costs can be broken down into operating (recurring)
and implementation (nonrecurring) categories. The
implementation costs include one-time expenses such as
construction of a new facility, purchasing computer
hardware, or detailed planning. Operating costs, on the
other hand, include recurring expenses such as manpower.
The operating costs may be reduced as shown in Figure 5.2,
if personnel perform at a higher position on the learning
curve. The identification of a learning curve position is
vitally important during the planning phase when firm cost
positions must be established.
 Of course, it is not always possible to know what individuals
will be available or how soon they can perform at a higher
learning curve position.

Figure 5.3: Cost Benefit Analysis

5.2.2.2 Cost Benefit Analysis:

Once the approximate total cost of the project is determined,

a cost-benefit analysis should be conducted (see Figure 5.3)
to determine if the estimated value of the information
obtained from the system exceeds the cost of obtaining the
information. This analysis is often included as part of a
feasibility study.

There are several situations, such as in competitive bidding,

where the feasibility study is actually the conceptual and
definition phases. Because of the costs that can be incurred
during these two phases, top-management approval is
almost always necessary before the initiation of such a
feasibility study.
 Figure 5.4: A Stream of Projects

5.2.3 Testing Phase:

The third phase— testing— is predominantly a testing and final
standardization effort so that operations can begin. Almost all
documentation must be completed in this phase.

5.2.4 Implementation Phase:

The fourth phase is the implementation phase, which integrates the
project's product or services into the existing organization. If the
project was developed for establishment of a marketable product,
then this phase could include the product life cycle phases of
market introduction, growth, maturity, and a portion of
deterioration.

5.2.5 Closure Phase:

The final phase is closure and includes the reallocation of resources.
The question to be answered is, "Where the resources should be
reassigned?" Consider a company that sells products on the open
consumer market. As one product begins, the deterioration and
death phases of its life cycle (i.e., the divestment phase of a system),
then new products or projects must be established. Such a company
would, therefore, require a continuous stream of projects as a
necessity for survival, as shown in Figure 5.4. As projects A and B
begin their decline, new efforts (project C) must be developed for
resource reallocation. In the ideal situation these new projects will
be established at such a rate that total revenue will increase and
company growth will be clearly visible.
 The closure phase evaluates the efforts on the total system and
serves as input to the conceptual phases for new projects and
systems. This final phase also has an impact on other ongoing
projects with regard to priority identification.

Thus, so far no attempt has been made to identify the size of a

project or system. Large projects generally require full-time staffs,
whereas small projects, although they undergo the same system life
cycle phases, may require only part-time people. This implies that
an individual can be responsible for multiple projects, possibly
with each project existing in a different life cycle phase.

The following questions must be considered in multi-project

management:

1. Are the project objectives the same?

• For the good of the project
• For the good of the company

2. Is there a distinction between large and small projects?

3. How do we handle conflicting priorities?

• Critical versus critical projects
• Critical versus non-critical projects
• Non-critical versus non-critical projects

5.2.6 Explanation of Various Life Cycle Phases:

Later topics discuss methods of resolving conflicts and establishing

priorities.

The phases of a project and those of a product are compared in

Figure 5.5. Notice that the life cycle phases of a product generally
do not overlap, whereas the phases of a project can and often do
overlap.

Table 5.1 identifies the various life cycle phases that are commonly
used. Even in mature project management industries such as
construction, one could survey ten different construction
companies and find ten different definitions for the life cycle
phases.
 Table 5.1: Life Cycle Phase Definitions

The life cycle phases for computer programming, as listed in Table

above, are also shown in Figure 5.5 which illustrates how
manpower resources can build up and decline during a project. In
Figure 5.5, PMO stands for the present method of operations, and
PMO' will be the "new" present method of operations after
conversion. This life cycle would probably be representative of a
twelve-month activity.

Figure 5.5: Definition of a Project Life Cycle

Most executives prefer short data processing life cycles because

computer technology changes at a very rapid rate. An executive of
a major utility commented that his company was having trouble
determining how to terminate a computer programming project to
improve customer service because by the time a package is ready
for full implementation, an updated version appears on the scene.
Should the original project be canceled and a new project begun?
The solution appears to lie in establishing short data processing
project life cycle phases, perhaps through segmented
implementation. In any case, we can conclude that top
management is responsible for the periodic review of major
projects. This should be accomplished, at a minimum, at the
completion of each life cycle phase.

More and more companies are preparing procedural manuals for

project management and for structuring work using life cycle
phases. There are several reasons for this trend. These are as
follows:

• Clear description of the work to be accomplished in each phase

may be possible.

• Pricing and estimating may be easier if well-structured work

definitions exist.

• There exists key decision points at the end of each life cycle
phase so that incremental funding is possible.

Reader should be aware that not all projects can be simply

transposed into lifecycle phases (e.g., Research and Development).
In such a case it might be possible (even in the same company) for
different definitions of life-cycle phases to exist because of schedule
length, complexity, or just the difficulty of managing the phases.
 Figure 5.6: System/Product Life Cycles

5.3 CHARACTERISTICS OF PROJECT LIFE CYCLE:

• Project life cycle defines phases that connect beginning and end of the
project. After each phase deliverables are reviewed for the
completeness in time, accuracy according to defined objectives and
their final approval (approval for acceptance) before moving to the
next phase.

• As shown in the diagrams in the beginning, phases can be overlapped

to save time and to have fast tracking on the life cycle. This technique
is used to compress the whole schedule (if required resources are
available or manageable)

• There is no way to define Project Life Cycle ideally. Because of this

every project management team can define its own way to work on the
project. They can use best common practices and can learn new ways
of dealing projects by their experiences in detail or in general. Only
three phases are always certain to be performed; conceptualization,
intermediate phase(s), and closure.

• Generally phases are defined in sequential order by technical

information officer.
 • Cost and staffing level is defined for every single phase.

• Project may have sub-project(s) and sub-projects may have their own
project life cycle.

• In the beginning of the project, level of uncertainty and risk is always

high.

• The typical project life cycle – initiating, implementing and closing –

has critical decision points where the project may continue, be
changed, or be abandoned.

• There are many points within the project life cycle where Community of
Professionals (CoPs) may provide support and guidance. For example,
initiating the project involves such activities as identifying the project
team members, defining the scope and business objectives of the
project and identifying key stakeholders.

• During project close, reassignment and intelligent preservation of

resources, knowledge projects (i.e. deliverables), and sharing lessons
learned are facilitated.

5.4 PROJECT MANAGEMENT OFFICE:

The Project Management Office sets project standards and oversees the
organization’s portfolio of projects. This allows the organization to
evaluate the use of resources across all projects and resolve conflicts that
affect project timelines. The Project Management Office is also a very good
place to examine how communities are linked across projects. Using the
communities as the linkage point for knowledge transfer is far more
efficient for the following several reasons:

• In communities, the evaluation of knowledge is generally done by a

broader range of people, ensuring that the ideas are more completely
vetted.

• Communities generally exist outside the project framework and trust

is already established.

• They can be used as opposed to setting up more formal structures and

methods to get the required information transferred to the project.
 • In communities, knowledge is transferred from expert to recipient.
This includes tacit knowledge transfer as well as explicit knowledge
transfer. This is a much more efficient transfer mechanism than is
normally used. Generally, documents would be transferred from
project to project with minimal expert knowledge available to add
value.

• Community transfer shares the knowledge broadly, strengthening the

entire organization for future projects.

• As mentioned earlier, Project Management Office and top

management are responsible for the periodic review of major projects.
This should be accomplished, at a minimum, at the completion of each
life cycle phase.

5.5 PROJECT MANAGEMENT OFFICER (PMO):

Project Management Officer (PMO) centralizes and coordinates

management of project under his domain, and oversees management of
project and product (system/program) both. Project Management Officer
may not be directly related to the project at spot. He/she focuses on
coordination planning, prioritization of all resources and deliverables of
projects and sub projects. It is the responsibility of Project Management
Officer to keep top management and clients/parents organization
connected and informed about all projects running or product life cycle.
He/she is involved in selection, management and re-deployment of
shared projects as much as authorized.
Project Management Officer is generally responsible for:

• Providing monitoring platform for Project Manager.

• Identifying the Project Management Methodology and best practices

for specific project.

• Clearing house, i.e. defining and refining project policies, procedures,

templates and shared documents.

• Configuration management for all projects under work.

• For developing and keeping repository and risk management for

projects.
 • Developing Project Management Office for operation and maintaining
tools for project management. Normally it includes Enterprise Wide
Project Management Software creation and installation.

• Management and coordination and monitoring of communications

across the projects, project timelines and budget, quality standards.

• Project Management Officer may be having authority to terminate

project anytime when he gets it not feasible anymore.

5.6 DIFFERENCE BETWEEN PROJECT MANAGER AND PROJECT

MANAGEMENT OFFICER:

1. Both have different objectives - driven by different requirements,

aligned with strategic needs of organization.

2. Project Manager is responsible for delivering specific project objectives

within project constraints, while Project Management Officer is
responsible for organizational structure specific mandates having
much vast perspective.

3. Project Manager focuses on project objectives, while Project

Management Officer focuses on major programs, scope and changes
required and authenticated. Project Management Officer considers all
potential opportunities to have business goals achieved.

4. Project Manager is constrained with assigned resources for specific

project to meet its full objective. On the other hand, Project
Management Officer is supposed to optimize the use of shared
organizational resources across all projects overall.

5. Project Manager manages scope, schedule, cost, and quality of

product, while the Project Management Officer manages overall risk,
opportunities, interdependencies and links among different projects.

6. Project Manager reports on project progress/project specific

information to the top management, while Project Management Officer
provides consolidated reporting/enterprise view of project or all the
running projects.
5.7 SOME EXAMPLES OF PROJECT LIFE CYCLE:

There are many variations on the theme of the project phases, influenced
by the project’s scope of work. The project phase selected in the examples
here are arbitrary and serve only to illustrate the technique for different
types of projects. The main features to look for are the key issues, key
activities, limiting factors, decision and hold points in each phase.

The project life cycle is conveniently represented by a bar chart which

clearly indicates the duration of each phase and its overlap (if any) with
the other phases.

5.7.1 House Project:

The construction of a house provides a project many of us have

personally experienced. Consider here the following simple sub-
division into four phases.

The level of effort follows the typical life cycle profile by increasing
to a maximum during the building phase before declining during
the interior phase.

Figure 5.7: Project Life Cycle: House Project

5.7.2 Computer installation:

With the improved cost effectiveness of computer facilities most

companies will experience a computer installation project sooner or
later.

Note that the training phase overlaps with both system selection
and the implementation phase.

Figure 5.8: Project Life Cycle: Computer Installation

5.7.3 Engineering Project:

An engineering type project is a popular example to illustrate the

project phases. Note here that all phases overlap which could
indicate a fast tracking.
 Figure 5.9: Project Life Cycle: Engineering Project

5.7.4 Nuclear Power Station Project:

This project may well span 50 years with the people involved in the
initial phases being retired long before the final phases.

The interesting point here is that the environmental constraints

have changed significantly over the fifty years between the design
phase and the decommissioning phase.

Figure 5.10: Project Life Cycle: Nuclear Power Station Project