Introduction | Historical Perspective | Early Project Management Focused Texts
Project Life Spans, Late 1980s | Project Life Spans in the 1990s
Whither Project Life Spans in the 2000-Decade? | Summary and Conclusions

Project Life Spans in the 1990s

In late 1991, Warren Allen consolidated the general view of the project life span in a paper titled "The Universe of Project Management: A Comprehensive Project Management Classification Structure (PCMS) to Update and Expand the Dimensions of PMI's PMBOK". The paper arose out of a discussion amongst a group of interested PMI members prior to the annual seminar/symposium. Allen's PCMS model related the nine or more "Level 1" project management functions with the generic project life cycle. As Allen describes it

"[The] project life-cycle (Time) dimension defines the principle 'Major Management Phases' of virtually any type of project and acknowledges that project management functions and their application often change as the project moves through the various phases of its life-cycle."[22]

Unfortunately, the Project Management Institute subsequently declined the paper for publication, failing to see its value, and it appears that the author lost interest. Allen's project life span is shown in Figure 10.

Figure 10: Allen's generic project life span

One might be forgiven for thinking that by this time just about everything that could be said about project life spans had already been said about them. That might have been true but for two major events in the '90s. The first was the rapid rise of the idea of managing by projects in the emerging high-project volume software development industry. Software development, like R&D, is not so amenable to the deterministic planning flowing from the idea of a well-established generic project life span. On the contrary, the production people (i.e. programmers) in this industry seemed to have strongly eschewed any suggestion of the control that an established life cycle implies. That is, until the arrival of the "Year 2000" (Y2K) legacy software upgrade panic.

The second event seems to be the publication in 1996 of the Project Management Institute's Guide to the Project Management Body of Knowledge ("PMBOK"). This publication was a complete rewrite of the 1987 version, which had attempted to identify those areas of knowledge within the purview of a project management discipline, or profession, as some prefer to call it. The Guide, on the other hand, set out to describe only the subset of the PMBOK that is generally accepted.[23] As a part of this rewrite, a section was devoted to project phases and the project life cycle with a number of examples displayed. Disappointingly, the sample generic life cycle offered was denuded to the point of illustrating only the beginning and end of a project. It appears that the author(s) of this section had not done their homework in reviewing even PMI's own official publications. Worse yet, the same illustration was repeated in the 2000 Edition update, see Figure 11.[24]

Figure 11: PMI Standard Committee's sample generic project life span

Perhaps the PMI Standards Committee was influenced by a presentation made to an information systems group by Kapur (1995). The paper was titled "The Seven Deadly Sins of Project Management" and Sin Number 5 pointed to the lack of a robust project management process. Kapur proposed a set of six stages in a "Scalable Model" of 33 steps. His illustration is shown in Figure 11a.[24a] The red triangles between each stage represent the specific deliverables shown in the boxes immediately below. However, closer study of the Figure shows that the second stage is "Pre-Launch" suggesting that only the third, fourth and fifth stages shown are a part of the formal project life span.

Figure 11a: Kapur's information system project life span

Instead of this limited view, others were expanding their vision of project management. For example, Morris wrote (1998):

"Too many people see project management as beginning when the project is set up. Yet all the lessons of modern management -- and indeed all the lessons of project management history -- show that time spent up front in defining needs, exploring options, modeling, testing, and looking at different business benefits is central to producing a successful project. The decisions made at the early definition stages set the strategic framework within which the project will subsequently develop. Get it wrong here, and the project will be wrong for a long time -- perhaps forever. Get it right, and you are half way there. (Defining the problem is half the solution; 90 percent of the outcome is defined in the first 10 percent of the project.) This is one of the most crucial areas of project management professional input."[25]

Morris includes a graphic of his project life cycle as shown in Figure 12.

Figure 12: Morris's project life span

In fact, Morris's graphic looks more like a flow diagram with inputs and outputs rather than a time based life span display.

Frame mirrors Morris's view. He wrote (1998)

"If the traditional four-phase project life cycle is viewed from the customer perspective, we encounter a dramatic revelation. The phases that customers worry most about are the very ones that have been down played in the theory and practice of project management. Customers care most about phases 1 and 4. With respect to phase 1, their concern is: "Did you get my needs and requirements right?" If not, then the planning and implementation activities of phases 1 and 2 are a waste of time. With respect to phase 4, their concern is: "Are you about to hand me a deliverable that meets my needs and is operable and maintainable? If not, then what you have been doing on the project these past few months?" The link between project closeout and the level of customer satisfaction with project effort should be obvious."[26]

The Morris and Frame views are probably reflections of actual steps taken by some companies, such as Dupont and Abitibi, to be more thorough with "front-end" work, especially if their market position depends on capital-intensive projects. Figure 13 shows the introductory graphic to a presentation promoting the idea of "front-end loading" of the project development phases (1996).[27]

Figure 13: Abitibi's front-end loading of project development

Thoms describes three stages of the project life span in terms of motivation, which brings in the "people" (or human resources) aspect. She says (1998)

"Getting started
The goal of the first stage is to get the team and each individual member moving and motivated. Part of the process of motivating the project team is explaining the project, yet many managers fail to tell their team why the project is important.
…
Project Development
In the next stage, the day-to-day work on the project proceeds, and the project develops. A project manager who provides an exciting launch for a project needs to keep energy flowing when the team gets bogged down in details and runs into problems.
…
Wrapping Up the Project
The final stage of a project can sometimes be the most difficult. Often teams are tired of the work, bored with the technical details, and anxious about the next project. This stage varies with the length of the project and the attention span of each individual."[28]

This author went further and associated different phases of the generic project life span with different project manager personality types as best suited to the management of that particular phase. He wrote (1998)

"The 'Concept' phase of the four phase high-level project life cycle should start out with the 'Explorer' type; then proceed with a 'Coordinator' type in the 'Development' (definition or planning) phase; move to an assertive 'Driver' type in the 'Execution' phase; and conclude with the 'Administrator' type in the cleanup 'Finishing' phase."[29]

Meantime, the software development industry appeared to be going its own way. The so-called "waterfall" model of the "conventional" software engineering process or workflow, shown in Figure 14, was touted by many but decried by others. This model is technology specific, but its essential difference is that the major activities overlap significantly. However, the real difficulty with this model is software development's essential need to progress iteratively.

Figure 14: Conventional waterfall model of software development

An early attempt to reflect an iterative strategy was offered by Boehm (1988) in a "spiral" model as shown in Figure 15.[30]

Figure 15: Boehm's spiral model of software development

However, Royce brought some semblance of order by suggesting the relationship between the spiral model and the project life span as shown in Figure 16 [30a] (1998).

Figure 16: Royce's life span view of the spiral model

Given the explosion of small to medium sized information systems/technology projects, Mochal has developed one of the first discrete project management methodologies dedicated to this market. It is based on Mochal's view of the project life span for software development projects in a process he calls the Project Lifecycle Process™. His five-phase framework is shown in Figure 16a.[30b] The accompanying manual details all the project and technical management activities to be considered in an essentially linear process.

Figure 16a: Mochal's view of software development projects

Project Life Spans, Late 1980s

Whither Project Life Spans in the 2000-Decade?

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