TOPIC: Where do I start?

I hope I can be clear and concise in my effort to describe my confusion, because I know that I am on the cusp of "getting it" and putting it altogether. So hear goes...

My confusion stems from the fact that the Project Management Plan is (or can be?) a collection of all of the other subsidiary plans (i.e.: Scope Mgmt. Plan, Quality Mgmt. Plan, etc.). So on page 106 of the PmBok guide, it states, "Completion of the project scope is measured against the project management plan." If the project mgmt plan, and the process of developing it, includes the project scope plan, (see pps. 76, 77; "It integrates and consolidates all of the subsidiary plans and baselines from the planning processes.") how does one measure the scope plan against the project plan if the scope plan is a component of the project plan?

Also, it seems to me that the PmBok guide picks and chooses what tools and techniques they find acceptable to them, when there are clearly other T&T that can be used successfully, logically, and are reasonable for many development processes. For example, in plan scope managment, if you could use meetings, why could one not use interviews. If such a question were to fall on the exam, an interview is simply a meeting with one individual, and yet it is not a technique that is "acceptable" or "acknowledged" by the PmBok. It makes good sense that I can use multiple other techniques as well. If we are to not memorize, but understand and think logically, then I foresee bad results.

Lastly, I would love to see real world examples, or any examples for that matter. These concepts I understand are a framework, sometimes understanding the concepts is much easier when an physical manifestation is attributed to it. By this I mean, (and I'll continue to utilize plan scope management as an example): if plan scope management is the process of creating a scope management plan..., then it could manifest as: writing down the requirements, scope and WBS in a Word document.

The concepts without true to life examples can be fleeting, abstruse, abstract and esoteric.

Thank you.

Ah, and one more question.

Using the example of "Plan Scope Management", why do I need a process to determine "how" the scope will be defined? Shouldn't the scope just be defined? Or does this essentially mean that I have to document that I will (meaning, process):

Meet with stakeholders on Wednesday, by phone, using the project charter as a starter discussion.

Again, why does one have to define a process to develop a process? Should one not simply define the scope, validate the scope, control the scope?

Please explain to me what I am missing. I know that if someone can bridge this gap for me, all of this will come together.

Thanks again.

Joe,

Here are my answers for you

My confusion stems from the fact that the Project Management Plan is (or can be?) a collection of all of the other subsidiary plans (i.e.: Scope Mgmt. Plan, Quality Mgmt. Plan, etc.). So on page 106 of the PmBok guide, it states, "Completion of the project scope is measured against the project management plan." If the project mgmt plan, and the process of developing it, includes the project scope plan, (see pps. 76, 77; "It integrates and consolidates all of the subsidiary plans and baselines from the planning processes.") how does one measure the scope plan against the project plan if the scope plan is a component of the project plan?

You are right. That would not make sense at all. I checked your reference and I don't see where it says that you compare the scope plan against the PM plan. I may have missed this... do you have an exact chapter number?

Also, it seems to me that the PmBok guide picks and chooses what tools and techniques they find acceptable to them, when there are clearly other T&T that can be used successfully, logically, and are reasonable for many development processes. For example, in plan scope managment, if you could use meetings, why could one not use interviews. If such a question were to fall on the exam, an interview is simply a meeting with one individual, and yet it is not a technique that is "acceptable" or "acknowledged" by the PmBok. It makes good sense that I can use multiple other techniques as well. If we are to not memorize, but understand and think logically, then I foresee bad results.

The PMBOK Guide is exactly that... a GUIDE. It does not claim to contain all PM knowledge. It contains the knowledge that is traditionally known to be applicable to most projects most of the time. For the PMP exam the rule is quite simple: The PMBOK Guide is always right. No exceptions and no arguing. But the PMBOK Guide also states that we as the PM team will be tailoring our methods, tools & techniques to the needs of the project. But if an exam question asks "which of the following is / is not a T&T of process X", then the correct answer is according to the PMBOK Guide. So if you want to pass the exam: The PMBOK Guide is always right.

Lastly, I would love to see real world examples, or any examples for that matter. These concepts I understand are a framework, sometimes understanding the concepts is much easier when an physical manifestation is attributed to it. By this I mean, (and I'll continue to utilize plan scope management as an example): if plan scope management is the process of creating a scope management plan..., then it could manifest as: writing down the requirements, scope and WBS in a Word document.

There are many such examples out there. Just do a web search for the example you want and you will find document after document. But of course the PMBOK Guide is mostly a scholarly text so it only shows a small set of samples to give us a general picture. If you want the "real life" examples, then you have to look around for what others have shared publicly. There are also lots of templates available for many of the tools that are mentioned in the PMBOK Guide.

Using the example of "Plan Scope Management", why do I need a process to determine "how" the scope will be defined? Shouldn't the scope just be defined? Or does this essentially mean that I have to document that I will (meaning, process): Meet with stakeholders on Wednesday, by phone, using the project charter as a starter discussion. Again, why does one have to define a process to develop a process? Should one not simply define the scope, validate the scope, control the scope?

The PMBOK Guide uses a very methodical approach to project management. Generally speaking you can shorten it to "Plan - Do - Check - Act". So no matter what your task (or process) is you first have to plan what you are going to do. Let's take the example of your "Wednesday phone call". Would you just pick up the phone and call each stakeholder without thinking first about what questions you might want to ask them? My guess is that you would probably (at least) jot down a few notes of what you are going to ask them... right?
Well.. the PMBOK Guide takes this to the "professional level". Instead of allowing you to "shoot from the hips" and just start calling people, it is telling you to first sit down and plan everything in detail. You thereby have a process that you can repeat on every project. (And don't forget what I said earlier... for the PMP Exam... The PMBOK Guide is always right).