The Life Span of Projects
In investigating and understanding the nature and needs of projects, it is essential to recognize that they go through progressive periods during their life span. The label "project life cycle" typically used misrepresents this progression. My concern with the term "cycle" is that it implies "over and over" whereas one of the essential attributes of a project, as I described earlier, is its unique, non-repetitive nature. In addressing this subject I have elected to retain enough generic nature to make the discussion meaningful for project management as a profession, or at least as a discipline, rather than just someone's
As a basis for discussion, let me set up as a "straw man" picture of a project. While it may not correspond to practical reality, nonetheless I believe it represents an all-inclusive picture of a project and its life stages. It permits a coordinated display, and a consistent, focused discussion of a project, its components, the elements of the components, the inputs to and outputs from the component(s), and the forces acting on the project and its components. Further, I have done it in a form that is largely graphical and self-explanatory by using the graphics originated by Isgrig.
The project stages presented by Isgrig are shown in Figure 1. It is possible that not every PM practitioner will recognize all the terms displayed, or may even find them confusing. Nevertheless, the figure does display the most logical and comprehensive sequence readily available. Moreover, it can represent the realization of a hard product such as a facility, production plant, or infrastructure, or a soft product such as the development of a service, a software program, an advertising campaign, a product launch, a report, an analysis, a revised procedure, an evaluation, and so on.
Figure 1: The Project Life Cycle
(Copyright Professor Elvin Isgrig, 1991, reproduced with permission)
A particularly challenging aspect, often overlooked, is that each project manager in a project "system" has his own subset life span that looks much like Isgrig's description but actually operates within only a few stages of the whole. For example, in the case of a physical facility or plant, compare the perceived project stage views of the plant's owner/sponsor, the plant's designer PM, and its operations manager. To illustrate:
The owner's goal is to establish an operating facility that meets certain criteria, maximizes the project benefit and justifies the investment by return on investment.
This takes a lot of careful market analysis, planning and competitive positioning. Once the project is approved and launched, the owner's job is substantially done until after the whole project is finished and the plant comes on stream. The engineering manager, the plant's designer, will no doubt participate in the early planning, but his real job is to develop plans, drawings and specifications, not just efficiently, but to a constructed cost breakdown that will fulfill the investment mandate. Essentially, this is his "project", a subset of the whole.
Likewise, the operations manager will no doubt be consulted along the way but his "project" is to get involved in the new plant testing, commissioning, staffing, training, permitting, delivery of initial input materials and supplies and getting the facility up to full functional capacity. Thus, his "project" is really the last phase of the total project contemplated by the owner/sponsor. In a similar way, the plant's constructor PM, and each subcontractor providing design, fabrication and erection of each on-site unit of equipment will also see their individual piece as a whole project to themselves.
It is probably fair to state that the assignment and breakdown of a project into stages is driven more by the project's business sector and its typical project delivery system derived from past experience, than by the concepts of project management. At project conception there are very few stages envisioned - in fact often there is only "the project" and this holistic view is very beneficial. However, as the project progresses, and the preferred delivery system is selected and defined, more phases and stages are identified.
Indeed, I suggest that the next phase or stage must be defined or you don't really have a project to work on. That is because you are left with neither scope nor time to work to. It is even possible that the next stage is in fact termination; as with a feasibility study whose product finding is so unattractive as to be economically insupportable. Despite the prevalence and preference for a stage view of projects, it is useful and instructive to remember that at any stage the whole project can be beneficially viewed in its entirety as a single entity.
You must also keep flexibility in mind. The extent and assignment of phase divisions and limits, the number of segments within each major phase, the segment sub-divisions and the terminology shown or applied in each phase, segment or function block (step) are indicative only. They are not intended to constitute either a mandatory or an exclusionary display or listing. Steps can disappear, collapse or be specifically excluded for a real project according to the nature of the project and its industry. Such changes can be by choice, direction or dictate. Likewise, phase boundaries can be shifted so that the phase to which an activity or step is assigned can be modified to match the realities of the situation.
Once you acknowledge the need for this project life span flexibility, you are forced to recognize the practical limitations of our Figure 1. This can be frustrating to the practitioner who expects to find a framework into which he or she can directly dump his/her project, and thus jump right into its execution. But, the picture is also realistically cruel. The fact is, you cannot know the structure of your project's life span until you've attained some level of scope definition. And this, in turn, only develops as the project progresses and begins to assign its own terminology, definition, phases and boundaries.
As an aside, it is important to agree on the lexicon used in the breakdown or hierarchy of the project life span. From the bottom up, I would propose that the following constitutes a consistent, clear and useful guide. Tasks occur within activities and activities occur within stages. Depending on the magnitude of the project and its execution plan, phases are used to assemble stages, and the overall total time needed for completion of the project's product is the project's life span. Within this framework, upward collapsing of these "levels" can, and should be, considered and judiciously implemented as needed to provide for effective and efficient PM and project execution.
To complete the discussion on project life stages, and particularly in the light of current use of four major phases, we can readily abbreviate Isgrig's life span in Figure 1. To simplify discussion, and matching to life itself, the set of terms shown in Table 1 come readily to mind:
|Natural life span:
||Grow & mature
||Aging & pass on
||Check Out/Turn Over
|Year End Close:
*Descriptive verbs describes the nature of the work done by the PM. The use of these verbs is important and is discussed in a later article. They are shown here to emphasize the differing roles of the PM as the project moves through its life span.
Table 1 - Comparison of the natural life span with various project scenarios
1. Isgrig, E. Linking the Life-Cycle with the Project Breakdown Structure, Paper # 9.8, PMI Annual Seminar
Symposium, Dallas 1991, pp684-688