Introduction | Content in General | Project Life Span
Technical Content | Pearls of Wisdom

Technical Content

The author tries to stay close to the PMBOK Guide, but some of the problems show up in the text. For example, Kim says "A strange thing happens here. Resource requirements become an input to other Planning processes. But so do staffing requirements, which are a subset of resource requirements. This is the only process where an output is split into two pieces and each piece becomes an input to other processes."[12] By the way, does anyone believe that memorizing all these inputs and outputs for the exam really makes them a better project manager? And, for that matter, have all these inputs and outputs ever been tested on a real project?

Indeed, it appears that Kim is not always comfortable with what the PMBOK Guide says and prefaces some remarks with a phrase such as "What the Guide to the PMBOK terms".[13] The phrase "According to the Guide" also appears extensively [14] and it is not clear whether the author would otherwise beg to differ, or uses it just to emphasize the source of the information. Since we understand that many of the actual certification questions are sourced from other recommended documents, the statements in the PMBOK Guide could in fact be misleading.

I was surprised to learn from the PMP SG that project stakeholders are confined to the immediate project environment and do not include product operatives, i.e. the users, or members of the public.[15] Indeed, the book specifically differentiates stakeholders from users and customers[16] although the definition in the Glossary[17] is all-inclusive. In defining project stakeholders, the Guide to the PMBOK does include "individuals and organizations ... whose interests may be positively or negatively affected as a result of project execution or project completion".[18] So it does include users, customers and the public who may be impacted by the results of the project, even if reluctantly.

I was dismayed to see many references to "triple constraint".[19] True it is mentioned in the PMBOK Guide but only to the extent that "Many project practitioners refer to the project triple constraint as a framework for evaluating competing demands."[20] That is true, perhaps because the triangle is a sexy symbol, but the reality is that there are four core constraints to project management and these consist of scope, quality, time and cost. To this list you might even add "customer satisfaction". This is especially important to remember when managing the project and assessing options and risks. It is high time that the flawed concept of a triangle is laid to rest.

Another area of confusion in the project management arena is the difference between a scope statement and a statement of work. A scope statement should describe the product to be produced by the project and form the basis for a product-oriented breakdown structure. It does not serve as a statement of work.[21] The statement of work should describe the work involved in producing the product and it is this statement that enables activities to be identified and the time and cost of the project to be estimated. But Kim does a good job of describing how a work breakdown structure should be constructed[22] and neatly side steps the perennial discussion of whether its content should start with nouns or verbs. However, we think that it is not the lowest level in the WBS that is called a work package[23] but rather the lowest level of any given branch — not quite the same thing.

The Project Life Span

Pearls of Wisdom

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