The following research paper has been prepared with a view to advancing the body of project management knowledge.

Last updated 2/1/04

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

Whither Project Life Spans in the 2000-Decade?

In recent years, the accelerating pace of technological development has led to the need to administer and manage multiple projects to maintain competitive advantage. Whether this is a consequence of, or driver for, even greater focus on the front-end of project life spans is difficult to say. Either way, the focus of project management has moved "upstream" into program management and project portfolio management. This requires senior management's attention not just on one project but multiple projects competing for resources, cash flow and contribution to corporate strategic objectives. This in turn requires closer attention to screening or filtering out potential projects that do not make the grade during the course of the portfolio-program-project life span.

Therefore, Forsberg, Mooz and Cotterman suggest that the project life span has three aspects: Business, Budget and Technical (2000). As they say

"The business aspect contains the necessary business events related to customer management, justifying the project, the overall business management events, and associated contractor and subcontractor management.

The budget aspect depicts the activities and events necessary to fuel the project with funds throughout its project life cycle.

The budget activities and business management activities are combined with the technical aspects to yield the complete project cycle. The technical events are often the most significant force driving the project length and cost, and they're often the most difficult to manage."[31]

But as Archibald observes on the importance of designing and documenting project life-cycle processes

"Designing and documenting project life-cycle processes will:
  • Enable all 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 for each project category exists, it will be impossible to achieve the full benefits of modern, systematic project management."[32]

Archibald includes a typical gating process as shown in Figure 17.

Figure 17: Cooper, Edgbert & Kleinschmidt's Stage-Gate™  process
Figure 17: Cooper, Edgbert & Kleinschmidt's Stage-Gate™ process[33]

Archibald also clarifies the generic project life span with these words

"There is general agreement that these [i.e. the following] broad, generic project phases are
  • Concept (initiation, identification, selection)*
  • Definition (feasibility, development, demonstration, design prototype, quantification)
  • Execution (implementation, production, and deployment, design/construct/commission, install and test)
  • Closeout (termination and 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."[34]

[* Common alternative terms shown in parenthesis]

Archibald suggests that 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. He goes on to say that what is needed is the definition of perhaps five to ten basic phases for each project category. Fish, in a thoughtful paper "An Improved Project Lifecycle Model"[35] agrees (See http://www.maxwideman.com/guests/plc/intro.htm). Fish takes an in-depth and practical look at the project life span from the perspective of the chemical process industry. He provides a rationale for a "more robust" second or third level model by subdividing each of the "four" generic phases each into two more for a total of eight. Or ten if you include "sanction" and "audit" stages that are beyond the control of the project manager. He also arranges the model into a "Vee" display as shown Figure 18, an arrangement strongly espoused by Forseberg, et al.[36]

Figure 18: Fish's
Figure 18: Fish's "Vee" model of project life span

Interestingly, Morris uses this "Vee" shape to describe the waterfall development cycle of IT projects as shown in Figure 19.[37] Of this model, Morris observes

"Much of the difficulty in delivering IT projects successfully comes from (a) the challenge in specifying the system requirements in a way that will lead to business benefit, (b) the intangible nature of the product being produced."
Figure 19: Morris's waterfall development cycle
Figure 19: Morris's waterfall development cycle

Note the difference between the Fish and Morris displays. The left side of Fish's Vee describes products (documents) while the right describes activities. Morris, on the other hand displays all products. However, Morris also offers a generic project development cycle as shown in Figure 20.[38]

Figure 20: Morris's generic project development cycle
Figure 20: Morris's generic project development cycle

If we want to compare this with traditional construction, "Detailed Design" could be substituted for "Development". Since detailed design typically involves significant expenditure it is usually included as the first stage of project implementation. Combining development and execution in this way brings us back to a four-phase model which we think is not only more "generic" but more consistent with previous work in the field. This is not inconsistent with Morris's thinking, however, as he has stated elsewhere

"It is useful to note that the same life cycle sequence can be nested within each stage of the overall life cycle, just as subprojects nest within projects which can nest within programs."[39]

Finally, Morris provides an example of a standard drug development process, as shown in Figure 21. This is of interest because we do not often see examples of research and development project life spans. In describing this illustration, Morris observes

"Out of the thousands of compounds that may be initially synthesized and screened during discovery, only a very few typically enter into pre-clinical development; of these less than 5% might actually receive regulatory approval (and the majority of these do not then prove to be profitable!) Doing this may take from 12 to 20 years and cost several hundred million dollars."[40]

Figure 21: Morris's illustration of the standard drug development process
Figure 21: Morris's illustration of the standard drug development process

We do not normally think of projects being this long, except perhaps for very large civil engineering projects. Rather this illustrates levels well above project management, reaching into program and project portfolio management, where the rate of project rejection is extremely high. Does this suggest that all those rejected trials are projects failures? Not at all. It is an essential part of the advanced technology or research and development discovery process.

Meantime, a U.S. Department of Defense extension to the Project Management Institute's Guide to the PMBoK brings us back down to earth with its very clear display of the "Current DoD Acquisition Life-Cycle Process" as shown in Figure 22.[41]

Figure 22: US DoD Acquisition Life Cycle
Figure 22: US DoD Acquisition Life Cycle

Project Life Spans in the 1990s  Project Life Spans in the 1990s

31. Forsberg, Dr. K., H. Mooz, & H. Cotterman, Visualizing Project Management, Second Edition, Wiley, 2000, p89
32. Archibald, R. D., Managing High-Technology Programs and Projects, third Edition, Wiley, 2003, p41.
33. Cooper, R. G., S. J. Edgbert, & E. K. Kleinschmidt, Portfolio Management for New Products, Cambridge, MA, 2001, p272
34. Archibald, R. D., Managing High-Technology Programs and Projects, third Edition, Wiley, 2003, p44.
35. Fish, E., An Improved Project Lifecycle Model, Pandora Consulting, http://www.maxwideman.com/guests/plc/intro.htm (Guest Department), 2002, updated 2003.
36. Forsberg, Dr. K., H. Mooz, & H. Cotterman, Visualizing Project Management, Second Edition, Wiley, 2000, p34.
37. Morris, P. W. G., The irrelevance of project management as a professional discipline, paper presented to a forum in Moscow, 2003, p10
38. Ibid. p3
39. Morris, P. W. G.,Science, objective knowledge, and the theory of project management, presentation to the Institution of Civil Engineers, UK James forest Lecture, 2003, Footnote 5, p4.
40. Morris, P. W. G., The irrelevance of project management as a professional discipline, paper presented to a forum in Moscow, 2003, Footnote 10, p14.
41. US Department of Defense Extension to A guide to the Project Management Body of Knowledge, Version 1.0, June 2003, p7.

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