A Look Back at the Original
(PMBOK) Framework
- Part 2Please read this Musings in conjunction
with my January paper: The Framework
Rationale. Once again, our January paper is a repeat of what I wrote
over 30 yeas ago. And again, as I wrote last month,
I think it is worth repeating because it represented our project management expectations
of those days. Those expectations concerning a "Framework" for project management
are very different from what is described today. Indeed, in 1991, I wrote
a book for PMI titled A Framework for the Project and Program Management Integration
that covered the same original ground and much more. This particular book was
intended to be the first of a series designed to cover all of the components of
the PMBOK. I had hoped that the other authors of the original PMBOK would do the
same, but that was not to be.
Instead, in 1996, the Institute under the
guidance of the then Director of Standards of the PMI Standards Committee, William
R. Duncan, produced a document titled: "A Guide to the Project Management Body
of Knowledge". As noted last month, this "Guide" was explicitly stated as "not
the PMBOK", yet equally explicitly stated that: "This document supersedes
PMI's Project Management Body of Knowledge (PMBOK) document that was published
in 1987."[1]
This 1996 Guide introduced
a "systems approach" to describe the component knowledge areas identified in the
1987 document. In other words, in the 1996 document, each so-called knowledge
area was represented in terms of their "component processes", rather than by the
Function Impact Matrix Charts associated with each original PMBOK Function
component. This approach was a valuable contribution to the understanding of project
management because it specifically described, or at least recommended, how the
various components of the work of managing a project should fit together. At
the time, 37 such "project management processes" were identified to compose the
whole PMBOK knowledge content.[2] Since
then the number of processes has increased, and also fluctuated somewhat, in subsequent
updates. This new form of documentation then became the basis of the material
for the subsequent PMP examinations, although it must be said that many questions
in the exam are drawn from other sources. This format has been pursued in ever
increasing detail up to the present day. A troubling feature, however,
is that the broad definition of a "system" is that it is: "A set of principles
or procedures according to which something is done" or, in other words: "an organized
scheme or method."[3] If that is true,
then a project system is essentially a way of doing a project. Many up and coming
project managers have been thirsty for a good way of "doing projects", and this
looks like it. However, PMI has warned that the PMBOK Guide should not
be used as such a methodology. Nevertheless, the 1996 document, and every
update since, has been labeled "A Guide to the Project Management
Body of Knowledge". If that description is to be true, then what is, or where
can we find, the true Body of Knowledge" to which we are being guided? Another
aspect that I find most troublesome is the cavalier way in which "Quality Management"
is cast aside to 8th place in the hierarchy of project management topics as presented
in the Guide. That is as though the subject is of relatively minor significance.
Either that or the authors of the Guide, and all of those since, simply do not
understand the vital link between the scope of the project and product's quality
rating and delivered quality. All else being equal, these two components together
play the most important part in determining the time and cost of the project. Hence,
the issue of Quality Management with respect to its impact on time and cost is
second only to Scope Management. Firstly, that's because ensuring the quality
of the end product is "fit for purpose", whatever that product might be, has,
like scope, a direct bearing on the cost of the product and its time to delivery.
Secondly, and for the same reason, it is absolutely essential for the end product
to measure up to those quality standards as set. In other words like "scope",
"quality" in and of the product is also fundamental to project success. Figure 1
shows the basic product/project management environment in which the project manager
is expected to work. Figure
1: The project manager's basic working environment.While we are talking
about some obvious basic improvements that could be made to the Guide, here is
another that I think would be very timely. I simply hate being known as, or referred
to in abstract terms as, a "Human Resource", as in Project Human Resource Management.[4]
Yes, I know that "men and women" would be about the same length and more descriptive,
but not necessarily all-inclusive these days. So why don't we just simplify and
call this PMBOK component: "Project People Management"? 
1. A Guide
to the Project Management Body of Knowledge, Project Management Institute
Standards Committee, Sylvia, NC 28779, USA, 1996, p vii.
2.
Ibid, p viii.
3. Google, accessed 12/11/18.
4.
The Guide's Table of Contents (and every where else), p vi.
|
