Published here January 2019

 

Musings Index

A Look Back at the Original (PMBOK) Framework
- Part 2

Please 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 Guide", 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.
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 iv.
2. Ibid, p viii.
3. Google, accessed 12/11/18.
4. The Guide's Table of Contents (and every where else), p vi.
 
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page