Put another way, if you find yourself in a World War I-era trench, which would you rather have: the operator's manual on your howitzer or The Art of War by Sun Tzu?
Over my next few posts, I want to introduce my own version of the PMBOK® Guide, unencumbered by peer review (or even consistency). It will give me a chance to cut through some of the academic cobwebs that may have set into our practices, and illuminate recent issues and problems.
We'll start with scope.
Scope: (noun) the output or outcome for which your customer is willing to pay.
You've probably already recognized that, by this definition, the customer can't request anything out of scope, since what they desire is, by definition, in scope. And you would be correct.
So, if you don't want to find yourself in a situation where your (paying) customer is asking for more than you were originally willing to produce for a certain price, you had better have a very detailed agreement--otherwise, that most deadly of project ruination elements, scope creep, will devastate you, your team, your organization and your project.
Here's further proof that my definition for scope is correct: If your customer wants to add work to your project and will to pay for it, what project manager would refuse to do it on the grounds that it wasn't in the original statement of work?
No matter how absurdly the original work breakdown structure (WBS) was set up, if a person with sufficient organizational clout generated it, it can never be substantially changed.
In fact, the very act of pointing out that a proposed WBS element is inappropriate is a serious career-limiting move, since everyone knows that the ability to create a valid WBS is the litmus test for real project managers and pretenders. I've found that the pretenders will attack any challenge with a ferocity rooted in their insecurity.
Yes, it all begins with scope, but it obviously doesn't end there.
Next up: schedule.