Missed Opportunities
And speaking of "project life cycle", if it is possible to revise the labels of
so many "standard" processes, isn't it about time that we got rid of the word "cycle"
that means endless repetition? The term "project life cycle" is used to refer to the
time span of a project, but time is linear and there is no way we can change that.
Therefore, "Project Life Span" (PLS) would be much better terminology. We'll use the
latter in our following discussion.
Perhaps the single biggest disappointment is in the failure of the Guide's authors
to recognize and advocate for the proper deployment of the project life span technique.
According to the Center for Research in the Management of Projects, University of
Manchester, UK, the importance of this life span process and its influence on the
management of the project cannot be over emphasized. This relatively short-term life-to-death
environment and the consequences that flow, is probably the only thing that uniquely
distinguishes projects from non-projects.[9]
A properly formulated PLS, with appropriate "gates" between the major phases, is the
vehicle for the sponsor or the executive management of the performing organization
to exercise control over the whole project management process. Many project failures
can be directly attributed to a lack of a sound PLS process.
If anything needed re-labeling it is the set of five project management process
groups. We delve in detail into this misleading state of affairs in our comments under
Section II in Part 2 of our review. While the authors have
tried hard to clarify this difficult concept, the result is questionable.
And while we are talking about wholesale change, it is high time that the knowledge
area chapters were re-ordered into their logical sequence. This sequence was carefully
considered, justified, and correctly presented in the 1987 version of the Project
Management Body of Knowledge. For those who no longer have access to this document
you can read the justification in my latest book: A Management Framework for Project,
Program and Portfolio Integration.[10]
Unfortunately, the logic of the sequence was lost on the developers of the subsequent
1996 version and, it seems, ever since. The current version makes great play of "organizational
process assets (updates)" that, according to the Glossary includes "lessons learned",
since it appears as an output of the work of each knowledge area. The credibility
of the Guide is challenged when it fails to apply its own recommendation.
The authors have made a serious attempt to clarify the controversial topic of the
term "scope". This is good, but the result is not quite conclusive and is not consistently
reflected in the other knowledge areas. Again, we discuss this in more detail under
Section III of Part 3 of our review.
The importance of quality is once again underplayed, both by its position in the
sequence of knowledge area chapters and its treatment of the term "grade". "Grade"
gets only a single passing mention in the document and that is in chapter 8 dedicated
to Project Quality Management.[11] We may
therefore infer that what is intended here is "Quality grade". Like the three other
"core" knowledge area variables, project quality management requires a "baseline"
as a basis-for-comparison, i.e. "conformance to requirements". This quality management
baseline is the quality grade. Note that "grade", i.e. quality grade baseline, is
not mentioned in Chapter 5, Project Scope Management.
The fact is, quality ultimately transcends all else, whether in terms of performance,
productivity, or final product. However, a remarkable number of people in the project
management industry don't seem to have latched onto that. Who will remember that last
year's project was late and over budget? That's all lost in last year's financial
statements. It is the quality of the product that endures throughout its life.
One may legitimately question to what extent the Guide's update-team were charged
with researching previous Institute documents and current project management texts,
given the paucity of references[12] for a
document of this importance. It is also a matter for regret that none of the expertise
of the senior members of the Institute, its Fellows, was available to the Standards
Program Member Advisory Group during the development of this latest version of the
Guide.[13] It is possible that soliciting
their collective review could have made a difference and some of these disappointments
might have been averted.
To be continued ...
In Parts 2 and 3 of this review
we will look in more detail at the Sections within the Guide.
R. Max Wideman
Fellow, PMI
9. Section 60
Life Cycle Design and Management, CRMP Guide to the Project Management Body of
Knowledge, Centre for Research in the Management of Projects, UK: University of
Manchester, 1999
10. A Management Framework for Project, Program and Portfolio Integration
(see http://www.maxwideman.com/papers/framework_book/intro.htm
for details) pp35-37
11. A Guide to the Project Management Body of Knowledge, Third
Edition, Project Management Institute, PA, 2004, p180
12. Ibid pp345-346
13. Ibid p326
|
Downside
