Managing the Project Life Cycle

The management of project life cycles requires special treatment. In general, manage- ment must be adaptable, both to changes induced by the life cycle of each individual project as well as to changes induced by the life cycles of multiple, concurrent proj- ects. Unlike nonproject repetitive operations where activities tend to be stable, the

Figure 4-1

Level of activity during the project life cycle.

project life cycle puts resources, costs, and schedules in a constant state of change. To respond, management must be flexible. Little that is done in a project can be consid- ered repetitive or even routine. Work schedules, budgets, and tasks must be tailored to fit the stages of the project life cycle.

All life cycles contain an element of uncertainty. Unforeseen obstacles, which are virtually inevitable, can cause missed deadlines, cost overruns, and poor system per- formance. Management must anticipate problems and uncertainties and be able to re- plan activities and shift resources.

Many organizations undertake several projects at once, and at any given time each may be at a different stage of the life cycle. Although some projects are just be- ing started, others have reached maturity or are being phased out. Management must be able to continuously balance resources among these projects so the individual re- quirements of each are fulfilled and their sum does not exceed the capacity of the par- ent organization.

4.2

S

D

C

The life cycle of a human-made system can be segmented into a logical series of phases or stages, each representative of the types of tasks or activities typically con- ducted during some period in the life of the system. Figure 4-2 shows one way of di- viding the life cycle into four phases:

1. Conception phase (Phase A) 2. Definition phase (Phase B) 3. Execution phase (Phase C) 4. Operation phase (Phase D)

This normative four-phase sequence, called the systems development cycle, encom- passes the total developmental life cycle of systems. The phases overlap and interact, yet are clearly differentiable. They reflect the natural order of thought and action in the development of human-made systems, whether consumer products, space ve- hicles, computer information systems, company relocations, movie productions, or even political campaigns. For some systems the development cycle overlaps identi- cally with the project life cycle. In others, only portions of systems development are covered in the project life cycle, such as beginning with the definition phase or ter- minating with the execution phase.

Phase A: Conception phase Initiation stage Feasability stage Proposal preparation

Phase B: Definition phase Project definition System definition User and system requirements Phase D: Operation phase

System maintenance and evaluation

Phase C: Execution phase Design stage Production/build stage Fabrication Testing Implementation stage Training Acceptance tests Installation Termination System improvement (To Phase A: repeat cycle) System termination Figure 4-2

Four-phase model of the systems development cycle.

A project typically spans Phases A through C, the conception, definition and exe- cution phases of the cycle. In that context, a project can be thought of as an organiza- tion that exists to develop a system, and the project life cycle as being the first three phases of the systems development cycle. When Phase C is terminated upon implementation of the system, so is the project. At that time the system transits from being the end- result of a project to being an operational entity.

Virtually all projects progress through Phases A, B, and C, though not necessarily through all the activities shown in Figure 4-2. The actual steps in the project life cycle depend on the system or end-item being developed; some stages might receive little emphasis or even be skipped entirely. In general, however, most every project does in- volve at least most of the activities shown in Figure 4-2, even if informally. Many proj- ects do not involve formal proposal preparation, but every project starts as a proposal from someone. Similarly, not every project requires design and production as con- strued in manufacturing and construction, but each does require the designing and bringing together of elements to produce a final result. Even in a consulting project, for example, the investigation of the client situation must be conceptualized and laid out (design), the investigation results compiled and edited to produce the final report (production), and the report presented to the client (implementation).

Each phase of the cycle has specific content and management approaches. Be- tween phases are points at which decisions are made concerning the preceding phase and whether the next phase should be undertaken or the project abandoned. Though the number of phases and details for each are a matter of judgment and differ for every project, the sequence is similar for virtually all projects.

A project can be terminated at the juncture between phases either by prior contractual arrangement or because management decides it is not worth continuing. In large-scale endeavors such as urban renewal, product development, and space and weapons systems development—where the development cycle spans many years, the cycle itself is often treated as a program and the phases within it as separate projects—sometimes each conducted by a different contracting organization. For ex- ample, Phase A would be treated as a project and managed by one organization, Phase B as another project managed by a different organization, and so on. The glue keeping all of the projects and organizations on track throughout is the program manager.

Within the systems development cycle are several main actors (interested parties): 1. System users, also called customers or clients. These include

a. User top management b. User operators

2. The system development organization (SDO), also called the contractor, devel- oper, promoter, or consultant, includes

a. Contractor top management (corporate and functional managers) b. Project management (project manager and staff)

c. The doers—professional, trade, assembly, and other workers

Users are the persons or groups for whom the project is being undertaken and who will acquire and/or operate the system when it is completed. User top manage- ment pays for and makes decisions about the project, whereas user operators will utilize or become the direct recipients of the project end-item or outputs. The Sys- tems Development Organization or contractor is the group doing the project, that is, studying, designing, and developing the system. It is usually external to the user or- ganization, although, of course, the contractor group might reside within the same organization as the user, which would be the case of an internal consulting/support group. Because in most cases the user pays the SDO or contractor to perform the pro- ject, the user can also be thought of as the buyer and the contractor as the seller. Use of these terms makes more sense when you think of a project in the context of being a contract between two parties wherein one party agrees to provide services to the other in return for some payment. The project manager usually works for the contractor, though users may also have project managers to represent their interests.

Besides the individuals or groups listed previously, the cycle usually involves other key actors. These include other individuals, groups, or organizations that have vested interests and/or influence on the conduct of the project or its objectives. They are project stakeholders, part of the environmental subsystems or the global system mentioned in Chapter 3. Anyone who is affected by the project who potentially can alter its outcome is a stakeholder.