Summary and Conclusions
In reviewing the last three decades, it seems clear that the scope of project management and the underlying concepts of the project life span have evolved considerably. Whether this evolution is the result of a deliberate progression, or due to a gradually improved understanding of the project management phenomenon itself may be open to question. Certainly, today there is a better understanding of the integrative role played by a properly constructed project life span, even if project management associations have failed to fully explain and underscore the importance of this role.
It appears that Patel and Morris's 1999 description of the project life cycle (span) is an accurate one, namely
"The sequence of phases through which the project will evolve [and]
will significantly affect how the project is structured … There should be evaluation and approval points between phases often termed 'gates'."[42]
Thus a structured project life span plays a key role in the control strategy for the evolution of a project. Unlike schedule bar charts and flow diagrams, the project life span phases represent significant changes as the project progresses through succeeding levels of maturity. These include changes in: progressive levels of detail in management decision-making, required management style, and required management skill sets. Control points, constituting major milestones at which specific deliverables are expected, segregate these high-level strategic phases. Moreover, these points in time are treated as "gates". The idea of gates implies that the project does not proceed beyond them unless and until the required phase deliverable has been carefully reviewed and found satisfactory.
One might liken this progression as somewhat akin to the young student passing
a succession of final exams as he or she climbs up the educational ladder to
full-grown capability. Each subsequent step in the educational program requires
passing the criteria for competence in the previous level. Each major step
also involves a significant change in learning style.
What also seems to be clear, however, is that there has been considerable controversy over when a project actually starts and, surprisingly, when it finishes. Moreover, this is a controversy, or lack of understanding, that continues to this day. This misunderstanding seems partly due to some people viewing a project as a "process" while others use the word as a substitute for the word "product".
For example, Archibald lists the generic project life cycle as
- 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)
The labels sound good, but we are not convinced that there is general agreement
on their meaning. Indeed, we believe that "deployment, design/construct/commission,
install and test" are sufficiently different from the product production work
that it constitutes a different and final phase to the project. Along with "Closeout" we
prefer to think of the fourth phase in terms of "Transfer of care, custody
and control" of the product to the eventual owners/users.
Archibald suggested 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 went on to say that what is needed is the definition
of perhaps five to ten basic phases for each project category. That may well
be so, but then those project life spans are no longer "generic", there is
as yet no "general agreement" on project categorization or a project classification
scheme and, we suggest, if we cannot understand the basic generic project life
span, how can we expect to reach a general understanding of anything more detailed?
Indeed, the Strategy Principle, Principle #4 in my paper First Principles of
Project Management (see http://www.maxwideman.com/papers/principles/principles.htm)
attempted a simple explanation of such a simple concept.
However, writing from the perspective of the chemical process industry, Fish agrees with Archibald that a more detailed and "robust" model would be more useful, one having eight phases at the next level of detail. Clearly, there is more work still to be done and no doubt the larger and more complex the project, the more gated phases that are desirable. Nevertheless, what does appear to be evident is that four phases, as listed for the generic model, are a minimum for any project to be fully successful.
On the positive side, much improved recognition is now given to the importance of project justification long before execution of actual product production work. Recognition is also being given to the importance of the transfer of the "product" into the care, custody and control of the users. This latter area of the project life span still requires more attention, but it is a reflection of the reality that all projects exist in an "environment", whether public, private or non-profit, and a realization that this environment also needs to be managed. That is to say, the management of a project needs to extend beyond the internal processes to what is happening outside the project.
A further development over the decades is the change in the nature of projects encompassed. This has moved the focus of project management literature from managing large relatively limited capital construction or technology projects to managing portfolios of short-run system and service-oriented projects. This is often accompanied by an increase in the number of stakeholders involved. It is evident from all of this that one size does not fit all but rather requires a degree of flexibility. However, just how much is still a matter of on-going debate.
The issue, as always, is one of strategy: "How much control? Who should have it? and When?"
42. Patel, M. B. & Prof. P.G. W. Morris, Guide to the Project Management Body of Knowledge, Centre for Research in the Management of Projects, University of Manchester, UK, 1999, p52.
|
Whither Project Life Spans in the 2000-Decade?