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."
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".
The phrase "According to the Guide" also appears extensively
 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.
Indeed, the book specifically differentiates stakeholders from users
and customers although
the definition in the Glossary
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".
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".
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."
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.
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
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
but rather the lowest level of any given branch
not quite the same thing.
PMP Study Guide p158
13. PMP Study Guide p3, 129, 267, 376
14. PMP Study Guide pp XXXVIII, li, 3, 8, 24, 52,
60, 71, 83, 87, 88, 95, 103, 117, 121, 123, 124, 128, 134,152, 196,
203, 204, 211, 216, 220, 256, 266, 295, 337, 340, 344, 368, 373, 382,
386, 409, 427, 487
15. PMP Study Guide p4
16. PMP Study Guide p292
17. PMP Study Guide p501
18. PMBOK Guide p16
19. PMP Study Guide pp 6, 16, 27, 28, 29, 32, 37,
59, 63, 64, 65, 124, 128, 192, 202, 210, 367, 368, 391, 443
20. PMBOK Guide p29
21. PMP Study Guide p54
22. Constructing the WBS, PMP Study Guide p130
23. PMP Study Guide p136